I created a basic page with the plain text filter selected (no associated wysiwyg profile) with this body:

This is

a document
with line

breaks in it.

and then switched to a text format that did have a Wysiwyg profile associated with it. The line breaks did not display in the wysiwyg editor. When I switched back to the plain text filter, the text was then:

<p>This is a document with line breaks in it.</p>

I got the same result with content that had been written before its selected text format became associated with a Wysiwyg profile. Editing the content destroys the formatting.

Is it possible to avoid this automatic destructive editing? In other words, can I restrict the editors (I've tried TinyMCE and CKeditor with the same result) to only make changes that are explicitly initiated by the user? I selected the "Preformatted" option and deselected the "Remove linebreaks" options with no change in this behaviour.

The reason I'm asking is that my enthusiastic users started adding content before "Add Wysiwyg" made it in to a sprint list.

I have now created new text formats (e.g. "Filtered HTML - Wysiwyg") so that the original filters do not invoke this destruction on editing existing content, but it still means that existing content needs to be manually reformatted before a user can take advantage of Wysiwyg.

Whether avoiding automatic destructive editing is possible or not, should the FAQ have an item on it? (I couldn't see one and humbly apologise if there is.)

Comments

TwoD’s picture

Status: Active » Fixed

Short answer: No.

Medium answer: It's manageable, if you use the Wysiwyg Linebreaks module.

Long answer: Not all destructive reformatting is avoidable, beacause editors completely re-builds the markup from scratch to be able to filter it, but you can use plugins to simulate what the "Linebreak converter" filter does to whitespaces. Without such a plugin WYSIWYG editors have no clue that your serverside content filters will convert basic linebreaks to actual <br /> and <p></p> tags. Since the HTML specs say multiple whitespaces (normal space, linebreaks, tabs, etc) can be collapsed down to single spaces before/during markup parsing, editors are free to do this too. (Some simpler ones use built-in browser functions for parsing, others have their own parsers to avoid browser bugs.)

What the Wysiwyg linebreaks module does is to provide an editor plugin for converting linebreaks to actual <br /> and <p></p> tags before the editors do their parsing, and then convert those tags back to linebreaks after the editor has generated the markup. This is very helpful for users which either can't convert their existing content to not use the linebreak converter filter (since the editors know where to put them anyway), or if they would like to semi-automatically convert their content as it is being edited (and then finally disable the filter). The module has a few conversion modes to suit these use cases, but it's author is probably better than me at explaining those.

Feel free to add something about this to the FAQ, that would be great. I've aswered this question, or variations of it, in a lot of issues here so I should probably have added it there long ago...

crantok’s picture

Added this to the FAQ:

Q: Where did my linebreaks go? Editing old content after installation

A: Drupal preserves exactly what it is saved in content fields and allows admins to configure, and authors to select, Text formats in order to modify how content is displayed to users. If you are used to this strict preservation of your content then you may experience culture shock when you start using a client-side editor like those available for use through Wysiwyg. Client-side editors designed to produce HTML may remove linebreaks (which are meaningless in HTML) destroying the exsting formatting. If you are editing content saved before installing a client-side editor then you may benefit from using the Wysiwyg Linebreaks module which is designed to preserve linebreaks in either of two ways.

TwoD’s picture

Excellent, thank you!

Status: Fixed » Closed (fixed)

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

Anonymous’s picture

Issue summary: View changes

input filter -> text format