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:

http://www.fckeditor.net/forums/viewtopic.php?f=5&t=11485

And person was having the same issue:

http://drupal.org/node/331891

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

<?php
rtrim
($body, "<br />");
?>
Files: 
CommentFileSizeAuthor
#2 fckeditor_strip_trailing_br_tag.zip2.08 KBcapellic

Comments

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)

StatusFileSize
new2.08 KB

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.

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.

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.

I think the "

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

http://docs.fckeditor.net/FCKeditor_2.x/Developers_Guide/Configuration/C...

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

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.

Igorik
http://www.somvprahe.sk

@igorik - check the latest dev release.

Here's the solution that I have used:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/fckeditor/f...
(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.

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?
Igorik

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)

Hi

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

Thanks a lot for your work.

Igorik

@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.

Status:Active» Fixed

Status:Fixed» Closed (fixed)

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

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:

http://dev.fckeditor.net/ticket/2522

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.