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

WordPress Trac noreply at wordpress.org
Tue Jul 18 01:00:18 UTC 2017


#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 needs-dev-note        |     Focuses:
-------------------------------------------------+-------------------------

Comment (by westonruter):

 Replying to [comment:150 FolioVision]:
 > It seems to me the existing widget could remain in place with a flag to
 open it in the HTML widget, i.e. effectively it is an HTML widget.

 Yes, but then there'd essentially be one widget that is overloaded to have
 two separate purposes: showing content and showing HTML code. We're trying
 to separate out these into the two separate widgets with the introduction
 of the separate Custom HTML widget. So that is why the legacy mode of the
 Text widget cannot be entered into for new instances.

 Alternatively, an idea would be to have a way to give a UI for the user to
 opt-in to transform a Text widget into a Custom HTML widget. The closest
 we got to that can be seen in [attachment:add-widget-link-auto-search-
 available-widgets-panel.png] where Add Widget link causes the available
 widgets panel to open with the “Custom HTML” being pre-searched for. This
 feature, however, is only available in the Customizer given that there is
 a lack of any such construct in the widgets admin screen. In general,
 widgets lack a proper data model and JavaScript API to accomplish this
 widget transformation from a Text widget to a Custom HTML widget,
 something which is being accounted for from the ground up in the
 development of blocks in Gutenberg. So while it would be technically
 possible to implement logic for doing the transformation from a Text block
 to a Custom HTML block in the UI, the complexity required to implement
 given the current state of widgets would lead to diminishing returns, I
 feel.

 > Widgets are not mainly posts. They are *widgets* and hence should store
 javascript, PHP and HTML very easily. I.e. free form content Trying to
 store widgets in post content is just pushing square pegs into round
 holes.

 I think we have different understandings of what a “post” is. I agree that
 widgets are not mainly articles, but data. Custom post types are being
 used to store JSON data today in the `customize_changeset` post type to
 store changesets in the Customizer, and they are being used to store
 Additional CSS in the `custom_css` post type. We're also considering using
 a private custom post type to store oEmbed caches in #34115. The post type
 is WordPress's scalable storage model for objects, whether that be article
 content or data content. Using a custom post type to store JSON data
 containing a given widget/block's instance data seems natural to me.
 Anyway, this is going off topic.

 > I'm sorry Weston, but it sounds for carefully formulated excuses for a
 lack of respect for both user and agency time. I can't imagine how our
 clients would react if we just broke their sites for the heck of it.
 That's what we (collectively) are doing.

 Nothing will be broken because existing Text widgets will be in legacy
 mode if the expansive conditions are met. Also, I work at an agency that
 specializes in WordPress, so I very much respect agency time. I do not
 work for Automattic and I don't work on WordPress.com. I'm very much
 concerned for not breaking sites and that is why I've worked out this
 legacy mode, so existing installs will continue to work as they have been,
 but then moving forward users will start transitioning to use separate
 widgets depending on whether they want to write content (Text widget) or
 code (Custom HTML widget). As I've said before, I don't think this legacy
 mode is an excuse or an attempt to save face: I would have chosen this
 route from the beginning for 4.8 if these issues had arisen during
 testing.

 I feel like we're re-hashing the same things over and over. In the end
 we'll just have to agree to disagree.

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


More information about the wp-trac mailing list