[wp-trac] [WordPress Trac] #40951: New Text Widget - Switching Between Visual/Text Editor Strips Out Code

[WordPress Trac]

#40951: New Text Widget - Switching Between Visual/Text Editor Strips Out Code
--------------------------+--------------------------
 Reporter:  dwrippe       |       Owner:  westonruter
     Type:  defect (bug)  |      Status:  accepted
 Priority:  normal        |   Milestone:  4.8.1
Component:  Widgets       |     Version:  4.8
 Severity:  major         |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+--------------------------
Changes (by westonruter):

 * owner:   => westonruter
 * status:  reopened => accepted


Comment:

 This was discussed in the core dev chat. See the
 [https://wordpress.slack.com/archives/C02RQBWTW/p1498078551518900
 conversation log]. I started the conversation by pasting the following
 writeup:

 > To summarize the problem: the Text widget has been WordPress's de facto
 place to dump arbitrary HTML into sidebars. While arbitrary HTML can also
 be pasted into the post editor, it is there essentially managed by TinyMCE
 and will enforce `wpautop` while also stripping out empty elements and
 other markup that it determines is extraneous. When TinyMCE was introduced
 on the Text widget (#35243) it caused such custom-crafted HTML to get
 mutated by TinyMCE in undesirable ways.
 >
 > By late in the 4.8 cycle the only known issue from testing was for Text
 widgets that had relied on `wpautop` being off, and for such instances the
 direction for users was to remove the extra paragraphs that would get
 added once the Text widget was modified. At the time, the only known issue
 was extra paragraphs being inserted, per comments on the Make/Core post:
 https://make.wordpress.org/core/2017/05/23/addition-of-tinymce-to-the-
 text-widget/
 >
 > Important to note that Text widgets previously saved would retain the
 old behavior when rendering until the Text widget was updated with the new
 TinyMCE editor loaded. Since the presence of extra paragraphs was the only
 known issue, at the time late in the release cycle it was determined that
 reverting the Text widget (and renaming to HTML widget) and introducing a
 separate Rich Text widget was too drastic as a course of action. However,
 after the 4.8 release there appear to be a significant number of advanced
 users who are impacted by the change (see #40951), and the ultimate number
 of impacted users is not known now since, as noted above, the Text widget
 only changes its behavior once it is modified.
 >
 > In `trunk` there is presently an “HTML Code” widget for storing
 arbitrary HTML code that is not managed by TinyMCE. See #40907.
 >
 > One proposed solution was to convert all existing Text widgets over to
 HTML Code widgets as part of an upgrade routing. This will not have the
 desired effect for some advanced users because it will change the widget's
 ID that contains the content, and this will break CSS selectors that
 target the widget. It can also have negative impacts for plugins that have
 existing references to Text widget IDs for placement in contexts outside
 normal `dynamic_sidebar()` calls. Even for non-advanced users, migrating
 existing Text widgets over to HTML Code widgets is not ideal because then
 novice users, who may not know HTML to begin with, will have difficulty
 locating the widget that has the content they need to modify. Seeing the
 word “HTML” may also confuse and intimidate them.
 >
 > Another solution proposed was to revert the Text widget back to its
 original state (maybe renaming to HTML Code widget) and introduce a new
 Rich Text widget. However, a key reason for letting the existing Text
 widget remain upgraded with TinyMCE is that novice users who previously
 have just put simple text into the widget should by default get the new
 visual editing experience. Novice users shouldn't have to be bothered with
 copy/pasting the contents of their widget into a separate widget in order
 to start doing visual editing, in the same way that they don't have to
 switch between post editing experiences.
 >
 > However, I think the best suggestion that has been proposed is this:
 when loading the form for a Text widget, just as on the frontend it checks
 to see if it was previously saved from an older version of WordPress
 before TinyMCE was added to the Text widget. If it is such a pre-existing
 Text widget instance, then use heuristics to detect if TinyMCE would
 negatively impact the contents of the widget, including the auto-p
 checkbox being unchecked, whether there are empty tags, and whether there
 are `span`, `div`, `script`, or `style` tags. When the Text widget is in
 this legacy mode, it can have a notice that informs users of the new HTML
 Code widget and that it should be used going forward. Likewise, in the new
 mode when TinyMCE is present, when the Text (HTML) tab is selected, there
 can be a note (perhaps an admin pointer) that encourages users to use the
 HTML Code widget instead. By implementing this, novice users with basic
 content in their widgets win, and advanced users with custom HTML content
 in their widgets will cease from being negatively impacted.

 Based on the core dev chat discussion, I will be moving forward with
 implementing the proposed suggestion in this last paragraph, to introduce
 a legacy mode to the Text widget and use it when a widget instance
 contains non-`wpautop` content or advanced HTML. See the
 [https://wordpress.slack.com/archives/C02RQBWTW/p1498078551518900 Slack
 log] for the full conversation.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40951#comment:63>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform