WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 3 years ago

#13327 new defect (bug)

Post editor puts content through wpautop() before displaying it to users without JS enabled

Reported by: markjaquith Owned by:
Milestone: Future Release Priority: low
Severity: normal Version: 3.0
Component: Editor Keywords:
Focuses: Cc:

Description (last modified by markjaquith)

Steps to reproduce:

  1. With JS on, change to the Visual Editor
  2. Disable JS
  3. Add a new post
  4. Save as draft
  5. Note that the content is wrapped in <p> tags in the textarea.

http://img19.imageshack.us/img19/6363/screenshot20100510at524.png

Expected:

No paragraph tags are added.

Change History (7)

comment:1 markjaquith4 years ago

  • Description modified (diff)
  • Summary changed from Post editor puts content through wpautop() before displaying it to Contributors without JS to Post editor puts content through wpautop() before displaying it to users without JS enabled

This happens because

comment:2 follow-up: markjaquith4 years ago

This happens because the_editor() is adding wp_richedit_pre as a filter on the_editor_content. Because the user is "stuck" in Visual mode, it formats the content the way TinyMCE wants it... with paragraph tags.

One possible fix would be to load the TinyMCE version of the content up in a hidden textarea, load the regular text in the real textarea, and then attempt to use JS to copy the TinyMCE version over to the real textarea. Without JS, this would fail, and they'd keep the real content.

For users with JS, this may cause a flicker as that swap takes place. And we may need to use JS to keep them from trying to edit the content before this operation has taken place.

comment:3 markjaquith4 years ago

  • Milestone changed from 3.0 to 3.1

Punting to 3.1 — It's not a blocker, and I don't think it is a regression.

comment:4 in reply to: ↑ 2 azaozz4 years ago

Replying to markjaquith:

For users with JS, this may cause a flicker...

... And make the visual editor load slower.

The problem is that php (the server) has to know if the browser supports JS before outputting the post content so it applies the proper filter. That is doable with a cookie.

One possible fix would be to load the TinyMCE version of the content up in a hidden textarea, load the regular text in the real textarea, and then attempt to use JS to copy the TinyMCE version over to the real textarea. Without JS, this would fail, and they'd keep the real content.

We could try doing something similar with CSS only, will run some tests.

comment:5 azaozz4 years ago

Related: #13326

comment:6 azaozz4 years ago

Been thinking more about this: currently we output HTML for both cases, js and no-js and then hide the extra elements with CSS (the .hide-if-js, .hide-if-no-js classes).

This is working well and is completely transparent for the user. The disadvantages are that we output more HTML code and that in certain cases we still need to know whether JS in the browser is disabled before we start the output like for this ticket or the horizontal folding of the admin menu.

It seems we have two options:

  • Change the no-js mechanism to use a "session" type cookie, i.e. add a <noscript> redirect in the HTML header and when that is triggered, set a cookie that will expire when the browser is closed.
    <head>
    <noscript><meta http-equiv=refresh content="0; url=..." /></noscript>
    

The main disadvantage of this method is that the <noscript> tag is invalid in the HTML head in XHTML 1.0. However this is widely used and seems to work properly in all current browsers (see Google Maps for example).

From user prospective there will be no change when JS is enabled and only a very small delay in loading the first admin screen when it's disabled. In the back-end we can see that redirect, set a global or a constant, set the temporary cookie and stop outputting the <noscript> redirect (of course we will be checking for that cookie first).

  • Continue handling this on per-case basis. In that terms we would need to output two content textareas on the write/edit screen and hide the extra one with CSS:
<textarea id="content" name="content" class="hide-if-no-js"></textarea>

<textarea id="content-nojs" name="content-nojs" class="hide-if-js"></textarea>

If JS is enabled we can empty the content of #content-nojs (or even remove it completely), then when saving the post we will look first whether $_POST['content-nojs'] is not empty and copy that over $_POST['content'].

comment:7 nacin3 years ago

  • Milestone changed from Awaiting Triage to Future Release
Note: See TracTickets for help on using tickets.