WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 5 years ago

#5084 closed defect (bug) (invalid)

Non-WYSIWYG post editor broken in 2.3

Reported by: bglickstein Owned by:
Milestone: Priority: normal
Severity: critical Version: 2.3
Component: General Keywords: noTinyMCE
Focuses: Cc:

Description

I upgraded to 2.3 yesterday and discovered that HTML elements and entities in blog posts get an extra layer of entity-encoding before being presented in the non-WYSIWYG edit box. If you click "Save," the encoding remains and they're not HTML elements anymore. In other words, <b>this</b> becomes &lt;b&rt;this&lt;/b&rt; (and then renders in the blog as <b>this</b> when what I really wanted was this).

Attachments (1)

blogpost (1.2 KB) - added by bglickstein 7 years ago.
Procmail-callable interface that publishes mail to your blog

Download all attachments as: .zip

Change History (14)

comment:1 johnbillion7 years ago

  • Component changed from General to Administration

I'm unable to reproduce this. bglickstein, can you disable all your plugins and try again?

If the problerm persists, please supply a few more details such as PHP and MySQL versions, browser details, and whether you're using the Code tab of the WYSIWYG or just the non-WYSIWYG editor.

comment:2 ryan7 years ago

  • Resolution set to invalid
  • Status changed from new to closed

Markup placed in the "Visual" tab of the editor will encoded. You have to switch to the "Code" tab to enter markup that you do not want encoded. This is how it has worked for several releases and is the way it still behaves in my tests. Marking ticket as invalid. Re-open with more information if I have misunderstood the problem.

comment:3 foolswisdom7 years ago

  • Milestone 2.3.1 deleted

comment:4 raptorNL7 years ago

  • Priority changed from highest omg bbq to high
  • Resolution invalid deleted
  • Status changed from closed to reopened

Reopening this ticket.

Non-WYSIWYG editor converts my HTML entities to their plain charachter counterparts. Say I want to include some HTML code as an example in my page, i.e.

&lt;span&gt;

When I save that, it's OK. But when I then edit it, the entities are gone and it's just the unescaped HTML tag:

<span>

Strangely enough, this happens only in pages. In posts, HTML entities are preserved as they should.

comment:5 bglickstein7 years ago

For the record, I have the "Use the visual editor when writing" option turned off in my profile, so I don't see "Code" and "Visual" tabs.

Also: the original content of the post I later tried to edit in the UI was added via the XML-RPC interface; my PHP is 5.1.6; my MySQL is 5.0.27; my browser is Firefox 2.0.0.7.

comment:6 foolswisdom7 years ago

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

Thank you for reporting this problem. I have created a new ticket for this issue that clearly demonstrates the issue #5088. If your issue not as described in #5088 then please create another ticket with similar detailed information.

comment:7 foolswisdom7 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:8 foolswisdom7 years ago

  • Resolution set to duplicate
  • Status changed from reopened to closed

bglickstein7 years ago

Procmail-callable interface that publishes mail to your blog

comment:9 follow-up: bglickstein7 years ago

  • Cc bobg@… added
  • Component changed from Administration to General
  • Keywords noTinyMCE added; editor removed
  • Milestone set to 2.3.1
  • Resolution duplicate deleted
  • Status changed from closed to reopened

As requested in issue #5088, I am reopening this bug (which appears related to that one but is the reverse case) with more detail.

The XML-RPC client I used to post the text was a Perl script of my own design, invoked from procmail, so I can mail posts to my blog. It uses the Net::Blogger::* API from CPAN. I am attaching it hereto and incidentally contributing it to anyone else who'd like to use it.

My version of Perl is 5.8.8 and my version of Net::Blogger is 1.0.

However, in testing I discovered that it is not necessary to use XML-RPC to reproduce this problem. Simply start writing a post with the non-WYSIWYG editor (i.e., with your "Use the visual editor when writing" profile option turned off) containing something simple like:

<b>test</b>

Now "Save and continue editing." Presto: the post body now contains

&lt;b&rt;test&lt;/b&rt;

and you've reproduced the bug.

comment:10 in reply to: ↑ 9 foolswisdom7 years ago

Replying to bglickstein:

However, in testing I discovered that it is not necessary to use XML-RPC to reproduce this problem. Simply start writing a post with the non-WYSIWYG editor (i.e., with your "Use the visual editor when writing" profile option turned off) containing something simple like:

<b>test</b>

Now "Save and continue editing." Presto: the post body now contains

&lt;b&rt;test&lt;/b&rt;

and you've reproduced the bug.

I can't reproduce the bug in this manner, so there seems to be a detail missing.

comment:11 bglickstein7 years ago

OK, further details: my active plugins are Adsense-Deluxe, Akismet, Snap Preview Anywhere, Wordpress Autolink, WordPress XHTML validator, and wp-cache. After disabling all of them, I could no longer reproduce the bug.

I reenabled them one by one. It looks like the culprit is Wordpress Autolink. Disabling it makes the bug disappear.

I don't know whether this is a bug in Autolink or whether Autolink is tickling a bug in Wordpress.

comment:12 RuddO7 years ago

Can you guys please verify? I haven't had time to upgrade to 2.3 yet

comment:13 johnbillion7 years ago

  • Milestone 2.3.1 deleted
  • Priority changed from high to normal
  • Resolution set to invalid
  • Status changed from reopened to closed

Closing as invalid as per bglickstein's last comment. Culprit was WordPress Autolink.

Note: See TracTickets for help on using tickets.