openWYSIWYG editor - Fixing 'bugs' (improving script)

[djr33]

(I hope posting in here is right... not sure...)

Link to script:
http://www.dynamicdrive.com/dynamici...iwyg/index.htm

I posted a thread about this to get some help, but no one seemed to have the answer.

So I played around a bit, and I've come up with a couple nice work-arounds for this script:

1. Setting it to always submit in html mode (not plain text).
2. Fixing the hyperlink popup so you don't get "http://http://yoururl...."


FORCE SUBMIT IN HTML MODE:
I hate that if you submit if you've selected "TextMode" it submits as text... not html.
Ex: a "<" will be submitted as "&lt;", and when you display this on your next page, it's not html, but displaying the html as text, like you'd see "<b>" instead of getting bold text, etc.
So... this is a pretty simple workaround.
In your form tag, add this:

<form ... onSubmit="formatText('ViewText','YOURTEXTAREA');"

Replease "YOURTEXTAREA" with the name of your text area, as defined on your page and in your script.
If you have more than one text area, use this:

<form ... onSubmit="formatText('ViewText','YOURTEXTAREA');formatText('YOURTEXTAREA2','htmlaftertable');"

That will switch your text area back to html mode before submitting, and you're done.
You could probably add this to the submit button as well. I'm not sure what the pluses and minuses are for each method... one might be more compatible/secure than the other... so... you may want to look into that.


FIXING HYPERLINK POPUP:
When you open the hyperlink popup, you get two things:
1. A text field to type in your link.
and 2. Above that, a dropdown list to select what "type" of link.
Seems all good, but there's an issue.
For some reason, the "type" just ADDS that prefix to whatever link you type.
Ex: If you choose "http" as the type, and put "http://google.com" as your url in the text field, your resulting html will be "http://http://google.com"
The same goes with the "mailto" and "https" options.
You could just not put the http, and use www., but this still won't work for local links... you'd get something like "http://index.html".
So... by correcting this, it'll save you a trip to the code view each time you add a link.

How to fix:
1. Find your "openwysiwyg" director, with the .js file inside it. Go into the "popups" directory within that, and find "insert_hyperlink.html". Open that in notepad, dreamweaver, or whatever you like.
2. Look in the script, scroll down a bit, and find this part:

  <td style="padding-bottom: 2px; width: 50px; font-family: arial, verdana, helvetica; font-size: 11px;">Type:</td>

	<td style="padding-bottom: 2px;">

	<select name="linkType" id="linkType" style="margin-right: 10px; font-size: 10px;">

	 <option value="http://">http:</option>

	 <option value="https://">https:</option>

	 <option value="mailto:">mailto:</option>

	</select>

You really only need the select menu, but there's another change I wanted to make.

3. Replace that code with this:

<td style="padding-bottom: 2px; width: 50px; font-family: arial, verdana, helvetica; font-size: 11px;">Add:</td>

	<td style="padding-bottom: 2px;">

	<select name="linkType" id="linkType" style="margin-right: 10px; font-size: 10px;">

	 <option value="">(none)</option>

	 <option value="http://">http://</option>

	 <option value="mailto:">mailto://</option>

	</select>

Change the parts in red:
The select menu changes so you can add nothing to the start of your url, so you don't have to remove the http:// when you paste, or you can use a local file. This is a good default.
Just in case, though, you can still have the http, mailto, (and other) choices there.
If you want to add your own:
<option value="RESULT">CHOICE</option>
where CHOICE is what's in the dropdown and RESULT is what is added to the beginning of the link.
Also, the change at the beginning to say "Add:" instead of "Type:" makes this make a WHOLE lot more sense.
Type seems to imply that it will format it the "right" way, not just ADD something to the beginning.



I hope this is useful for some people.



I also am slightly bothered by the <br> that is always inserted at the end (or close... before other closing tags, sometimes) of the block of text.
I don't know how to get rid of it.
However, I'm using php and you can always do what I'm doing:

<?php
$textareaname = $_POST['textareaname'];
if ($textareaname == "<br>") $textareaname = "";
...
?>

...just checking if there was nothing entered. at least that way you won't get a worthless <br> by itself if the field was sent empty.

As for the <br> in general... no ideas. Wish someone who knew JS well would figure it out
I'll play a bit more and see what I come up with.

[djr33]

AHHHH!!!

There's an error with the "FORCE HTML MODE" script...
basically... works great if you submit IF it's in text mode, it'll switch back.
But if you're already in html mode, it does something weird and converts to plain text. Which is weird.

I'll look into it.... don't use yet, I guess. Heh.



EDIT: FIXED

Ok.

Update:

Here's what you do:

Add this code to the very end of wysiwyg.js (after a linebreak or something):

/* FUNCTION: Force html mode for text area so plain text isn't submitted.
Call with <form onSubmit="forcehtmlmode('textareaname')"> */
function forcehtmlmode(n) {
     if (viewTextMode == 1) {
     formatText('ViewText', n);
     }
}

take out the comment if you desire.

As said with the comment in the text, add
<form onSubmit="forcehtmlmode('textareaname')">
to your form tag.
you're done.


note: I haven't fully tested out all scenarios (like having 2 text boxes on one page), but I'll post if I have problems... working great right now.


What this does:
It sets it back to html mode IF you're in text mode.
If you're not in text mode, it doesn't do anything. This stops it from deformatting the text, which is what happens if you go from html mode to html mode... weird glitch.


EDIT 2: this isn't being nice with two text inputs... if one is text mode, it thinks both are. Meh.
I'll keep playing. Works great for one though

[djr33]

Ok... this is a bunch of code, so needs a new post.

the above problem is fixed and it now works for two text areas.

In your form tag, do the same thing as above, calling

<form onSubmit="forcehtmlmode('textareaname');">
or
<form onSubmit="forcehtmlmode('textareaname');forcehtmlmode(textareaname2);">
for two, etc.

Now, there are 4 parts of the wysiwyg.js file that need to be updated:

I'm hightlighting them in red:

I'm omitting stuff too, to save room in the post. ....[[[something]]].... means there's code missing.

....[[[copyright info]]]....

/* ---------------------------------------------------------------------- *\
  Global Variables: Set global variables such as images directory, 
	                  WYSIWYG Height, Width, and CSS Directory.
\* ---------------------------------------------------------------------- */

// Images Directory
imagesDir = "/sources/openwysiwyg/icons/";

// CSS Directory
cssDir = "/sources/openwysiwyg/styles/";

// Popups Directory
popupsDir = "/sources/openwysiwyg/popups/";

// WYSIWYG Width and Height
wysiwygWidth = 500;
wysiwygHeight = 150;

// Include Style Sheet
document.write('<link rel="stylesheet" type="text/css" href="' +cssDir+ 'styles.css">\n');

//FORCE HTML MODE ARRAY INITIATION
var viewTextCheck = new Array();
//END FORCE HTML MODE ARRAY INITIATION


/* ---------------------------------------------------------------------- *\
  Toolbar Settings: Set the features and buttons available in the WYSIWYG
	                  Toolbar.
\* ---------------------------------------------------------------------- */

....[[[middle of the code... long!]]]....



/* ---------------------------------------------------------------------- *\
  Function    : viewSource()
  Description : Shows the HTML source code generated by the WYSIWYG editor
  Usage       : showFonts(n)
  Arguments   : n   - The editor identifier (the textarea's ID)
\* ---------------------------------------------------------------------- */
function viewSource(n) {
  var getDocument = document.getElementById("wysiwyg" + n).contentWindow.document;
  var browserName = navigator.appName;
	
	// View Source for IE 	 
  if (browserName == "Microsoft Internet Explorer") {
    var iHTML = getDocument.body.innerHTML;
    getDocument.body.innerText = iHTML;
	}
 
  // View Source for Mozilla/Netscape
  else {
    var html = document.createTextNode(getDocument.body.innerHTML);
    getDocument.body.innerHTML = "";
    getDocument.body.appendChild(html);
	}
  
	// Hide the HTML Mode button and show the Text Mode button
  document.getElementById('HTMLMode' + n).style.display = 'none'; 
	document.getElementById('textMode' + n).style.display = 'block';
	
	// set the font values for displaying HTML source
	getDocument.body.style.fontSize = "12px";
	getDocument.body.style.fontFamily = "Courier New"; 
	
  viewTextMode = 1;
  viewTextCheck[n] = 1;
};



/* ---------------------------------------------------------------------- *\
  Function    : viewSource()
  Description : Shows the HTML source code generated by the WYSIWYG editor
  Usage       : showFonts(n)
  Arguments   : n   - The editor identifier (the textarea's ID)
\* ---------------------------------------------------------------------- */
function viewText(n) { 
  var getDocument = document.getElementById("wysiwyg" + n).contentWindow.document;
  var browserName = navigator.appName;
	
	// View Text for IE 	  	 
  if (browserName == "Microsoft Internet Explorer") {
    var iText = getDocument.body.innerText;
    getDocument.body.innerHTML = iText;
	}
  
	// View Text for Mozilla/Netscape
  else {
    var html = getDocument.body.ownerDocument.createRange();
    html.selectNodeContents(getDocument.body);
    getDocument.body.innerHTML = html.toString();
	}
  
	// Hide the Text Mode button and show the HTML Mode button
  document.getElementById('textMode' + n).style.display = 'none'; 
	document.getElementById('HTMLMode' + n).style.display = 'block';
	
	// reset the font values
  getDocument.body.style.fontSize = "";
	getDocument.body.style.fontFamily = ""; 
	viewTextMode = 0;
	viewTextCheck[n] = 0;
};



/* ---------------------------------------------------------------------- *\
  Function    : updateTextArea()
  Description : Updates the text area value with the HTML source of the WYSIWYG
  Usage       : updateTextArea(n)
  Arguments   : n   - The editor identifier (the textarea's ID)
\* ---------------------------------------------------------------------- */
function updateTextArea(n) {
  document.getElementById(n).value = document.getElementById("wysiwyg" + n).contentWindow.document.body.innerHTML;
};

/* FUNCTION: Force html mode for text area so plain text isn't submitted.
Call with <form onSubmit="forcehtmlmode('textareaname')"> */
function forcehtmlmode(n) {
	if (viewTextCheck[n] == 1) {
		formatText('ViewText', n);
	}
}

Note: this new JS should work for one, two, or more textareas, and will be determined by your form tag, and what onSubmit equals.


Again, just add the stuff in red to wysiwyg.js and you'll be good to go.


Also, remember that this won't do a thing unless you call it with the onSubmit value of the form. It isn't automatic.... though... wish it was
...but at least you can choose to not use this if you don't want to, I suppose.



EDIT: Here... you can have the file as an attachment... realized that's possible

[amper]

FIXING HYPERLINK POPUP wont work if you after adding hyperlink to local file (f.e. info.zip) go to HTML mode. After click HTML and then TEXT (to return to the HTML mode) it adds "http://" before "info.zip". Any ideas how to fix it?

It also affects all image src tags (f.e. images with relative path are changed to full path)... :-(

[djr33]

[Note: Another post has been made about this script, and I wanted to refer to this old thread. I somehow missed this post, and never did reply. Strange. Sorry about that, if you ever do see this message. Unintentional.]

Way late--
in answer to the question, I think my fix should do exactly that.
It used to add http:// no matter what. Now with the blank option, it will not add a prefix for local files.
Or, perhaps this another level of a similar setup that my fix didn't account for.

If you were saying that my fix actually hindered the use of local files, I have no idea why, because the only thing I did was removed the "http://" prefix.


EDIT: Just tested. No problem there. If anything, fixed it.
If the problem isn't resolved or if someone else runs into a similar situation, I'll take another look.