Hello,

I have a node were I added CCK text area (multi row) field. It is optional and ideally if some one doesn't use it the field label should not show up if a user didn't add any text to the text area. This is the way it works normally, and the way it was working up untill a certain point. unfortunatly I don't know what changed globally all I know is that "<p>&nbsp;</p>" (minus the quotes) code is added to my text areas automatically. This creats a probleme because now even thow there is not text displayed Drupal now shows the feild labels while viewing the nodes. IT IS ANOYING and I don't know how to fix it.

I have subsiquently switched to TINYMCE and have not encounterd the issue. So the lazy solution is to switch editors... However, this isue should be investigated. I read a couple of things in onther posts that indicated that this could be and inhearent issue with FCK Editor I am not sure.

The wiered thing is it wasn't doing this initially and then it started to. IDK

Anyway if anyone has an explenation that would be awesome. If anyone has a fix that would be supper awesome.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bigbob446’s picture

The part that was added was intermpteteda s html lol....

all I know is that "

" (minus the quotes) code is added to my text areas automatically.

should be:
all I know is that <p>&nbsp;</p> code is added to my text areas automatically.

uomeds’s picture

I was JUST about to post the same problem. I am using FCKeditor and Advanced Profiles with Panel based User Profiles. It is working well, but the extra <p>&nbsp;</p> is forcing blank panels users haven't filled out to show up unnecessarily.

My only solution so far has been to return the fields that most users probably won't fill out to plain text format, but this is half defeating the purpose of WYSIWYG.

If anyone wants to see it for themselves, just return any blank WYSIWYG field to plain text and you will get a <p>&nbsp;</p> in the field.

Any solution to stopping this? There has to be a way to fix it.

Thanks.

uomeds’s picture

What about integrating a word filter type php script into WYSIWYG such that it says:

If the contents of the form are only <p>&nbsp;</p> and no other characters, enter no data for that field.

I'm not good at doing script, but it should be possible to integrate a fix this way shouldn't it?

uomeds’s picture

Ah forget it. I just saw what you said Bob about TinyMCE working so I switched to that and my problem disappeared.

Text fields also show up at a much better height with tinymce - they were huge with fckeditor.

So I'm done with fck and my problem's solved.

TwoD’s picture

Status: Active » Postponed (maintainer needs more info)

I am unable to reproduce this using any editor in Wysiwyg 6.x-2.x-dev in FF3 or IE8. Would you mind testing with the latest development snapshot? I'll test with 6x-2.0 as soon as I can.

Which browsers have you tested with?
Which editor settings/plugins/buttons were enabled?

Some editors might not like having an empty editing area (might disrupt styles and maybe cursor positioning) so they force that in there. Other editors might see it as an unneeded tag and simply remove it... If anyone has a site online where this happens, I'd be happy to take a look and try to trace it down.

bigbob446’s picture

The only editor that seems to do it is FCK Editor. I only tested it wiht IE8. It seemed to hapen only with FCK editor (most recent version) and I didn't enable any special settings. Just added it used the settings as is. and it prodcued that response. The wiered thing was it didn't seem to do this untill I added some views with views slidewhow going. I think. I am not sure I didn't really pay really close attention. I had all the modules enabled but I only noticed the problem after I had created some views that utilize views slideshow. Not sure if that has anything to do with this.

I did see some info on the FCK Editor website about this issue so it could be in hearant to the editor.

Again my work around was to switch to TyneMCE... my only gripe is that TyneMCE doesn't show multi-level buleted list properly while editing. I am building a site that will be maintained and updated by Non-Web Savy people and I don't want them getting confused. You know what I mean.

I have a good enough solution, and so I am moving forward... I am behind the 8 ball so I do not have time to mess around with the Dev version but after I finish I can go back and try... Perhaps some one else who is encountereing the problem can give it a shot befor I will get back to it.

sun’s picture

TwoD’s picture

@sun, I'm not sure enabling that will work since there's a &nbsp; in the paragraph, but it's worth a try. If I can reproduce the issue first...

uomeds’s picture

To reproduce:

1. install advanced profile kit with panels
2. install fck wysiwyg
3. enable fck mode for the advanced profile multi-line text fields
4. save a profile with fck entry left blank.
5. view the profile in question - all fields assigned to fck will show up regardless of if they have content or not
6. switch fck fields that are showing up despite being blank to plain text
7. viewing profile should show all these fields now contain <p>&nbsp;</p>

Like Bob said though, TinyMCE doesn't do it, so that's what I'm sticking to. No worries here.

bigbob446’s picture

@sun

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

I tired this earlier on my own with no joy... Good idea though.

TravisCarden’s picture

I believe FCKeditor uses this code to force a paragraph into the DOM until you type something into it. The IgnoreEmptyParagraphValue option unfortunately doesn't seem to apply to paragraphs with a non-breaking space (&nbsp;) in them. The new CKEditor 3.0, however, appears to have corrected all this such that an empty editor submits no code at all. Until we can all upgrade to CKEditor, here's a temporary solution I've been using:

Workaround:

I've been using something like the following in my theme's template.php:

function theme_preprocess_node(&$vars, $hook) {
  if ($vars['node']->field_example[0]['value'] != '<p>&nbsp;</p>') $vars['node']->field_example[0]['value'] = NULL;
}

This just tests if the value of $node->field_example is exactly <p>&nbsp;</p>, and if it is, resets it to NULL. That way I can at least test helpfully for an empty value in my template files. Hope that helps someone.

netsensei’s picture

+1

Me and my colleagues noticed the same issue. FCKeditor adds excessive

 

tags when a field is left empty. Annoying. I also found this issue which contains a crude fix: #372150: break tag shows up in empty Body field after saving

This is clearly an FCKEditor issue. So it should be fixed there or maybe at the wysiwyg level. But I wanted to get it fixed in the meantime nonetheless without losing much time: clients do use FCKEditor and it bugs them and me. So I expanded the helper module from 372150 into something which functions a bit better.

Here's the code. Just make a new module strip_fck.module with strip_fck.info.

<?php

/**
 * Implementation of hook_nodeapi().
 */
function strip_fck_nodeapi(&$node, $op, $teaser, $page) {
  switch ($op) {
    case 'validate':
    case 'presave':
	  strip_fck_node($node);
      break;	
  }
}

/**
 * Find all the content fields in the node object and strip them of FKEditor added excessive htm
 **/
function strip_fck_node(&$node) {
  $fields = array_keys(get_object_vars($node));
  foreach ($fields as $field) {
    // body and teaser field
	if (is_string($node->{$field})) {
	  $node->{$field} = strip_fck_strip_value($node->{$field});
	}

	// CCK fields
	if (is_array($node->{$field})) {
	  foreach ($node->{$field} as $key => $item) {
		if (is_array($node->{$field}[$key])) {
 	      foreach ($node->{$field}[$key] as $fieldname => $fieldvalue) {
   		    $node->{$field}[$key][$fieldname] = strip_fck_strip_value($fieldvalue);
	      }
        }
      }
    }
  }	
}

/**
 * Strip fields with content <p>&nbsp;</p>, <p></p>, <p> </p>, <br> or <br /> 
 **/
function strip_fck_strip_value($value) {
  return preg_replace('/^(\<p\>(\&nbsp\;|(\s)*)\<\/p\>|\<br(\s\/)?\>)$/', '', $value);
}

?>

Of course, this should be obsolete as soon as we get CKEditor support in Drupal. Or a fix gets added somewhere else.

** edit **

Just thinking: tempering with user info in validate/presave isn't really the Drupal way to go, so you might want to consider using alter instead:

  switch ($op) {
    case 'alter':
	  strip_fck_node($node);
      break;	
  }
lias’s picture

What I've noticed is that when I use plain text for my cck text field with fckeditor that the

will show up even when text is there or not. When I set the cck text field to filtered the

was generated as html and won't show up since it's used to format the content.

dogbertdp’s picture

netsensei,
Thanks for the module in #12, it has helped me greatly, but I have found an issue with it. I have a cck number field on one of my nodes. For some reason, the "strip_fck" module as written above causes this field to populate with a zero if the user leaves it blank (it isn't a required field). I find this strange as the field doesn't contain a paragraph with a nbsp and isn't using FCKeditor.

My fix is to wrap:

$node->{$field}[$key][$fieldname] = strip_fck_strip_value($fieldvalue);

in an IF statement that only lets through a $fieldname that is a paragraph with a nbsp.

    if ( strcmp($fieldvalue, "<p>&nbsp;</p>") == 0 ) {
      $node->{$field}[$key][$fieldname] = strip_fck_strip_value($fieldvalue);
    }

In my testing it appears to work fine with Firefox3 and IE6. Does anyone see an issue with this code?

Thanks,
Mike Hays

netsensei’s picture

Thanks for testing the code!

I've noticed some issues with it. I'm going to have to refactor my code a bit. strip_fck_strip_value() function contains a preg_replace which should only omit the value of the field if it meets the conditions in the regex. Looks like it acts strange on numeric fields and such.

Remember, this is just bandage for a problem which should get fixed in fckeditor.

beertje’s picture

I made some customisations for the module to work with multiple non text cck fields AND for cck to ommit empty fields in the node view:

<?php

/**
* Implementation of hook_nodeapi().
*/
function strip_fck_nodeapi(&$node, $op, $teaser, $page) {
  switch ($op) {
    case 'validate':
    case 'presave':
      strip_fck_node($node);
      break;
  }
}

/**
* Find all the content fields in the node object and strip them of FKEditor added excessive htm
**/
function strip_fck_node(&$node) {
  $fields = array_keys(get_object_vars($node));
  foreach ($fields as $field) {
    // body and teaser field
    if (is_string($node->{$field})) {
      $node->{$field} = strip_fck_strip_value($node->{$field});
    }

    // CCK fields
    if (is_array($node->{$field})) {
      foreach ($node->{$field} as $key => $item) {
        if (is_array($node->{$field}[$key])) {
           foreach ($node->{$field}[$key] as $fieldname => $fieldvalue) {
               if (is_string($node->{$field}[$key][$fieldname])) {
                 $node->{$field}[$key][$fieldname] = strip_fck_strip_value($fieldvalue);
                 if (empty($node->{$field}[$key][$fieldname])) {
                   $node->{$field}[$key][$fieldname] = null;
                 }
               }
          }
        }
      }
    }
  }
}

/**
* Strip fields with content <p>&nbsp;</p>, <p></p>, <p> </p>, <br> or <br />
**/
function strip_fck_strip_value($value) {
  return preg_replace('/^(\<p\>(\&nbsp\;|(\s)*)\<\/p\>|\<br(\s\/)?\>)$/', '', $value);
}
?>
jjesus’s picture

+1 subscribing. I noticed the same problem as described in issue title. FCK Editor Version 2.6.4.

ressa’s picture

Thanks Travis, your code fixed it. Note to others: If you want to check the body, it should look like this:

function theme_preprocess_node(&$vars, $hook) {
  if ($vars['node']->field_body[0]['value'] != '<p>&nbsp;</p>') $vars['node']->field_body[0]['value'] = NULL;
}

I also had to disable rich-text (below the field) to be able to delete the space, and save the post without it.

TwoD’s picture

Status: Postponed (maintainer needs more info) » Needs review
FileSize
812 bytes

Adapted the RegExp from #16 to JavaScript and used it to filter all the output from the editor.

TimG1’s picture

subscribing

sun’s picture

Status: Needs review » Needs work
+++ editors/js/fckeditor-2.6.js	21 Jan 2010 19:26:11 -0000
@@ -79,7 +79,8 @@ Drupal.wysiwyg.editor.instance.fckeditor
+      // #550428: Fix non-empty fields.
+      return data.replace(/^(?:<p>(?:&nbsp;|\s*)<\/p>|<br(?:\s\/)?)$/i, '');

1) We're missing a closing > for the BR here.

2) CVS history already contains the issue number, we never add it to inline comments. Instead, the comment should be more concise about what is being done here and most importantly, why. It's probably also worth to mention that this seems to have been fixed for CKEditor, so doesn't apply there.

Powered by Dreditor.

TwoD’s picture

Status: Needs work » Needs review
FileSize
923 bytes

How about this?

darthf1’s picture

subscribing. I'm noticing this issue with the 6.x-2.x-dev version and CKeditor. Sometimes it creates a <p>&nbsp;</p> which causes an extra empty line.

I see this topic is mainly about FCKeditor, so perhaps this is a WYSIWYG-wide bug? And not a editor-specific bug? Or perhaps a fckeditor/ckeditor, since its from the same developer.

So i guess the 2nd line of comment from the last patch is incorrect (// to allow truly empty fields. This seems to be fixed for CKEditor)

geerlingguy’s picture

Subscribe: See similar (possibly duplicate?) issue: #723644: <p>&nbsp;</p> Added Before and After <hr /> tags...

darthf1’s picture

@Twod: I looked at your fix at #22, but this is mainly configured for FCKeditor. Can u create a patch for CKeditor too?

TwoD’s picture

It would be easy to put the fix in CKEditor too, but if this problem starts to pop up for other editors as well, maybe we should do it for all editors in one go? If we place the code outside the editor implementations (wysiwyg.js) we could make the substitution run after each editor has been detached, but then it becomes impossible to explicitly input <p>&nbsp;</p> even when no editor appears to be active (Wysiwyg attaches a 'fake' editor to handle the resize bar when no real editor is active, and it too is detached before the form is submitted.)

jaysadie’s picture

TwoD: I'm glad I found this thread because I'm having the same problem with CKEditor. What's weird is that it does not happen all the time. Sometimes I create a new post and the <br /> does not get included, and other times it does. Also, if you click inside the CKEditor text field and then click on the "Change to plain text editor" link, it also adds the <br />, even if it had nothing in it before. So, from this, it must mean that JS must somehow also add the <br />, because the page was not reloaded.

Sometimes I backspace over the <br /> and then switch between "Rich text editor" and "Plain text editor" just fine, and other times it adds the <br />. Cannot find a consistent pattern here.

It sure would be nice to have this resolved.

Suggestion: Let's create a function that inspects a text field that has no visible content, and set it to an empty string. This would be for when a text field only has one or more <br />'s, or only <p>'s, or a combination of both.
Additionally we may also want to only trim trailing parts of a text field, where after some text the only tags found are <br />s and <p>s.

Maybe we can call this function something like remove_blank_trailing_tags($text);

Or, to be more versatile, create a function called remove_blank_tags($text, $section = 'all'),
where $section can be 'trailing', 'leading', 'mid', or 'all';

jerry’s picture

Subscribing.

TwoD’s picture

Title: <p>&nbsp;</p> added to empty text areas » Tags like <p>&nbsp;</p> or <br /> added to empty textareas
FileSize
2.98 KB

Here's a quick compromise of the above suggestions.
It introduces Drupal.wysiwyg.removeBlankLines(content) with the RegeExp and calls it from the FCKeditor and CKEditor implementations when content is retrieved from the editors.

CKEditor has an additional change to make sure the code runs even when no Drupal plugins are enabled. If I remember correctly, we made a change before the 2.1 release so Drupal.settings.wysiwyg.plugins[params.format] should always exist, which it didn't before, hence the check.

The tests I made with this went ok, but I'm rarely able to reproduce the non-empty-field-effect so I'm going to need some help testing it.
The patch was made against 6.x-2.x-dev but also applies to HEAD with an offset.

TwoD’s picture

FileSize
2.87 KB

And here's the cleaned up version, I really need to remove old patches....

daphshez’s picture

Subscribing.

Karol Haltenberger’s picture

In my case (CKEditor 3.2.1.5372) I had to extend the search pattern with a carriage-return and a newline:

'/^(\<p\>(\&nbsp\;|(\s)*)\<\/p\>|\<br(\s\/)?\>(\r)?(\n)?)$/'
David Lesieur’s picture

Re-rolled #30 with Ypthor's addition to the pattern (I also had the issue with CKEditor 3.2.1).

jtsnow’s picture

Patch in #33 works great for me using CKEditor 3.3.1.

Note: It doesn't work in FireFox if the FireBug console is enabled.

jack.r.abbit’s picture

Patch in #33 works for me using FCKEditor

Thanks

SergFromSD’s picture

David,

Sorry for the dumb question but how do I apply your patch to my durpal installation?

David Lesieur’s picture

idflood’s picture

Subscribing.

SergFromSD’s picture

Thanks David!

Vidus’s picture

Thanks for the fix. Trying it on my sites currently. Had a user run into same problem: using CCK editor with WYSIWYG and had issues where whole pages that were rendering had black lines in them. Removed some extra
code and the problem was fixed, but going to try the patch to see if that nixes it entirely.

TwoD’s picture

Version: 6.x-2.0 » 6.x-2.x-dev
Component: Editor - FCKeditor » Code
FileSize
3.08 KB

Re-rolled #33 and added a pattern for recognizing an empty div left by Firebug. This div didn't always show up in the generated source but caused problems for the Regular Expression.
I haven't seen this issue with editors other than FCKeditor and CKEditor yet, but I don't use them frequently. If someone spots similar issues in other editors, please post here as soon as possible so we can investigate.

R2-D8’s picture

The following mod helped me preventing ckeditor from filling unused textareas with an <br />-tag.

But this way once clicked the textareas get filled with <p><br /></p>;
no matter if there is any content.

Edit ckeditor.js;

change...

<(p|div|address|h\d|center)[^>]*>\s*

... to ...

(:?<(p|div|address|h\d|center)[^>]*>\s*)?

Taken from http://www.inetcom.ch/ckeditor-und-cck-felder-fuellt-br-leere-textfelder (German)

Vidus’s picture

I've noticed the same HTML issue with Tiny MCE. The issue appears to be when users paste from Word without using "Paste from Word."

kbk’s picture

Status: Needs review » Reviewed & tested by the community

Patch at #41 worked for me. The issue is now over a year old, will this be committed soon?
Thanks to the problem solvers!

mandclu’s picture

I'm experiencing a similar issue on a couple of my sites. It may be that I'm seeing the empty issue too, but that it hasn't caused an issue in my case.

What I'm more concerned about is that CKEditor (working within WYSIWYG) seems to always add a blank paragraph before the content. When you're creating the node it won't show you the empty paragraph, and backspacing at the top of the editor does nothing. Once you save it, however, you can see the blank paragraph (every time), and then when you go back in you can see it and delete it in the editor.

Can someone clarify if this fix will also address this issue? If not, I'll open up a new issue.

TwoD’s picture

No, the regular expressions used in this patch will not match any case where more than just the empty p and br tags are present. This patch is already on the border of attempting to fix a problem native to the editor itself. Allowing Wysiwyg to alter content wihich we know has user data in it would be going even one step closer to having to build a heuristic parser to know what to change and what to leave alone.

We'd much rather see these output problems fixed in the editor's own code so everyone can benefit from them, and we get less special cases. This non-emtpy content issue seems to be very persistent when used under Wysiwyg tho, hence the patch.
I've also noticed the empty paragraph preceding some content but I've not yet had time to dig deeper.

jmcclelland’s picture

The patch in comment #41 works for me.

jamie

TwoD’s picture

Status: Reviewed & tested by the community » Needs work

I see Sun is on a commit spree tonight! Might have found a case where this patch can cause problems, so marking as "needs work" until I can perform some tests when I get home from work.

TwoD’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
4.62 KB

The patch in #41 did have a problem in the CKEditor implementation.

+++ editors/js/ckeditor-3.0.js	28 Aug 2010 16:44:13 -0000
@@ -79,7 +79,7 @@ Drupal.wysiwyg.editor.attach.ckeditor = 
-      if (editor.dataProcessor && Drupal.settings.wysiwyg.plugins[params.format]) {

The last condition should have been moved down a step, not just removed. The custom dataProcessor is always used now, but the plugins check has been moved inside it. This prevents an error from being thrown when Drupal.settings.wysiwyg.plugins[params.format] is undefined because there are no plugins active for a format.

Just a small fix, though it looks bigger because of the added indents, so I'll return this to RTBC.

Powered by Dreditor.

sun’s picture

Status: Reviewed & tested by the community » Needs review

I'm not really convinced of this patch. Shouldn't this be fixed upstream in the CKEditor library instead?

IIRC, this would be the second extension to Wysiwyg's JavaScript API that adds a complex regular expression to manually clean up a bogus behavior. In general, doing that does not feel right - we are working around a problem instead of fixing the problem, resp. the cause.

Thus, even though the changes in this patch are relatively simple, I'm asking: At which point does this end?

TwoD’s picture

Like I've said earlier, I don't really like "fixing" it here either, but it's becoming a pain when checking for empty fields in things like Views...

It does look like the CKEditor are working on some related tickets: http://dev.ckeditor.com/ticket/5404
That together with the ignoreEmptyParagraph settings should take care of most of the problems seen here, but it looks like we'll have to wait a while.

sun’s picture

Good to hear that our considerations are aligned. :)

In that case, I'd recommend to merely "maintain" this patch here for anyone who urgently needs it. If people don't want to apply a patch and have a permanent solution instead, then everyone should work on that upstream issue/patch for the CKEditor library itself.

That said - normally, this issue would be "won't fix". I don't really like the idea of clobbering our queue even more with issues that cannot and should not be resolved in here. If something needs to be fixed upstream, then it makes little sense to have an issue in our queue that basically communicates that Wysiwyg module might be able to fix something. But then again, without keeping this issue open, I suspect we'll see many duplicates... Normally, one would attempt to resolve this conflict with a list of "Known issues" somewhere. Perhaps we should discuss such a list in a separate issue.

R2-D8’s picture

+1

"Known issues" could also help deciding individually which modules to use:

wysiwyg with libraries
or
independent version of wysiwyg-editors like ckeditor

sun’s picture

Nitebreed’s picture

I just downloaded the latest nightly build of CKEditor, and the problem is gone now!

tarzadon’s picture

I upgraded my CKEditor to 3.5 and the problem is gone as well (FF 3.6.13). However, I did check on IE8 using CKEditor 3.4.2 and the problem didn't happen there.

In views-view-fields.tpl.php, I added:
if ($field->content != "<p></p>" ):
...
endif;

to take care of all the nodes that already have "<br />" in them.

Alternatively, you can update the database field and replace the <br />'s with NULL's.

Stomper’s picture

I am running CKEditor 3.5, and after screwing up the layout in the rich text editor and trying to fix it by toggling back to plain text, I too noticed that CK had added a lot of stuff too.

Not to much of an issue if you are patient and or willing to delete and redo. Turning it rich text editing based on "full" or "filtered" html is helpful.

eft’s picture

I am running CKEeditor 3.5.2 and I still get <p>&nbsp;</p> at start of CCK text area but only after I initially save the node.

If I switch to plain text and then back to rich text and delete the extra line, then I can save the node without the issue recurring.

Sivaji_Ganesh_Jojodae’s picture

Upgrade to CKEditor 3.5.3 and a cache clear did the trick for me.

Stomper’s picture

Will need to look into that. Can WYSIWYG support auto checking for editor updates and suggesting updates on the status page?

Danny Englander’s picture

I updated CKedtior to latest stable & also tried the nightly build and the latest dev of Wysiwyg but am also having this issue.

TwoD’s picture

Please try the patch in #49.

bryancasler’s picture

TwoD could that patch be applied to 7.x?

TwoD’s picture

@animelion, yes, it should apply to 7.x. The editor implementations are currently similar enough across D5, D6 and D7 so the patch should be valid for all of them. (Expect some fuzz or offsets.)

Danny Englander’s picture

Does the patch in #49 apply against any specific 6.x version of wysiwyg? For example I am using 6.x-2.x-dev from 2011-May-05. Will it work that version?

bryancasler’s picture

Applied the patch from #49 to 7.x-2.0. Not 100% sure how to tell if it's working except to give it some time. I'll report back later.

TwoD’s picture

@highrockmedia, patches are always made against the HEADs of the master branch in git unless otherwise specified. The master branch currently corresponds to the 7.x-2.x-dev snapshot though it might be up to 12hrs behind.
I can't promise that patches will apply to a certain -dev branch, you'll simply have to test. If parts of the patch fails to apply, update to the latest snapshot of the branch. If the patch still doesn't apply, ask for it to be rerolled and/or ported back to D6.

This patch in particular mainly touches the editor implementations, so it's very likely it'll apply to older snapshots as well. If it applies cleanly, and there are no runtime errors, it's reasonable to assume it also does the job it's supposed to do.
Note the conversation in #50-#52 though.

idflood’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev

This still happens on a d7 with latest ckeditor... As #67, I will apply patch in #49 and see if it fixes the issue.

barraponto’s picture

Do we still care about this? FCKEditor is history, its development continued in CKEditor. I suggest we just close this issue.

idflood’s picture

Maybe it's just me but I had this issue with ckeditor recently. In fact it was with a specific client and I wasn't able to reproduce the issue but he described exactly what this is about. He had empty paragraph being inserted at the top/bottom of some posts when using the wysiwyg.

bryancasler’s picture

Cross referencing this post from the CKEditor module #669114: CKeditor adding <p> &nbsp;</p>

gagarine’s picture

Status: Needs review » Reviewed & tested by the community

Patch #49 works for me on D7.

Dentorat’s picture

Status: Reviewed & tested by the community » Needs work

I am using Wysiwyg and CKEditor on Drupal 7 alongside with htmlpurifier and patch #49 did not work for me

John Bickar’s picture

Status: Needs work » Reviewed & tested by the community

Tested patch in #49 against wysiwyg-7.x-2.1+38-dev and it resolves the issue.

kbk’s picture

For some reason the patch in #49 is not working with my D6 install.
Wysiwyg 6.x-2.4
CKeditor 3.6.0.6902

Solved: I have no idea why, but the default for that field was set to a break tag. smh

calefilm’s picture

FileSize
10.61 KB

You requested other editors with the same issue.

I just downloaded Niceditor and cannot stand to see <br> in the text field if I have purposely disabled the rich text format for my users. Is this part of the same issue the others have experienced with fckeditor?

bryancasler’s picture

#77 I do not think it's the same issue

TwoD’s picture

Assigned: Unassigned » sun
Status: Reviewed & tested by the community » Needs review
FileSize
1.32 KB

I improved the RegExp a bit and moved the invocation of the cleanup to the detach method so now it always happens for all editors.

It looks like we still need this patch and that editors haven't improved in this regard (or we haven't found configuration options to fix their behavior).

Should we just commit this and be done with it once and for all?

caschbre’s picture

I tested this patch against 7.x-2.2 and here are my findings so far...

When the editor initially loads the <p>&nbsp;</p> is removed. However I'm also using the dev release of wysiwyg_template and when a template is inserted a <p>&nbsp;</p> is inserted before and after the template and not getting removed.

Is that expected?

TwoD’s picture

The new code in the patch only runs when an editor is detached from the original textarea, such as when the form gets submitted or one clicks "Disable rich-text". The empty p tag should not stay there if you disable the editor after inserting a template, but I'm not sure what to do about it appearing there in the first place since Wysiwyg isn't inserting them on its own.

caschbre’s picture

The empty p tag should not stay there if you disable the editor after inserting a template

I just tested this scenario and the empty p tags are still there.

What information can I provide to try and help?

Also, here are some wysiwig_editor_settings_alter items I've been toying with trying to get ckeditor to behave. Any of these getting in the way?

$settings['entities_processNumerical'] = 'force';
$settings['entities'] = FALSE;
$settings['basicEntities'] = FALSE;
TwoD’s picture

Do you have a small sample of what the complete content looks like after the editor was disabled and the empty p tag remains?
If I can get that and reproduce the results here, I should be able to determine why the p tags aren't being removed.

caschbre’s picture

Sure... so when the wysiwyg (ckeditor) first loads up everything is blank. Using wysiwyg_template I choose a template to insert. Here's the markup for that template.

<div class="widget-box">
  <h2 class="widget-item">Widget Title</h2>
  <div class="widget-item">Enter content here</div>
</div>

Then I'll click the Disable rich-text link below the wysiwyg editor. Here's the markup in the textbox after disabling wysiwyg.

<p>&nbsp;</p>
<div class="widget-box">
  <h2 class="widget-item">Widget Title</h2>
  <div class="widget-item">Enter content here</div>
</div>
<p>&nbsp;</p>

Note that this isn't happening with all of my templates. I have a template that is simply a link (anchor tag) and disabling the editor at that point I do not get the empty paragraph tags.

klonos’s picture

Title: Tags like <p>&nbsp;</p> or <br /> added to empty textareas » Tags like &nbsp; or <p>&nbsp;</p> or <br /> added to empty textareas.

In my case (using latest devs of core and all related modules) it was adding a non-breaking space (&nbsp;) in the text area. You could see that each time you edited a node with a WYSIWYG field: when the node edit form loaded the text area showed as empty, but if you switched to the "Plain text" format you'd see the &nbsp; (plain in my case - not wrapped in <p> tags).

The workaround so far was to tell my content editors that wished to leave the field empty (it was optional) was to switch to plain text mode before save and delete this "nonsense" (the &nbsp;). A really tedious task for them and they always seemed to either completely forget about it or forget the steps to work around it. This lead to breaking the site style in a couple of places which of course lead to complaints back at me :/

Anyways, the patch in #79 solved my issue and saved the day. Can we please commit that as an intermediate step towards solving this series of issues?

scott.browne’s picture

#42 Your solution didn't work for me.

klonos’s picture

@scott@coverclub...: #42 is from back in 2010. Can you please give a go to #79 and report back how that worked?

dandolino’s picture

FileSize
22.67 KB

I just discovered that in the "wysiwyg profiles" configuration for ckeditor (version 3.6.6.7689), if you check "apply source formatting" under "cleanup and output", it will actually not automatically add a "p" or "div" at the end of your content.

dandolino’s picture

Issue summary: View changes

...wrapped

 

in tags.

klonos’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

#79 has been working fine for months now in a couple of sites I have it deployed. Please commit.

klonos’s picture

...so that people don't try old patches.

klonos’s picture

Title: Tags like &nbsp; or <p>&nbsp;</p> or <br /> added to empty textareas. » Tags like "&nbsp;" or "<p>&nbsp;</p>" or "<br />" added to empty textareas.
FileSize
3.69 KB

...attempting to fix how the issue title is displayed in the queue:

issue title containing html tags messed up

klonos’s picture

MXT’s picture

Status: Reviewed & tested by the community » Needs work

#79 does not work for me: <p>&nbsp;</p> are not removed from my ckeditor textarea.

So I have to use this module to resolve for now: https://drupal.org/project/emptyparagraphkiller

(I'm using latest DEV version of wysiwyg, but 4.0.3.0eafb700 version of CKEditor -> could be this the cause?)

Thank you

TwoD’s picture

@MXT, did you save the content again after applying the patch? The empty paragraphs are only removed when the editor is being detached, which happens when you save the content.

MXT’s picture

@TwoD, yes, I've saved the content and also created new one for test adding a number of empty paragraph (pressing "enter" more times on keyboard).

An entire new comment (or node also) is saved empty of words, but full of <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> paragraphs.

TwoD’s picture

Are there any spaces before or after the p tags (at the very beginning or end of the contents)? The RegExp used in #79 won't catch those since it only targets occurrences of <p>&nbsp;</p>, possibly repeated with whitespaces in or between them, but not outside them. This is only meant to target fields left not empty unintentionally, as in if the user erases everything in it and assuming that means the editor won't put any default content in there and actually leave the field completely empty.

EDIT: Btw, activating the ignoreEmptyParagraph setting via hook_wysiwyg_editor_settings_alter() may help you here.

int_ua’s picture

TwoD, can you please add the actual code for the setting?

TwoD’s picture

/**
 * Implements hook_wysiwyg_editor_settings_alter().
 */
function mymodule_wysiwyg_editor_settings_alter(&$settings, $context) {
  if ($context['profile']->editor == 'ckeditor') {
    $settings['ignoreEmptyParagraph'] = FALSE; // Defaults to TRUE I think.
  }
}
simba909’s picture

Can this be solved by adding the fillEmptyBlocks setting from CKEditor? (See http://docs.ckeditor.com/#!/api/CKEDITOR.config-cfg-fillEmptyBlocks for info)

I've made additions to ckeditor.inc to include a nice checkbox setting for this in my local instance, if it's of use to anyone I can create a patch and upload.

mgifford’s picture

DrupalDope’s picture

Hello,

I have the exact same problem as described in #85 by klonos

I checked if I could apply patch #79, but the code has changed in the file !

Please indicate a new way of applying patch #79 ?

plato1123’s picture

@TwoD

Was there never an official release that resolved this issue? Can we get one? Thx!

edit: #93 empty paragraph killer module seems to be an acceptable work around for now https://drupal.org/project/emptyparagraphkiller