Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I tried upgrading to Wysiwyg 7.x-2.3. Previously was on 7.x-2.2, with TinyMCE 3.5.11. Installed TinyMCE 4.5.1. After, deleting the 3.5.11 profile, running update.php and flushing caches, some admin errors disappeared, the WYSIWYG header bar appeared, and the profile editor appeared. I chose a few buttons to display in the header bar.
However, linebreaks that were in the original text were not appearing after the upgrade. E.g.,
abc
def
ghi jklwas now appearing in the editor box as
abc def ghi jkl
Doing Preview showed they were indeed lost in the output.
I restored from a database backup and put back the old versions of Wysiwyg and TinyMCE. Everything OK again.
I did have the Wysiwyg_linebreaks helper module installed. I disabled that but it had no effect on the missing linebreaks as reported above.
Comments
Comment #2
TwoDFirst, there was no need to delete the profile before upgrading. 7.x-2.3 contains code to migrate profiles between supported editor versions as needed. ;)
When you say "the original text", do you mean the actual markup as show when the editor is disabled, or the contents of the editor itself?
Editors will always modify white-space in the original source markup as it is by definition [mostly] ignored when parsing HTML markup. However they may insert linebreaks
\ncharacters, not<br>HTML breaks, to format the source for readability if properly configured. Drupal's line-break to HTML br-tags filters should normally not be enabled for a format when using a WYSIWYG editor as the editor is perfectly capable of producing the proper br- or p-tags as needed in the source. If the conversion filter is enabled it will mistake the linebreaks used for source formatting for spacing inserted by the user and will needlessly replace them with additional br- and p-tags upon rendering. That's harmless though, as fixing it is a simple matter of disabling the conversion filter and trusting the editor to do its job.However, if you already have large amounts of content relying on linebreaks (
\n) being converted to HTML tags to look good, that's what the WYSIWYG Linebreaks module and either of its plugins are for. It can be used in two different modes (only one of its plugins should be enabled at a time), and which one depends on what's convienient and whether you'd like to keep the filter active (I would personally prefer to have content stored with the proper br- and p-tags in the database and not have the filter enabled, as that would eventually mean I would not need the WYSIWYG Linebreaks module.)I can not tell exactly what appears to have changed here. It would be clearer if you showed a sample of the markup as it is when it's being edited, without the editor having been enabled (configure the profile to not enable the editor by default so it won't have a chance to mess with the markup, then edit an existing node.)
It would also be very useful to know how the corresponding text format is configured. Then I can provide a suggestion on how to configure the editor to handle linebreaks.
Comment #3
dhalbert CreditAttribution: dhalbert as a volunteer commentedYes, it appears I should have run update.php earlier.
The actual original text as stored in (say) field_data_body has newlines to indicate line and paragraph breaks. These were previously displayed as linebreaks in the editor textarea before I tried upgrading. They then disappeared on the upgrade.
In my original TinyMCE 3.5.11 profile, "Remove linebreaks" is not checked. In the text format I use for WYWSIWYG editing, the output filter " Convert line breaks into HTML (i.e. <br> and <p>)" is turned on. Indeed, as your comments suggest, a lot of content with linebreaks indicating formatting was imported years ago when the site was built, and we've continued to rely on linebreaks to indicate <br> and <p>, except in some special cases.
One of the reasons for trying this upgrade was a continuing problem we have with TinyMCE sometimes inserting paragraphs between existing paragraphs in the whole text being edited, resulting in double paragraph breaks which have to be removed by hand. I got the impression that this issue might have been fixed in newer versions of TinyMCE.
I apologize for the tone of the original report. It did break content editing in a kind of alarming way, and I thought a caution for upgraders might be in order.
Comment #4
dhalbert CreditAttribution: dhalbert as a volunteer commentedComment #5
TwoDAh I see, thanks for the clarification.
The 'Remove linebreaks' option is no longer available in TinyMCE 4. It will not matter here though as the Wysiwyg Linebreak module is a "cross-editor" plugin which will run its filtering before the editor is given the original contents, and also after the editor has generated its final markup.
Since you have a lot of old content with linebreaks instead of br-/p-tags, what you need is to keep the linebreak conversion filter enabled for the format and enable the 'Force linebreaks' plugin from the Wysiwyg Linebreaks module in the editor profile.
That plugin will take care of converting linebreaks to tags before the editor is aware of them, and back again once it is detached. All the editor will see is HTML markup, and all you'll see if you disable the editor is linebreaks.
There may be a setting or two which could be tweaked to remove empty paragraphs. I have also had some issues with them, usually when copying contents from word processors where people have hit enter/return twice to make a new paragraph.
It has not been enough of an annoyance yet that I've bothered to actually do something about it, but perhaps the invalid_elements can be used to disallow empty paragraphs.
However, I don't think the editor considers paragraphs with a non-breaking-space in them as empty.
Others seem to have the same concerns though, so it's probably possible to also use the ideas from post like this one: http://blog.room34.com/archives/5075.
There's also the option to ignore these empty paragraphs and remove them on output instead. For that we have solutions like the Empty paragraphs killer module, though I would personally prefer to not get them in there in the first place.
These settings can be overridden by implementing
hook_wysiwyg_editor_settings_alter()in a small custom module.Comment #6
dhalbert CreditAttribution: dhalbert as a volunteer commentedThanks for your detailed comments. I started the upgrade over from scratch and was careful to be more systematic.
So it seemed necessary to clear caches and/or re-run update.php, even though it was run during update. The first time I did the upgrade, I failed to do this. (I did see your warning in the Release Notes later.) I ended up deleting my old Wysiwyg profile, which seemed to be the only possible action on that configuration page (there was even some sort of message suggesting that, I think), and starting over with an empty profile. The new profile did not have linebreak handling turned on, and that caused my initial panic.
Also thanks for your comments about empty paragraph handling. I will keep an eye on this. It seemed to happen during some edits with the old TinyMCE, but I could not come up with a simple reproducible test case.
Comment #7
TwoDAh, yes, some plugins don't check the editor version before presenting themselves to Wysiwyg module.
A module not detecting a compatible version of the library (which may be difficult since you may not know which future versions are API-breaking) should not present a plugin through Wyswyg's API. When this happens Wysiwyg should be excluding the unavailable plugin from profiles already using it and the editor should hopefully continue to work without it. Sometimes other plugins may depend on it though, or we may simply not be detecting the plugin as unavailable, so editor crashes become unavoidable.
Thanks for figuring out which plugin was the problem with the crash. A bit weird that you had to run updates twice though. Drupal normally doesn't allow upgrades to run again.