I am using the latest version of FCKEditor - 2.6.4

I have a problem with FCKEditor adding a
tag to empty textarea fields on which FCKEditor appears.

The Body field setup to handle HTML. It works fine as a FCKEditor field. Body is not required and often will not contain any content. When I go to add a node, I fill out the form and leave the Body field empty. I view source to verify that there are no spaces and no characters between the open and closing textarea tags. All looks good.

I save the node and view the database and I see "
" in the field. and the "View", read-only display of the node. The Body field is outputting a
tag. Why?

After I save, click on edit and the view source, I see the following in the textarea tag for the Body field: <br />

I have "Enter mode" and "Shift + Enter mode" set to "

I've done some searching in Google, and I am a bit surprised that I haven't found more reports of this problem. But I did find this:


And person was having the same issue:


It would be great if there was some function to strip off trailing
tags when submitting -- something like:

rtrim($body, "
#2 fckeditor_strip_trailing_br_tag.zip2.08 KBcapellic


igorik’s picture

I have same problem, FCKeditor give to empty textarea <p>&#160;</p>

It is wrong, because if I have this textarea as required, with this it could be empty and user didn't receive info about required textarea (when it is empty)

capellic’s picture

I write a small utility module to take care of analyzing the Body and all CCK fields that are submit on a node form and replacing the "
" and "

" strings with an empty string. You can extract this archive file in your modules directory, enable it and edit and then save nodes that are having this issue and it should clear it up.

wwalc’s picture

Status: Active » Fixed

I did not manage to reproduce this issue with empty <p> tag, however I did manage to get the single <br /> tag with EnterMode set to br.
Anyway, I have added a line of code that sets the content returned by FCKeditor to an empty string if it is a single br tag or empty p/div tag.

wwalc’s picture

It seems that the issue described by igorik has been reported here: #374386: if processEntities = false, fckeditor insert into empty drupal extarea this: <p>&#160;</p>, so it is enough to set the content to an empty string if we have <br /> tag only.

capellic’s picture

I think the "

" problem can be fixed with a FCKeditor JS variable setting?


wwalc: Thanks for taking care of the "
" issue.

igorik’s picture

Hi Capellic, thanks for your module.

I looked at it, but IMHO is better use $op == 'validate' instead 'presave'

It is because with $op == 'presave' it solve only storing empty tags, not validation if the textarea (if it is required) is empty or not.
Example: If I have some textarea set as required, but fckeditor inserts there empty tags, - removing these tags *AFTER* validation doesn't help that required textare will be empty.

But if we remove these tags before validation, content of the textarea is checked and if it will be empty, node is not stored and user have to insert a content there.


wwalc’s picture

@igorik - check the latest dev release.

Here's the solution that I have used:
(similar trick is used in 6--2 and 5--2)

There is no need to touch the fckeditor.module file, it can be fixed when data is passed from FCKeditor back to the textarea.

@capellic - yeah, it should work this way, however it doesn't, due to a bug (single br tag isn't considered as an empty paragraph). IgnoreEmptyParagraphValue is already set to true by default in FCKeditor.

igorik’s picture

hi wwalc

thanks for the solution, however, it doesn't solve what I wrote about:

Example: If I have some textarea set as required, but fckeditor inserts there empty tags, - removing these tags *AFTER* validation(before storing) doesn't help that required textare will be stored empty.

what you think?

wwalc’s picture

Status: Fixed » Active

Thanks igorik for not giving up :-) I still think this can be completely fixed on the javascript side. Unfortunately I have just fixed that part of code which is executed when FCKeditor is manually switched to plain text field and forgot about the most obvious case when someone simply submits the form without doing anything.

Check the latest version of that file: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/fckeditor/f...
(switch to other branch if you were using a different version of the FCKeditor module than 6.x-2.x)

igorik’s picture


with latest file from cvs it works exactly as you told! Great! :)

Thanks a lot for your work.


capellic’s picture

@igorik - Thanks for the module writing tips and keeping on this issue. I had since discovered that my little module was throwing all sorts of PHP errors.

@wwalc - Thanks for the fix. I have updated my install with the fckeditor.utils.js file per #9 and it seems to be working well. I really like FCKeditor 2 --- especially with how easy it is to override --- very cool stuff indeed.

wwalc’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

botimer’s picture

Status: Closed (fixed) » Needs review

I have run into this issue outside of Drupal and did some research. There was already an existing ticket, so I have attached a patch to it to resolve the issue.

The problem was that the "padding node" was not being pruned properly from the content, but rather always emitted. This is worth noting outside of the Drupal fckeditor.utils.js fix because the FCK.GetXHTML() method in 2.6.x is forcing the content to dirty, even without changes. This causes problems with anything that reads the editor contents, including autosave implementations and so on. The patch attached to the ticket also resolves this. My hope is that this patch will be merged for the FCKeditor 2.6.5 release.

See the FCKeditor ticket for more details:


wwalc’s picture

Status: Needs review » Closed (fixed)

@botimer - looks interesting, however I'd prefer to have this ticket closed, because this issue has been fixed in the Drupal module (dirty workaround, but it works) and even if it will be fixed in FCKeditor, I will not revert it to maintain compatibility with older versions of editor.

Anyway, it would be very nice to have it fixed in the FCKeditor itself so thanks for the patch.