[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:
     Type:  defect (bug)                         |  westonruter
 Priority:  normal                               |      Status:  reopened
Component:  Widgets                              |   Milestone:  4.8.1
 Severity:  major                                |     Version:  4.8
 Keywords:  needs-testing has-unit-tests has-    |  Resolution:
  patch commit fixed-major                       |     Focuses:
-------------------------------------------------+-------------------------

Comment (by westonruter):

 Replying to [comment:136 bobbingwide]:
 > Comments on the new Custom HTML code... having tested the new solution
 for #40993.

 Many thanks for testing.

 > 1. I don't understand why is_legacy_instance() is called during
 wp_list_widgets() processing. Note: It doesn't cause a problem at present.

 The reason is that the legacy mode is checked when outputting the widget
 controls, when the `form` method is invoked. The `form` method then will
 then decide whether or not the widget controls should be presented in
 legacy mode or not, and once a widget is saved in legacy mode or in non-
 legacy mode, then the results will get stored in the widget instance as
 the `legacy=true` prop or the `filter=content` prop, respectively. You can
 see that the `widget` method looks at the `filter` prop to see if has been
 set to `'content'`, and if so then that indicates that the new filter
 `widget_text_content` filter should apply.

 > 2. I think that the message that says 'This widget contains code that
 may work better in the new “Custom HTML” widget. How about trying that
 widget instead?' doesn't need the word 'new'. Some time in the future new
 will be old.

 I think we can remove the “new” word in `trunk` but it should be left in
 the 4.8 branch. @melchoyce agreed?

 > 3. When the widget text contains a shortcode then it may not work better
 in the Custom HTML widget as do_shortcode is not automatically attached to
 'widget_custom_html_content'. So, until logic is added to enable shortcode
 processing it'll be worse.

 Shortcodes aren't automatically attached to `widget_text_content` filter
 either, or `widget_text` for that matter. A plugin has to opt-in to do
 shortcode processing in widgets to begin with, so a plugin would need to
 do the same for the Custom HTML widget.

 > 4. The message doesn't go away even when the widget has been changed.
 > So perhaps the message should say 'This widget may contain code...'.

 Good point. Or even, “This widget ''may have'' contained code”. @melchoyce
 thoughts?

 > 5. And what's meant by 'code' anyway. Some users may think it's the code
 tag(s) created by the code button.

 So maybe it should say “custom HTML” instead of “code”?

 > 6. Checking for the presence of a shortcode assumes that the shortcode
 has been registered. Not all shortcodes are registered during admin
 processing. Sometimes shortcodes are inactive since the plugins to which
 they're associated have been deactivated.

 You mean in the `is_legacy_instance` method? Actually, that whole bit of
 logic could in reality be reverted. You see, the commit
 [https://github.com/xwp/wordpress-
 develop/pull/235/commits/1ffb4519867c87d12a68fcc89805b99480325343 1ffb451]
 was added first, and then a more robust method for temporarily moving the
 `do_shortcode` handler was done subsequently in [https://github.com/xwp
 /wordpress-
 develop/pull/235/commits/6e6b53df1f5ccdcc009682dcc9166c88d8c2c56d
 6e6b53d]. So there isn't actually a need to enter into legacy mode when a
 preexisting widget contains a shortcode.

 > 7. Does the presence of shortcodes matter anyway, now that there's just
 in time processing?

 Hah. Yes, exactly! I can revert [https://github.com/xwp/wordpress-
 develop/pull/235/commits/1ffb4519867c87d12a68fcc89805b99480325343 1ffb451]
 then, unless anyone sees a reason for keeping it around.

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