Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#40960 closed defect (bug) (fixed)

Widgets: The Text widget should respect the “Disable the visual editor when writing” setting

Reported by: westonruter's profile westonruter Owned by: azaozz's profile azaozz
Milestone: 4.8.1 Priority: normal
Severity: normal Version: 4.8
Component: Widgets Keywords: has-patch fixed-major commit
Focuses: Cc:

Description

In #35243 the Text widget was updated to feature TinyMCE. However, the editor here does not respect the “Disable the visual editor when writing” user setting. The wp.editor.initialize API does not support initializing the editor with the Text tab selected by default, and that would be a dependency for supporting this.

Relates to #40951.

Attachments (1)

40960.patch (3.7 KB) - added by azaozz 7 years ago.

Download all attachments as: .zip

Change History (53)

#1 follow-up: @westonruter
7 years ago

@azaozz can the wp.editor.initialize() API get a param to default to the Text tab, essentially deferring the initialization of TinyMCE until the user first clicks the Visual tab?

#2 in reply to: ↑ 1 @azaozz
7 years ago

Replying to westonruter:

We can, but that will be pretty bleak user experience. Can also try to implement the same behavior like the main editor: to "remember" the last tab. Can reuse the state from the main editor. However that would make initializing this editor more complex.

To support "Disable the visual editor when writing", we can stop outputting the TinyMCE scripts (from PHP). This is a global user preference so TinyMCE shouldn't be initialized anywhere. That should behave in the same way as the Edit Post editor regardless of the initialization settings.

Last edited 7 years ago by azaozz (previous) (diff)

#3 @mahasvin
7 years ago

Can the "Disable visual editor" checkbox be returned to Widgets UI?

#4 @theMikeD
7 years ago

Or maybe text widget be reverted and a new widget called "rich text editor" be created?

#5 @Cynderella
7 years ago

I'm by no means a hard-core developer but I use Black Studio TinyMCE Widget and have no issues in latest version of WP. Why can't that or something similar be used?

#6 @dfterry
7 years ago

Surely this is a huge problem for all the themes that use widgets with SVG or javascript or raw HTML that doesn't want to be changed. The widget WYSIWYG should be disabled by default, I have lots of problems with this default even with custom functions to prevent autoformatting because the editor itself just rewrites code when opened, no chance to disable.

#7 @skoen
7 years ago

  • Severity changed from normal to major

I would say that this is a severe bug that actually breaks a lot of themes. This is Wordpress core team reverting the whole software back to being a blog and making people lean towards more themes that uses the preview editor. I second the opinion to have it at least select the Text version of the Widget first. That way the code doesn't break instantly which it does now. There are already several plugins to utilize a more visual based widget, why not make that into a core and let the «normal» text widget be just that, NORMAL text.

#8 follow-up: @j893
7 years ago

Additionally, Wordpress is long overdue for a "Code" widget that is specifically for placing raw code (shortcodes, javascript, SVG, HTML, etc.). This is what people would have been using if it had been available, and then now the addition of the visual editor to the text widget would not be breaking anything, and would have been the welcome addition it was hoped to be...

But for now, please have it default to the "Text" tab at least, and not the visual editor, and not convert anything without asking! (or some similar fix, a reversion, etc.) This change caused an ongoing crisis on dozens of my sites as users went and edited a widget like they usually do, but then had all the code-containing widgets insta-break on them.

Sure one can use:

remove_filter('widget_text_content', 'wpautop');
remove_filter('widget_text_content', 'wptexturize');
remove_filter('widget_text_content', 'capital_P_dangit');
remove_filter('widget_text_content', 'convert_smilies');

but that doesn't help keep any code from being mangled when changing over to the visual editor and back to text (and it always defaults to "Visual" now).

Last edited 7 years ago by j893 (previous) (diff)

#9 in reply to: ↑ 8 @westonruter
7 years ago

Replying to j893:

Additionally, Wordpress is long overdue for a "Code" widget that is specifically for placing raw code

An HTML Code widget is actually now in trunk. See #40907. We're evaluating options for releasing it as part of 4.8.1.

#10 @theMikeD
7 years ago

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.

#11 follow-up: @carasmo
7 years ago

Yes, nearly every tut on "how to add an image" or how to add this or that is using the old text widget and regular html. ( The new image widget doesn't even allow a link. Who does that? So rare. And confusing. Regular people don't think in terms of a link with an image, it's just an image. I just had a client the new Image widget and wonder how to add a link, so I used an image widget that had an optional field for a link and used

unregister_widget('WP_Widget_Media_Image');

so she wouldn't be confused.)

I would switch the text widget back to the previous text widget, just rename it html widget and add a rich text editor.

WordPress is super confusing these days.

#12 follow-up: @pipdig
7 years ago

+1 for reverting the Text widget back and creating a new widget with TinyMCE functionality.

We're receiving more and more support requests relating to this with people finally updating to 4.8. I don't think the full effect of this breaking change has been felt yet...

For the first time, we're now recommending to clients that they should hold-off on updating to the latest version. Sad times.

#13 in reply to: ↑ 12 @skoen
7 years ago

Replying to pipdig:

+1 for reverting the Text widget back and creating a new widget with TinyMCE functionality.

We're receiving more and more support requests relating to this with people finally updating to 4.8. I don't think the full effect of this breaking change has been felt yet...

For the first time, we're now recommending to clients that they should hold-off on updating to the latest version. Sad times.

+1 here as well. It's sad to make them hold off on an update that adds better stuff into Wordpress. Just sad to see that they tried to fix the widgets. Haven't they heard the saying «Don't fix something that ain't broken». I would rather have Hello Dolly removed from WP than this widget «fix»

#14 @theMikeD
7 years ago

I believe the original issue that tracked this "feature" is #35760 fwiw

Version 0, edited 7 years ago by theMikeD (next)

#15 in reply to: ↑ 11 ; follow-up: @westonruter
7 years ago

Replying to carasmo:

The new image widget doesn't even allow a link.

It does allow a link. Select the image and then under Display Settings select Link To => Custom Link and then provide the URL for the link.

#16 @dfterry
7 years ago

Will 4.8.1 it be safe to update? I won't be updating to a version which costs hours of dev time to deal with.

Last edited 7 years ago by dfterry (previous) (diff)

#17 in reply to: ↑ 15 @carasmo
7 years ago

Replying to westonruter:

Replying to carasmo:

The new image widget doesn't even allow a link.

It does allow a link. Select the image and then under Display Settings select Link To => Custom Link and then provide the URL for the link.

Thanks! I like the other image widget (https://wordpress.org/plugins/image-widget/), easier to use and to make a link.

#18 follow-up: @FolioVision
7 years ago

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

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 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 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 sami.keijonen, Kopepash, carasmo, pipdig, piggybanktechnology, theMikeD, Cynderella, dfterry, skoen, j893, dwrippe, And_or, philclothier, majick, gitlost, gekkocorp.

The current fix strategy will not solve unnecessary breaking issues, as 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 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 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.

@azaozz
7 years ago

#19 @azaozz
7 years ago

  • Keywords has-patch added; needs-patch removed
  • Severity changed from major to normal

In 40960.patch: when using wp_enqueue_editor() and the user has clicked the "Disable the visual editor when writing" checkbox, do not output the TinyMCE scripts. Any editor added from js will only have the Quicktags buttons.

#20 @westonruter
7 years ago

  • Keywords needs-testing added

#21 @azaozz
7 years ago

  • Owner set to azaozz
  • Resolution set to fixed
  • Status changed from new to closed

In 40991:

TinyMCE: respect the Disable the visual editor when writing user setting and don't output the TinyMCE components when using wp_enqueue_editor().

Fixes #40960 for trunk.

#22 @azaozz
7 years ago

  • Keywords fixed-major added; needs-testing removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopen for 4.8.1.

#23 in reply to: ↑ 18 ; follow-ups: @azaozz
7 years ago

Replying to FolioVision:

Wow, so much hatred... This kind of "post" would be perfect for your own site, but don't think it belongs on trac. It also has nothing to do with this ticket.

Few things:

Promoting your own plugin on trac is really spammy. Could you edit your comment and remove that part please. Looking at that plugin, the name BusinessPress seems quite misleading. This seems to be a plugin that mostly circumvents security for convenience. Imho this type of plugins should come with a big warning:

Using some of the features of this plugin will make your site vulnerable to attacks. If you disable auto-updating, it is imperative that you check for WordPress security updates few times per day or your site may get compromised.


...the reason we are breaking millions of WordPress sites

How did you count them? I'd say they are "tens of sites" where the users had followed some not-so-great advice to add some not-so-great html, and then attempt to edit these hacks. :)

Your "ideal" solution seems to be to stop everybody edit theirs Text widgets with the newly added editor in order to "save" the few users that followed the mostly not-so-great advice and used a Text widget to add html hacks to their sites.

From the examples I've seen: adding inline <script> is considered "bad practice" (as it is not cacheable in the browser) and may slow down page load. Adding <style> mid-page is harmful as it slows page loading a lot and most search engines will penalize (reduce SEO ranking) sites that do this. The last example was with removing empty spans and links, but think we should fix this in TinyMCE.

Last edited 7 years ago by azaozz (previous) (diff)

#24 in reply to: ↑ 23 @carasmo
7 years ago

The majority of Genesis child themes are widgetized front pages with arbitrary html in the old text widget. It would be over kill to add a builder or make another widget with an interface when html will do just fine. It's not a few users, it's quite a lot. FontAwesome (empty tags), paragraphs wrapping and messing up the layout ... so many issues with just very simple, non-hacky html in a widget with a description "arbitrary html".

I loved the post by FolioVision.

Replying to azaozz:

How did you count them? I'd say they are "tens of sites" where the users had followed some not-so-great advice to add some not-so-great html, and then attempt to edit these hacks. :)

Your "ideal" solution seems to be to stop everybody edit theirs Text widgets with the newly added editor in order to "save" the few users that followed the mostly not-so-great advice and used a Text widget to add html hacks to their sites.

#25 @mark-k
7 years ago

:( not sure how anything is being fixed with the last commit. Hope no one seriously expect people that do not want to use the rich text editor in the "html" widget to disable it also when they edit their content.

And really, all of us make mistakes and some of them are bigger than the others. The patch over patch strategy employed now to save face is just not in place. The proper solution is to resurrect the old widget and call the 4.8 version something like "rich text". Much less coding effort than the endless patch over patch over patch that is surely to come.

#26 in reply to: ↑ 23 ; follow-up: @emmtre
7 years ago

Replying to azaozz:

Replying to FolioVision:

How did you count them? I'd say they are "tens of sites" where the users had followed some not-so-great advice to add some not-so-great html, and then attempt to edit these hacks. :)

I'm amazed by such ignorance by core committers to justify a bad decision from the beginning. There are at least several hundred thousands of sites using widgets for forms, call for actions, footers, etc where the layout now are broken. And we are disabling TinyMCE for all users in all sites we are building since we are using a very strict layout policy with structured css. I'm sorry but you have to listen and understand why people are upset about this change nobody asked for.

#27 in reply to: ↑ 26 ; follow-up: @westonruter
7 years ago

Replying to emmtre:

I'm amazed by such ignorance by core committers to justify a bad decision from the beginning. There are at least several hundred thousands of sites using widgets for forms, call for actions, footers, etc where the layout now are broken. And we are disabling TinyMCE for all users in all sites we are building since we are using a very strict layout policy with structured css. I'm sorry but you have to listen and understand why people are upset about this change nobody asked for.

Disabling TinyMCE for a given user is not the solution being proposed, as I understand you to be indicating by this comment. This ticket is just to make the Text widget respect that user preference. For fixing the Text widget to be compatible with prior usages, while also directing users to use the new Custom HTML widget (#40907) moving forward, see #40951.

#28 in reply to: ↑ 27 @emmtre
7 years ago

Replying to westonruter:

Disabling TinyMCE for a given user is not the solution being proposed, as I understand you to be indicating by this comment. This ticket is just to make the Text widget respect that user preference. For fixing the Text widget to be compatible with prior usages, while also directing users to use the new Custom HTML widget (#40907) moving forward, see #40951.

I was just trying to explain why it's a bad decision to have TinyMCE as the default editor for text widgets. And there should be a separate setting for enabling the TinyMCE editor for text widgets instead of depending on the general setting for the content field.

#29 @skoen
7 years ago

  • Severity changed from normal to critical

I am worried now. This ticket has spiraled out of control because someone clearly doesn't understand that is happening. Let me show you what is happening.

On five of my sites we are using four different text widget as footers. All of these contain HTML codes to make them appear as they should. If I want to make a change to the widget, like updating a link or update some information I have to view the source and copy the current HTML code into a text editor.

Then when accessing Widgets in the WP dashboard I have to make sure that I don't perform the changes while the editor is in TinyMCE mode (Visual), because it will break the code. This broken code is very visible if I change to Text to see the HTML code.

It turns this
http://i.imgur.com/1Ln6V3L.jpg
into this
http://i.imgur.com/U5m4XRa.jpg

This is why this ticket has to stay on topic and why we need to revert the current Text widget back to being a clean HTML widget, and instead introduce a new «rich text» widget and encourage the users to start using this one, while making it possible for us who are using HTML tags in our current Text widgets to continue using the ones we are using and not break the site or the code.

#30 @anonymized_11892634
7 years ago

@azaozz It seems to me that @FolioVision was merely emphasizing how much of a flustercluck this issue is. Your response to him appears very defensive and off-topic (even more so than BusinessPress plugin. Though I agree, it did seem a bit spammy).

No one in the core team seems to appreciate how much this is impacting WP sites out in the wild (probably because it is not impacting worpdress.com's Text widget which was restricted prior to updates anyway).

If you look at #40951, #40907, #40960 and the [launch post](https://make.wordpress.org/core/2017/05/23/addition-of-tinymce-to-the-text-widget/), you'll see just how much of a kickback there has been in the comments.

</rant>

#31 in reply to: ↑ 23 @theMikeD
7 years ago

@azaozz @FolioVision 's post was exactly right. The core belief of backwards compatibility that has guided WP development for years got thrown out the window with the decision to modify the text widget without warning, feedback or a way to disable it. It's that simple.

You may think it's bad practice. Maybe it is. That is 100% irrelevant. The fact is that for years the text widget has been used for arbitrary HTML for countless reasons, and it's not up to you to decide if that is valid or not. It was never stated to be *invalid* anywhere that I have seen, so its our job to deal with that and make decisions based on data not whims.

And even if it *is* invalid, that is again 100% irrelevant. You don't get to decide how users use WP, and it's not your role to correct them with breaking code. And you wonder why there is such negative pushback?

The truly shitty thing here is that the users this affects won't know what happened when it actually does affect them. This bug is not evident on upgrade to 4.8. It's only evident after an upgrade to 4.8 and then modifying the text widget. If these two things don't happen within minutes of each other the logical cause and effect won't exist and they'll be left with a) code that used to work that no longer does for no obvious reason, and b) no way to get the working code back without a site backup being restored (which will only set the user up for the same problem again) or the ability to pull the widget code *out* of a site backup and put it into the new HTMl widget (when it's released) or one of the several plugins that now exist to combat this issue.

And I'd like to point out that in the slack dev meeting where this issue was discussed, one of the things Matt asked for as proof of how messed up this decision was, was examples of plugins that had been created to undo it. So while you may think it's spammy, it was a factor in that meeting.

IMHO your patch addresses the original bug logged but is missing the point. I don't want to disable TinyMCE site-wide, and I suspect the most people don't either. I want to disable TinyMCE in the text widget. How can we achieve that goal?

Last edited 7 years ago by theMikeD (previous) (diff)

#32 @pipdig
7 years ago

As a theme shop, we're receiving support requests like this http://i.imgur.com/Zq93MNa.png with increasing frequency. Ironically, it's not really anything to do with our themes. We don't provide any features that require the Text widget.

It is almost always Adsense or Mailchimp that people are trying to setup. I wonder if those services are listing steps that relate to the old widget? i.e. It isn't explicitly saying "click the HTML tab" in the guide, so people are simply pasting it into the Visual widget contents. This might seem really obvious to us, but to the average user it seems to be causing quite some confusion.

I don't know if the solution is to reach out to third parties to ask them to update their guidance? Or would it not make more sense to revert the widget back so that the majority of guidance does not need to be updated by third parties?

#33 follow-up: @dfterry
7 years ago

I assume it will be changed to a default HTML view and create a new WYSIWYG widget for less savvy users.. Every other alternative seems to have no understanding of what this change has caused.
I don't want to be required to remember to change a setting before I edit a widget.
I don't want HTML auto-changed when I edit a widget. (see above)
I don't want to update old websites to cater to a new way of doing things unless it is completely amazing.

Last edited 7 years ago by dfterry (previous) (diff)

#34 in reply to: ↑ 33 @skoen
7 years ago

Replying to dfterry:

I assume it will be changed to a default HTML view and create a new WYSIWYG widget for less savvy users.. Every other alternative seems to have no understanding of what this change has caused.
I don't want to be required to remember to change a setting before I edit a widget.
I don't want HTML auto-changed when I edit a widget. (see above)
I don't want to update old websites to cater to a new way of doing things unless it is completely amazing.

Sums up everything perfect. This is what we want with this ticket. Is this so hard to understand?

#35 @pipdig
7 years ago

We're receiving more and more support requests relating to the new widget settings. If you don't believe me, here's a public example https://twitter.com/pipdig/status/882163832050864128

I appreciate the answer might be "that's your problem, not ours". I'm just trying to highlight issues that may not have been considered for third parties. The usability of the new widget seems to be hitting entry-level users pretty hard due to inaccurate guidance from Google searches. e.g. "How to add Adsense to WordPress". Unfortunately we're on the "font line" since people are using our themes and assume it is a theme issue.

Is the expectation that external sources should update the guidance to the new widget? Or are we waiting for 4.8.1 first? @azaozz @westonruter - I know you guys are probably super busy but any kind of pointers on this would be appreciated. Are we sticking to the current plan?

Last edited 7 years ago by pipdig (previous) (diff)

#36 follow-up: @westonruter
7 years ago

@pipdig Thanks for the comment. I've followed up at https://core.trac.wordpress.org/ticket/40951#comment:103

In short: You can see in #40951 that we're looking at using a pointer or some kind of notification that alerts users of the existence of the Custom HTML widget. A pointer like that could also be shown when someone tries pasting HTML into TinyMCE.

https://core.trac.wordpress.org/raw-attachment/ticket/40951/admin-pointer-widgets-screen.png

#37 in reply to: ↑ 36 @pipdig
7 years ago

Replying to westonruter:

Thanks for the summary, Weston. Apologies, I did not realize there had been further discussion via the other ticket.

I think that the notification in the screenshot should help to direct people. Now we just need to wait patiently for 4.8.1 :]

#38 follow-up: @skoen
7 years ago

Quick question though. Will this revert the «old» text widget to the «Legacy» type in 4.8.1, so that it will not break the site?

#39 in reply to: ↑ 38 ; follow-ups: @westonruter
7 years ago

Replying to skoen:

Quick question though. Will this revert the «old» text widget to the «Legacy» type in 4.8.1, so that it will not break the site?

Yes, if the Text widget was created/modified prior to 4.8.0 and if the Text widget determines it contains markup that TinyMCE could potentially corrupt (including if there are line breaks and the auto-paragraphing checkbox was unchecked), then it will revert to the legacy mode with the the addition of a notice, according to the patch proposed on #40951:

https://core.trac.wordpress.org/raw-attachment/ticket/40951/text-widget-legacy-mode-2.png

#40 @skoen
7 years ago

Awesome. Hopefully it will work out this way when 4.8.1 comes out, then I will actually update the rest of my sites to this version with no problem.

#41 in reply to: ↑ 39 ; follow-up: @emmtre
7 years ago

Replying to westonruter:

Yes, if the Text widget was created/modified prior to 4.8.0 and if the Text widget determines it contains markup that TinyMCE could potentially corrupt (including if there are line breaks and the auto-paragraphing checkbox was unchecked), then it will revert to the legacy mode with the the addition of a notice, according to the patch proposed on #40951:

And what about shortcodes that add content with html markup? I still see a lot of cases with forms, etc where this won't work.

#42 in reply to: ↑ 39 ; follow-up: @dfterry
7 years ago

Replying to westonruter:

(including if there are line breaks and the auto-paragraphing checkbox was unchecked),

What if auto paragraphing was disabled in a function and the checkbox does not match?

#43 in reply to: ↑ 41 @westonruter
7 years ago

Replying to emmtre:

And what about shortcodes that add content with html markup? I still see a lot of cases with forms, etc where this won't work.

Good point about shortcodes. The wpautop function is going to run on the widget_text_content filter at priority 10. This is after the widget_text filter applies. So if you have a plugin that add shortcode handling to the Text widget (since shortcodes are not processed by default in core) then it's true that wpautop could cause problems. So probably the solution here is to add another condition to the legacy mode detection to include the case when a shortcode is detected.

Plugins that add shortcode support for the Text widget should use the widget_text_content filter at priority 11, in the same way that core applies shortcodes on the the_content filter at priority 11, whereas wpautop runs at priority 10.

Patch has been updated on that ticket to implement this: https://core.trac.wordpress.org/ticket/40951#comment:106

#44 in reply to: ↑ 42 ; follow-up: @westonruter
7 years ago

Replying to dfterry:

Replying to westonruter:

(including if there are line breaks and the auto-paragraphing checkbox was unchecked),

What if auto paragraphing was disabled in a function and the checkbox does not match?

How would a function do this? The legacy mode detection in the patch is currently looking for whether the checkbox was checked and whether there are line breaks in the widget's text:

<?php
$wpautop = ! empty( $instance['filter'] );
$has_line_breaks = ( false !== strpos( $instance['text'], "\n" ) );

// If auto-paragraphs are not enabled and there are line breaks, then ensure legacy mode.
if ( ! $wpautop && $has_line_breaks ) {
        return true;
}

#45 in reply to: ↑ 44 @dfterry
7 years ago

Replying to westonruter:

Replying to dfterry:

Replying to westonruter:

(including if there are line breaks and the auto-paragraphing checkbox was unchecked),

What if auto paragraphing was disabled in a function and the checkbox does not match?

How would a function do this? The legacy mode detection in the patch is currently looking for whether the checkbox was checked and whether there are line breaks in the widget's text:

This disables I believe.

<?php
 remove_filter('widget_text_content', 'wpautop');

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


7 years ago

#47 @westonruter
7 years ago

  • Keywords commit added

#48 @westonruter
7 years ago

  • Severity changed from critical to normal

#49 @westonruter
7 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 41067:

TinyMCE: respect the Disable the visual editor when writing user setting and don't output the TinyMCE components when using wp_enqueue_editor().

Merges [40991] onto 4.8 branch.
Props azaozz.
Fixes #40960 for 4.8.1.

#50 @dfterry
7 years ago

So this is sort of fixed as long as you know to go to User->Your Profile and Disable Visual Editor before going into Apeparance->Widgets where you would need to copy each Text Widget into a new Custom HTML Widget.

#51 @westonruter
7 years ago

@dfterry if you have custom HTML in the Text widget that was saved prior to 4.8, then it will open in a legacy mode without TinyMCE. That is the way it is designed, in any case. It has logic to detect whether or not the contents of a Text widget contains any HTML markup that would be liable to be munged by TinyMCE, and if so, it enables the legacy mode. See https://make.wordpress.org/core/2017/08/01/fixes-to-text-widget-and-introduction-of-custom-html-widget-in-4-8-1/

#52 @pracko
7 years ago

Last edited 7 years ago by pracko (previous) (diff)
Note: See TracTickets for help on using tickets.