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> </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.
Comment | File | Size | Author |
---|---|---|---|
#91 | html_tags_not_escaped_in_issue_titles.png | 3.69 KB | klonos |
#88 | 2013-10-23_1604.png | 22.67 KB | dandolino |
#79 | wysiwyg-non-empty-tags.550428.79.patch | 1.32 KB | TwoD |
#77 | niceditor-example.jpg | 10.61 KB | calefilm |
Comments
Comment #1
bigbob446 CreditAttribution: bigbob446 commentedThe part that was added was intermpteteda s html lol....
should be:
all I know is that
<p> </p>
code is added to my text areas automatically.Comment #2
uomeds CreditAttribution: uomeds commentedI 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> </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> </p>
in the field.Any solution to stopping this? There has to be a way to fix it.
Thanks.
Comment #3
uomeds CreditAttribution: uomeds commentedWhat about integrating a word filter type php script into WYSIWYG such that it says:
If the contents of the form are only
<p> </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?
Comment #4
uomeds CreditAttribution: uomeds commentedAh 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.
Comment #5
TwoDI 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.
Comment #6
bigbob446 CreditAttribution: bigbob446 commentedThe 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.
Comment #7
sunhttp://docs.fckeditor.net/FCKeditor_2.x/Developers_Guide/Configuration/C...
Comment #8
TwoD@sun, I'm not sure enabling that will work since there's a
in the paragraph, but it's worth a try. If I can reproduce the issue first...Comment #9
uomeds CreditAttribution: uomeds commentedTo 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> </p>
Like Bob said though, TinyMCE doesn't do it, so that's what I'm sticking to. No worries here.
Comment #10
bigbob446 CreditAttribution: bigbob446 commented@sun
I tired this earlier on my own with no joy... Good idea though.
Comment #11
TravisCarden CreditAttribution: TravisCarden commentedI 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 (
) 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:
This just tests if the value of
$node->field_example
is exactly<p> </p>
, and if it is, resets it toNULL
. That way I can at least test helpfully for an empty value in my template files. Hope that helps someone.Comment #12
netsensei CreditAttribution: netsensei commented+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.
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:
Comment #13
lias CreditAttribution: lias commentedWhat 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.
Comment #14
dogbertdp CreditAttribution: dogbertdp commentednetsensei,
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.
In my testing it appears to work fine with Firefox3 and IE6. Does anyone see an issue with this code?
Thanks,
Mike Hays
Comment #15
netsensei CreditAttribution: netsensei commentedThanks 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.
Comment #16
beertje CreditAttribution: beertje commentedI 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:
Comment #17
jjesus CreditAttribution: jjesus commented+1 subscribing. I noticed the same problem as described in issue title. FCK Editor Version 2.6.4.
Comment #18
ressa CreditAttribution: ressa commentedThanks Travis, your code fixed it. Note to others: If you want to check the body, it should look like this:
I also had to disable rich-text (below the field) to be able to delete the space, and save the post without it.
Comment #19
TwoDAdapted the RegExp from #16 to JavaScript and used it to filter all the output from the editor.
Comment #20
TimG1 CreditAttribution: TimG1 commentedsubscribing
Comment #21
sun1) 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.
Comment #22
TwoDHow about this?
Comment #23
darthf1 CreditAttribution: darthf1 commentedsubscribing. I'm noticing this issue with the 6.x-2.x-dev version and CKeditor. Sometimes it creates a
<p> </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)
Comment #24
geerlingguy CreditAttribution: geerlingguy commentedSubscribe: See similar (possibly duplicate?) issue: #723644: <p> </p> Added Before and After <hr /> tags...
Comment #25
darthf1 CreditAttribution: darthf1 commented@Twod: I looked at your fix at #22, but this is mainly configured for FCKeditor. Can u create a patch for CKeditor too?
Comment #26
TwoDIt 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> </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.)Comment #27
jaysadie CreditAttribution: jaysadie commentedTwoD: 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';
Comment #28
jerry CreditAttribution: jerry commentedSubscribing.
Comment #29
TwoDHere'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.
Comment #30
TwoDAnd here's the cleaned up version, I really need to remove old patches....
Comment #31
daphshez CreditAttribution: daphshez commentedSubscribing.
Comment #32
Karol Haltenberger CreditAttribution: Karol Haltenberger commentedIn my case (CKEditor 3.2.1.5372) I had to extend the search pattern with a carriage-return and a newline:
Comment #33
David Lesieur CreditAttribution: David Lesieur commentedRe-rolled #30 with Ypthor's addition to the pattern (I also had the issue with CKEditor 3.2.1).
Comment #34
jtsnow CreditAttribution: jtsnow commentedPatch in #33 works great for me using CKEditor 3.3.1.
Note: It doesn't work in FireFox if the FireBug console is enabled.
Comment #35
jack.r.abbit CreditAttribution: jack.r.abbit commentedPatch in #33 works for me using FCKEditor
Thanks
Comment #36
SergFromSD CreditAttribution: SergFromSD commentedDavid,
Sorry for the dumb question but how do I apply your patch to my durpal installation?
Comment #37
David Lesieur CreditAttribution: David Lesieur commented@senorbond: http://drupal.org/patch/apply
Comment #38
idflood CreditAttribution: idflood commentedSubscribing.
Comment #39
SergFromSD CreditAttribution: SergFromSD commentedThanks David!
Comment #40
Vidus CreditAttribution: Vidus commentedThanks 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.
Comment #41
TwoDRe-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.
Comment #42
R2-D8 CreditAttribution: R2-D8 commentedThe 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)
Comment #43
Vidus CreditAttribution: Vidus commentedI've noticed the same HTML issue with Tiny MCE. The issue appears to be when users paste from Word without using "Paste from Word."
Comment #44
kbk CreditAttribution: kbk commentedPatch at #41 worked for me. The issue is now over a year old, will this be committed soon?
Thanks to the problem solvers!
Comment #45
mandclu CreditAttribution: mandclu commentedI'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.
Comment #46
TwoDNo, 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.
Comment #47
jmcclelland CreditAttribution: jmcclelland commentedThe patch in comment #41 works for me.
jamie
Comment #48
TwoDI 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.
Comment #49
TwoDThe patch in #41 did have a problem in the CKEditor implementation.
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.
Comment #50
sunI'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?
Comment #51
TwoDLike 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.
Comment #52
sunGood 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.
Comment #53
R2-D8 CreditAttribution: R2-D8 commented+1
"Known issues" could also help deciding individually which modules to use:
wysiwyg with libraries
or
independent version of wysiwyg-editors like ckeditor
Comment #54
sunSee #965538: Add a list of Known issues somewhere
Comment #55
NitebreedI just downloaded the latest nightly build of CKEditor, and the problem is gone now!
Comment #56
tarzadon CreditAttribution: tarzadon commentedI 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.
Comment #57
Stomper CreditAttribution: Stomper commentedI 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.
Comment #59
eft CreditAttribution: eft commentedI am running CKEeditor 3.5.2 and I still get
<p> </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.
Comment #60
Sivaji_Ganesh_Jojodae CreditAttribution: Sivaji_Ganesh_Jojodae commentedUpgrade to CKEditor 3.5.3 and a cache clear did the trick for me.
Comment #61
Stomper CreditAttribution: Stomper commentedWill need to look into that. Can WYSIWYG support auto checking for editor updates and suggesting updates on the status page?
Comment #62
Danny EnglanderI updated CKedtior to latest stable & also tried the nightly build and the latest dev of Wysiwyg but am also having this issue.
Comment #63
TwoDPlease try the patch in #49.
Comment #64
bryancasler CreditAttribution: bryancasler commentedTwoD could that patch be applied to 7.x?
Comment #65
TwoD@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.)
Comment #66
Danny EnglanderDoes 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?
Comment #67
bryancasler CreditAttribution: bryancasler commentedApplied 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.
Comment #68
TwoD@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.
Comment #69
idflood CreditAttribution: idflood commentedThis still happens on a d7 with latest ckeditor... As #67, I will apply patch in #49 and see if it fixes the issue.
Comment #70
barraponto CreditAttribution: barraponto commentedDo we still care about this? FCKEditor is history, its development continued in CKEditor. I suggest we just close this issue.
Comment #71
idflood CreditAttribution: idflood commentedMaybe 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.
Comment #72
bryancasler CreditAttribution: bryancasler commentedCross referencing this post from the CKEditor module #669114: CKeditor adding <p> </p>
Comment #73
gagarine CreditAttribution: gagarine commentedPatch #49 works for me on D7.
Comment #74
Dentorat CreditAttribution: Dentorat commentedI am using Wysiwyg and CKEditor on Drupal 7 alongside with htmlpurifier and patch #49 did not work for me
Comment #75
John Bickar CreditAttribution: John Bickar commentedTested patch in #49 against wysiwyg-7.x-2.1+38-dev and it resolves the issue.
Comment #76
kbk CreditAttribution: kbk commentedFor 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
Comment #77
calefilm CreditAttribution: calefilm commentedYou 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?Comment #78
bryancasler CreditAttribution: bryancasler commented#77 I do not think it's the same issue
Comment #79
TwoDI 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?
Comment #80
caschbre CreditAttribution: caschbre commentedI tested this patch against 7.x-2.2 and here are my findings so far...
When the editor initially loads the
<p> </p>
is removed. However I'm also using the dev release of wysiwyg_template and when a template is inserted a<p> </p>
is inserted before and after the template and not getting removed.Is that expected?
Comment #81
TwoDThe 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.
Comment #82
caschbre CreditAttribution: caschbre commentedI 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?
Comment #83
TwoDDo 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.
Comment #84
caschbre CreditAttribution: caschbre commentedSure... 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.
Then I'll click the Disable rich-text link below the wysiwyg editor. Here's the markup in the textbox after disabling wysiwyg.
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.
Comment #85
klonosIn my case (using latest devs of core and all related modules) it was adding a non-breaking space (
) 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
(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
). 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?
Comment #86
scott.browne CreditAttribution: scott.browne commented#42 Your solution didn't work for me.
Comment #87
klonos@scott@coverclub...: #42 is from back in 2010. Can you please give a go to #79 and report back how that worked?
Comment #88
dandolino CreditAttribution: dandolino commentedI 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.
Comment #88.0
dandolino CreditAttribution: dandolino commented...wrapped
in
tags.
Comment #89
klonos#79 has been working fine for months now in a couple of sites I have it deployed. Please commit.
Comment #90
klonos...so that people don't try old patches.
Comment #91
klonos...attempting to fix how the issue title is displayed in the queue:
Comment #92
klonosNope, that didn't fix it. Filed an issue for it: #2156041: Display issue titles that contain html tags properly in the issue queue.
Comment #93
MXT#79 does not work for me:
<p> </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
Comment #94
TwoD@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.
Comment #95
MXT@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> </p> <p> </p> <p> </p>
paragraphs.Comment #96
TwoDAre 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> </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.
Comment #97
int_ua CreditAttribution: int_ua commentedTwoD, can you please add the actual code for the setting?
Comment #98
TwoDComment #99
simba909 CreditAttribution: simba909 commentedCan 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.
Comment #100
mgiffordComment #101
DrupalDope CreditAttribution: DrupalDope commentedHello,
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 ?
Comment #102
plato1123 CreditAttribution: plato1123 commented@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