A directory of browser-based WYSIWYG editors


Home: htmlArea 3 (beta): htmlArea 2 & 3 archive (read only): htmlArea v3.0 - Bug Reports & Fixes:

The htmlArea 2 & 3 editors have been discontinued.

We've made these forums available as a read-only reference and knowledge-base for people using or developing editors based on htmlArea 2 or 3.

Anyone who is interested in taking over version 2 or 3 is free to do so. All we ask is that you choose a new name that doesn't have "htmlarea" in it to avoid confusion with this site. We'll even give you a link in the directory to make it easier for people to find you. If you are developing or hosting an htmlArea based-editor under a new name, please submit it to our directory.


New User

Feb 14, 2005, 1:50 PM

Post #1 of 6 (22398 views)
stripBaseURL Can't Post

The function stripBaseURL() in HTMLArea 3.0 RC3 corrupts filepaths when the editor is invoked from a different URL (i.e. than the URL path used to view the HTML code (i.e., then all URL's modified by stripBaseURL (basically, EVERY local reference) will point to the wrong location (relative to the /admin/ path).

The quick fix is to add the following code BEFORE creating new HTMLArea:

  HTMLArea.prototype.stripBaseURL = function(string) { 
var baseurl = this.config.baseURL; // strip host-part of URL which is added by MSIE to links relative to server root
baseurl = baseurl.replace(/^(https?:\/\/[^\/]+)(.*)$/, '$1');
basere = new RegExp(baseurl);
return string.replace(basere, "");

I do think this should be at least configurable (either don't strip anything, strip only domain part or strip nothing).

Martijn van der Lee

New User

Feb 17, 2005, 6:25 AM

Post #2 of 6 (22340 views)
Re: [mwvdlee] stripBaseURL [In reply to] Can't Post

I assume this cripling functionality has already been fixed for the next release since nobody seems to want to reply?

New User

Feb 17, 2005, 11:45 AM

Post #3 of 6 (22336 views)
Re: [mwvdlee] stripBaseURL [In reply to] Can't Post

I am also interested in a fix for this feature. I understand the reasoning behind it, but it presents an annoying bug in a CMS system.

My situation is that I have an "Administrative Site" at a particular url, say "" and then a public site at "". If I want to put a link within the editor to point to "" it will not work because the baseurl will be stripped to just "/site".. so that in the public it just points to itself due to the relative url instead of the absolute "" url.

If anyone has any suggestions, I'm all ears. Simply removing the stripping of the url does not work for various other reasons, the main one being that we need to allow relative urls in the admin.

Thank you for you help!

I of course love htmlarea nonetheless! Best Editing tool out there in my opinion.

New User

Feb 17, 2005, 11:47 AM

Post #4 of 6 (22329 views)
Re: [dmbfreak] stripBaseURL [In reply to] Can't Post

Just an addition to that:

The main issue is that we need to somehow "know" that the absolute url was user entered, as opposed to IE entered. So that I can allow the user entered absolute url through, but strip the IE entered.

New User

Feb 17, 2005, 12:55 PM

Post #5 of 6 (22312 views)
Re: [dmbfreak] stripBaseURL [In reply to] Can't Post

Shouldn't it strip(or not) the URL the same way in both cases?

New User

Feb 17, 2005, 1:53 PM

Post #6 of 6 (22306 views)
Re: [mwvdlee] stripBaseURL [In reply to] Can't Post

Yes.. as it is, it will. But the strip only happens on actions such as creation of a link, img, or changing from text to html view. But i guess there's really no way to tell if IE put the full base url in there or not. Our team has come up with a work around in the mean time.

Use a placer such as ::url_admin:: to represent a url to the admin. Then when the form is submitted and processed (we're on Tomcat/Struts framework) the content is checked for the placer and replaced with the necessary url to be stored in the db. Then when the content is pulled from the DB to fill the htmlarea editor the content is checked for instances of the url and replaced with ::url_admin:: so it will not get changed upon the next save. The actual url (in our case would be would be stored in a deployment descriptor or some other manageable interface.

The user is then instructed to place the ::url_admin:: placer where needed. It's a workaround, and annoying, but it works for us.

Note: IE still screws us on this one. If you have ::url_admin:: =, the full url, so that they just have to put the placer, it will change the link to file:///::url_admin:: (this does not happen in Mozilla). Therefore we have to (unfortunately) tell the user to represent the link as http://::url_admin:: so that it remains intact, and then set ::url_admin:: =

Hope that all makes sense. Let me know if you have any questions. This is probably a unique case with us. And only affects trying to make a link back to our admin site. All other absolute remote, absolute local, and relative links work fine. Whereas the public site just pulls the content from the DB as is, so it's not affected.


Search for (options)