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

Comment (by FolioVision):

 Thanks for sharing your thought process, Weston.

 Replying to [comment:149 westonruter]:
 > > So why not then just keep the Widget ID for the converted widget.
 >
 > Widget IDs are different from post IDs. Given how widgets are
 (unfortunately) stored in a single serialized array in options, there is
 no auto-incremented number from MySQL. The number part of a widget's ID is
 the ''index'' in the array. Then in order to disambiguate the number from
 other widget types, a widget ID is prefixed by the widget type (id_base)
 for example `text-123`. So converting such a widget over to Custom HTML
 would not only change the type prefix but it would also get a different
 array index, both breaking any CSS selector.

 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.

 > See also #35669 where widgets are proposed to be stored in a custom post
 type, so they ''would'' get an auto-incremented post ID. This will
 probably be implemented as part of blocks in Gutenberg.

 Another dubious idea, I remember when this came up. I believe it was
 Iseulde's idea. 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.

 > > Why should people have to go through painful manual moves when we
 could just do it for them automatically and seamlessly. That's what
 computers are for Weston, lightening the burden of pointless manual
 labour.
 >
 > Per above, we can't automatically move them as the migration would
 result in ID changes.

 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.

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