Posted by ManyNancy on November 2, 2009 at 2:48am
Jump to:
| Project: | Wysiwyg |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I installed CK editor and all the line breaks in my nodes disappeared when viewing with ckeditor. I was previously using bbcode input format to handle linebreaks as br tags, not paragraph tags. Can WYSIWYG not recognize br tags?
I disabled the remove line breaks checkbox in the ck editor settings already, it didn't help!
Help!
Thanks.
Comments
#1
The BBCode filter should not have anything to do with linebreaks I think, I'm assuming you mean the 'line break converter' filter.
If you were using the 'line break converter' filter on your input format (transforms
\ninto<p>or<br />) you will get problems. If there are are only linebreaks (\n) in your source, any WYSIWYG editor will simply treat them as source formatting just like the browser does. The WYSIWYG editor will correctly insert<p>or<br />tags where appropriate and only use linebreaks for its own source formatting, as they will normally not be visible when the node is rendered. But, if you've previously used the 'line break converter' filter, the editor does not know where you actually wanted break/paragraph tags and just treat it all as one big paragraph. It gets a whole lot worse if you have the 'line break converter' filter active when using a WYSIWYG editor. Then both the break/paragraph tags inserted by the editor, and the source formatting linebreaks (converted to break/paragraph tags) will be visible in the rendered node.So, when using a WYSIWYG editor turn of 'line break converter' and use the editor to insert breaks/paragraphs where you want them.
If you have tons of content already using an input format where 'line break converter' was active (and thus contain no
<br>/<p>tags), you might want to keep the converter filter on, and use the helper-module developed in #513998: Plugin to convert p- and br-tags to newlines. (Don't know if it fully works with CKEditor yet.) Note that doing so will add an extra step to the text processing on the client. Your original content with only linbreaks will be converted to using break/paragraph tags before being passed to the editor, and the edited content will those tags replaced by linebreaks when retrieved from the editor. Thus your content will still be saved without the break/paragraph tags in the database and rendered as having them when the node is viewed thanks to the 'line break converter' filter.There's an open issue [with a workaround/patch] in Drupal Core about that filter not being able to handle very large text in all circumstances though.
#2
The bbcode filter also handles newlines and I was using it to filter all newlines to br, with no p at all.
Anyway surely there's a way to get the editor to insert
\ninstead of p or br?Also according to ckeditor's official website it can use bbcode as well. I also have a ton of content in BBcode, not looking forward to rewriting everything.
#3
I didn't realize the BBCode module also handled linebreaks, thought they left that up to the builtin Drupal filter.
CKEditor does not support BBCode by default (the string 'bbcode', or variations of it, does not exist in the entire source tree). One must write a custom Data Processor to explicitly handle BBCode (and most likely also deactivate the supplied HTML Data Processor). We currently override two methods of the Data processor to let Drupal plugins access the WYSIWYG area's [X]HTML, but that should not cause a problem if another Data Processor is used. Some Drupal plugins might expect the 'raw' data format (not the XHTML representation in WYSIWYG mode) to be XHTML as well, but those plugins would just have to be deactivated.
I'm afraid you'll have to stick with FCKeditor (or any other editor supporting BBCode) unless you have more luck than me and find a BBCode plugin/Data Processor for CKEditor.
#4
Thanks, gotcha.
#5
Automatically closed -- issue fixed for 2 weeks with no activity.
#6
This issue comes up again and again and most of the workarounds are troublesome for the following situation:
- have created lots of content where "line break converter" was active
- want to be able to edit that old content in WYSIWYG *without* losing the line breaks
Many of the workarounds suggest ways to keep the line breaks by only using text editors for edits (some involving creating different text format types).
There are also workarounds that involve installing more modules / helper modules to convert the old format (adding "break" and "paragraph" html to the old content). But that is painful for people like me that don't have time / expertise to do this sort of thing.
So... how about this enhancement to CKeditor which I understand was already added to FCKeditor...
>Posted by gpk on June 22, 2010 at 7:48pm
>The original problem is solved in FCKeditor module 6.x-2.1 with a new option
>"Automatically detect and convert plain text:" under Cleanup and output in each profile's
>settings. See #575626: Activating Fckeditor breaks existing node formatting.
This would be *so* helpful. You could leave the line break converter active. THEN, any time someone edits their old content (where they relied on line breaks for formatting -- and for 'line break converter' to handle the display proper), they can be put straight into the WYSIWYG which will convert the old text properly (adding in "break" and "paragraph" html as appropriate)!!
Really, really want this! :-)
#7
The change you're talking about is in commit 773ef613d94efd2379b4f2a5aa327d082f0aa7fe.
Wysiwyg does not preprocess content based on editor settings now, but it might be worth considering adding a step like that.
At some point we might also integrate the plugins from http://drupal.org/project/wysiwyg_linebreaks, which already let you choose between forcing content to be stored with linebreaks only, or with the markup tags.
No expertise should be required to install that module btw. Drop it like any other Drupal module, enable the plugin under "Buttons and plugins" when configuring the editor and the rest should take care of itself.