[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