[wp-trac] [WordPress Trac] #40960: Widgets: The Text widget should respect the “Disable the visual editor when writing” setting

WordPress Trac noreply at wordpress.org
Wed Jun 21 14:43:29 UTC 2017


#40960: Widgets: The Text widget should respect the “Disable the visual editor when
writing” setting
--------------------------+--------------------
 Reporter:  westonruter   |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  4.8.1
Component:  Widgets       |     Version:  4.8
 Severity:  major         |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+--------------------

Comment (by FolioVision):

 There are three related open tickets about the issues which the forced
 upgrade of existing text widgets has caused:

 * [ticket:40907 Introduce widget dedicated for HTML code]
 * [ticket:40951 New Text Widget - Switching Between Visual/Text Editor
 Strips Out Code]
 * [ticket:40960 Widgets: The Text widget should respect the “Disable the
 visual editor when writing” setting]

 I'm not expert enough in WordPress Trac to be able to etiquette to merge
 all three but perhaps someone else is.

 Apparently the reason we are breaking millions of WordPress sites is
 [comment:5:ticket:40907 fairly arbitrary decision by Matt made in Slack]
 (hardly seem a very earnest way of running an open source project, taking
 breaking decisions in a real time chat environment with no opportunity for
 input by those not present at the specific meeting).

 > Matt wants to move forward with the upgraded Text widget as-is, with
 there not being a great enough concern for some users potentially having
 to adjust their usage to align with the new behavior (which aligns with
 longstanding post editor behavior).

 Consensus among developers is [comment:37:ticket:40951 synavista's
 suggestion]:

 > The best course of action at this point, it would seem, would be to
 admit the error, convert the text editor back to the way it was, and
 simultaneously release the updated HTML Code widget along with a new Rich
 Text Editor. If that is completely impossible, at least figure out a way
 for the TinyMCE Text Editor to both default to the text editor AND
 remember the selected editor type (which I would hope would stop the
 system from stripping out existing content).

 Advocates of that point of view include many experienced developers and
 contributors such as [comment:3:ticket:40907 sami.keijonen],
 [comment:4:ticket:40907 Kopepash], [comment:12:ticket:40907 carasmo],
 [comment:30:ticket:40907 pipdig], [comment:33:ticket:40907
 piggybanktechnology], [comment:34:ticket:40907 theMikeD],
 [comment:5:ticket:40960 Cynderella], [comment:6:ticket:40960 dfterry],
 [comment:7:ticket:40960 skoen], [comment:8:ticket:40960 j893],
 [comment:4:ticket:40951 dwrippe], [comment:31:ticket:40951 And_or],
 [comment:40:ticket:40951 philclothier], [comment:42:ticket:40951 majick],
 [comment:43:ticket:40951 gitlost], [comment:52:ticket:40951 gekkocorp].

 The current fix strategy will not solve unnecessary breaking issues, as
 [comment:10:ticket:40960 TheMikeD notes]:

 > That's great, but it still means that every site that has ever used to
 code in the text widget now has to be manually updated. Backwards
 compatibility wise, this decision was not well thought out. I would like
 to see the rich text parts of the text widget reverted and a new rich text
 editor in trunk. In other words, don't replace the one that's already
 there, add a new one.

 The update burden for those of us who actually manage WordPress websites
 in the real world (and don't have 500 developers on staff to do it for us)
 is [comment:31:ticket:40951 substantial]:

 > Usually I am fast with updating websites, but this 'handy' Text Widget
 is a game-changer. Basically I feel punished for knowing and using html
 now....So I have convinced my clients to update their sites, and now I can
 not until I have manually checked and fixed a 100+ Genesis
 websites...which is going to take me days.(Who is the genius that wanted
 this new widget?)

 There's nothing wrong with making mistakes, Matt. There's something really
 wrong in not acknowledging one's mistakes and correcting them.

 All we have to do here is make the HTML widget a separate widget and not
 auto-convert the existing widgets to an HTML widget. There's no problem
 even making the default widget going forward the HTML one. But force
 converting and breaking sites is not fair. I'm left pretty speechless by
 this deliberate sabotage of millions of sites.

 Nonsense like this makes me very glad we created
 [https://wordpress.org/plugins/businesspress/ BusinessPress] to block
 forced or inadvertent updates for WordPress until we're satisfied those
 updates no longer compromise security or functionality.

 Millions of personal and business sites should not be a playground for
 beta software, whether that software is free or not. WordPress is not free
 to its users: they pay in spades for choosing WordPress in either money
 (management) or time (lots of their own free time). Honestly we should
 keep WordPress users' costs to a minimum and strive to keep the trust
 high.

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


More information about the wp-trac mailing list