Make WordPress Core

Opened 15 years ago

Closed 15 years ago

#9218 closed defect (bug) (fixed)

Visual and HTML editor worked weird

Reported by: denis-de-bernardy's profile Denis-de-Bernardy Owned by: azaozz's profile azaozz
Milestone: 2.8 Priority: normal
Severity: major Version: 2.7
Component: Administration Keywords:
Focuses: Cc:


In the wysiwyg editor, click HTML. Then paste:

style="width: 520px; text-align: left; margin-left: auto; margin-right: auto;"
border="1" cellpadding="2" cellspacing="2">
     <td style="text-align: center; width: 350px;"><span
style="font-size: large;"><span
style="font-family: Arial;">Foo</span> </span></td>
     <td style="text-align: center; font-family: Arial;"
colspan="2" valign="undefined"><span
style="font-size: large;">Bar</span></td>

Basically, if there is a carriage return within a tag, rather than a space, TinyMCE will "fix"/break the code.

The same applies to WP, too, btw. Pasting the same in WP without the wysiwyg will trigger wpautop hell. (I can't recall the ticket number, but I submitted it as well and it went on ignored, even after I added a patch.)

Change History (13)

#1 in reply to: ↑ description @azaozz
15 years ago

  • Component changed from TinyMCE to Administration
  • Resolution set to wontfix
  • Severity changed from major to normal
  • Status changed from new to closed

Replying to Denis-de-Bernardy:

In the wysiwyg editor, click HTML...

That means you're switching to the HTML editor and are not in TinyMCE any more.

In the HTML editor all line breaks are converted to <br /> or <p> by autop, so having line break in the middle of a tag wouldn't work.

Although this code example is valid, the HTML editor is still an editor that works together with autop. Even if you paste the example in the QuickPress module on the dashboard where no editor is used at all, it would still break autop.

Possible work-around would be to add the "code" button to TinyMCE that would let you edit or paste arbitrary HTML code directly in the editor's iframe, although you will still have the browser's limitations there, or to turn autop off completely.

#2 follow-up: @Denis-de-Bernardy
15 years ago

  • Resolution wontfix deleted
  • Severity changed from normal to major
  • Status changed from closed to reopened

Why wontfix? We both agree that this is related to wpautop. But why should wpautop not get fixed accordingly? It's not that complicated... filtering the content with something like this in a while loop before calling wpautop would do the trick:

$pee = preg_replace("/(<[^>]+?)\n+/", "$1 ", $pee);

It could be run on ajax calls and before saving the post, rather than on every page load.

The fact of the matter is, fixing this bug would spare countless headaches for users who end up relying on html editors to format more complicated posts.


#3 @Denis-de-Bernardy
15 years ago

Also, fixing this at the TinyMCE level could also be done, which is why it seemed that reporting this as a TinyMCE issue sounded correct -- in spite of the fact that wpautop is the real culprit.

#4 in reply to: ↑ 2 @azaozz
15 years ago

Replying to Denis-de-Bernardy:

Why wontfix?..

Because it's an extremely rare case (IMHO). Don't remember seen any HTML editors that add line breaks in the middle of a tag and even if there are such editors, running HTML Tidy would fix this as well as catch errors. If users are pasting from external HTML editors, I think the least they could do it to ensure the code is well formed and appropriately formatted.

Also the proposed regex has to be run after normalizing line breaks (replacing \r\n and \r with \n) to work properly.

Yes, this can be fixed at the TinyMCE level by adding the "code" button there that opens a popup where HTML can be entered directly. Don't see this as a core addition though.

#5 @Denis-de-Bernardy
15 years ago

Just for reference, the related ticket is #4298

#6 follow-up: @FFEMTcJ
15 years ago

  • Milestone Unassigned deleted
  • Resolution set to wontfix
  • Severity changed from major to trivial
  • Status changed from reopened to closed

After talking with azaozz, still closing as wontfix due to the extreme situation involved in making this happen.

#7 follow-up: @bravos
15 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I'm a non technical user of WP so I suppose I'm the sort of user that it was intended for. Sufficient to say that I had a real struggle finding my way in here and have failed completely to understand some of this thread.

But the reason I'm here is that this deficiency affects me and I find it very frustrating because WP is not doing what it is supposed to do and I thought you should know about it. I was pleased to find the problem already identified but I'm very surprised at the response.

Someone seems to have lost the plot. WP is supposed to be simple for the user - that's people like me. Isn't that the objective?

So no matter whether it is 'extreme' or not (I suppose that must mean that it's difficult to sort out) the issue is to fix it - not avoid it.

The 'extremely rare case (IMHO)' from azaozz is just so totally mistaken I wonder whether you are living on this planet!

I hate html but when I have to use it then I use Kompozer as the editor when I cant get my blog editor to do what I want. Please don't tell me I should learn how to use it better. I'm one of the masses called users, remember.

But you could say that I am slightly more advanced than the average WP user. I can sort of manage with Kompozer and I use it because my understanding is that Kompozer is pretty strict in the code that it produces and being open source is likely to conform to standards.

I copy the relevant code out of Kompozer and paste it into the html editor - and it produces the sort of junk identified by this thread.

Quite by chance I discovered that by putting the code into Textpad and removing all the white space and then pasting it into the html editor - then everything is fine. The same goes for widgets - which often will not work when nicely formatted html is entered but will do when the white space is removed.

While you may be able to identify why this might be from a technical point of view the only thing that I experience is frustration and a great waste of time - and it is Wordpress that gets the blame.

I hope you will see this from my point of view and certainly, azaozz, you need to understand your users rather better. The number of Wordpress users I have mentioned this workaround to who have thanked me profusely for this gem of information is considerable, believe me.

#8 in reply to: ↑ 7 @Denis-de-Bernardy
15 years ago

  • Severity changed from trivial to major

Replying to bravos:

So no matter whether it is 'extreme' or not (I suppose that must mean that it's difficult to sort out) the issue is to fix it - not avoid it.

Definitely not difficult to sort out. Not only it's simple, but there's even a proposed patch on the related ticket -- which fixes the issue in the php version of wpautop.


#9 @Denis-de-Bernardy
15 years ago

Just for reference, the wpautop stuff from tinymce is in wp-admin/js/editor.js


#10 @dslyoga
15 years ago

  • Summary changed from Pasting HTML in the editor fails to Visual and HTML editor worked weird


I am a non-tech guy also, and much of the above is WAY over my head, but I wanted to comment on this issue. Especially since a chance meeting with WordPress users in a cafe who were very surprised I had so much trouble with the text editor.

In earlier versions of WP/SemPro (before they added TinyMice), I was learning how to use html tags when the Visual Editor did weird things, and my pages were turning out pretty well. I thought I was getting the hang of the html process.

Then when SemPro went to using TinyMice, all kinds of weird things happened. One of the most frustrating was the constant adding of one or more blank lines between blocks of text. And if I put in a horizontal line, it would add MANY blank lines. And if I did go into the html tab to try and fix things, I could no longer get the html tag fixes to work the way I had before.

After the Visual Editor created all those spaces, I would venture into the HTML tab, and try and remove excess tags and lines there, trying to make sure I would back space out ALL excess spaces in case there were some kind of invisible characters (don't even know if that is possible, but it sure seemed like it), then go back to the Visual Editor. It would look fine. Then I'd Update the page, and then Preview it, and all those blank spaces would be back again. I'd do that over and over again. If I recall correctly, it would only work if I saved the page while I was still in the HTML tab. But then if I later on went back into the Visual Editor to make more changes, the fight would be on again.

There were times when I thought I should just give up on the whole idea of using WordPress.

Getting the Table tools to behave was quite difficult too. I never did get them to behave in a way I could predict their behavior, and I got extremely frustrated. Excess lines was just one of the problems.

I never tried, as Bravos did, to paste in html from an editor, though.

I believe SemPro/Denis are not using TinyMice any longer, and so it is now much easier to format the pages. I'm not sure if he is going to try and bring it back, but I thought I'd provide some feedback in case they do want to try and use TinyMice again.

Thanks for Reading,
David Scott Lynn

#11 @dslyoga
15 years ago


Denis IS still using TinyMice in SemPro. I thought he had changed it to something else until the bugs got worked out.

Now I understand why it looks like TinyMice. ... It IS TinyMice!

Sorry for the confusion. Don't know where I got that idea he changed it.


#12 in reply to: ↑ 6 @sminc
15 years ago

Replying to FFEMTcJ:

After talking with azaozz, still closing as wontfix due to the extreme situation involved in making this happen.

This is for me what is frustrating with Wordpress and some other open source software. I am quite a novice at PHP but have made improvements to code or debugged issues and submitted those changes to the developer and they don't incorporate the fixes. I have to wonder why that is??

Here you have a solution to a known issue that does not seem difficult at all to implement handed to you and you discard it saying you won't correct the issue because the issue is not frequently discovered by average users? You know your code is in error, have the solution in your hands, or close enough or at least an individual willing to work the proposed fix until it is right, and you won't fix? Seems incredible to me.

Wordpress devs, you do get a lot right, however in this case you are wrong and seemingly out of touch.

Oh and by the way, the issue has in fact effected me directly, perhaps it is more common than you know.


#13 @Denis-de-Bernardy
15 years ago

  • Milestone set to 2.8
  • Resolution set to fixed
  • Status changed from reopened to closed

seems fixed in wp 2.8

Note: See TracTickets for help on using tickets.