Introduce widget dedicated for HTML code

[westonruter]

As summarized in ​Dev Chat Summary: May 31st (4.8 week 5), the Text widget as of 4.8 uses the same TinyMCE editor as the edit post screen. Like the WP editor, it has a Visual tab and a Text tab, where a user can supply raw HTML in the latter. What is removed from the Text widget is the “auto add paragraphs” checkbox which allowed a user to control whether or not wpautop was applied to the text. This was removed to align the widget's behavior with the post editor, where wpautop is always applied. As noted in the ​TinyMCE Text Widget post, the behavioral changes to the Text widget means that users who have previously pasted 3rd party HTML into the Text widget may encounter extra line breaks if the HTML copied includes extra line breaks for readability (as normally line breaks in HTML are not significant). This extra line break issue is more problematic when pasted 3rd-party HTML includes JavaScript, wpautop can currently (erroneously) add p tags inside of script elements (see #2833).

So, in order to facilitate users being able to paste in arbitrary HTML, a new “HTML Code Widget” can be introduced.

At a minimum, the widget could look the same as the old Text widget except (again) without the checkbox to wpautop, where in this case it does not get applied.

The textarea should have the same fixed-width font styling applied as the Text (HTML) tab of the post editor.

It would also be ideal for the HTML code widget to make use of CodeMirror to provide syntax highlighting and checking, however this depends on #12423, which is currently blocked due to CodeMirror not being fully accessible. Use of CodeMirror has also been proposed for as well as Additional CSS in the Customizer and the Text tab in the post editor.

When the user does not have the unfiltered_html capability, the HTML code widget should also indicate the HTML tags that are allowed and anything not allowed will be stripped. It seems logical that the HTML code widget should allow the same tags that are allowed in post content.

Suggested PHP class name: WP_Widget_HTML_Code
Suggested widget ID base: html_code

[sami.keijonen]

Why not leave the old text widget and have TinyMCE widget as a new widget? That would not break anything.

[Kopepasah]

Why not leave the old text widget and have TinyMCE widget as a new widget? That would not break anything.

I agree with @sami.keijonen here, but it may be too little too late to make a revert.

That aside, I think the suggest class name and id are fine.

[westonruter]

Replying to sami.keijonen:

Why not leave the old text widget and have TinyMCE widget as a new widget? That would not break anything.

True, and this was brought up during the ​dev chat. But 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).

[jbpaul17]

Are we purposely NOT supporting JavaScript in this new widget? The proposed title of "HTML Code Widget" to me means it would NOT support JavaScript. However, from the dev chat it seemed that JS snippets was an expected use case.

[westonruter]

@jbpaul17 by “HTML Code” it is meant to accept any acceptable HTML, and that includes script tags (if the user can unfiltered_html). This would contrast with a “JavaScript Code” (or “CSS Code”) widget which would expect just code in that language.

[carasmo]

Many people use the old text widget for html and it was great, now it's autowp in my sign up forms and other stuff. This is actually horrible.

[carasmo]

I forked it. Hopefully someone will come along with a plugin. I can't do it for until time allows.

​https://gist.github.com/carasmo/d29722a1ef7e1ebe29125661ed3690a2

[westonruter]

I think the (TinyMCE) Text widget might also warrant having a comment that suggests users to use the HTML Code widget if they switch to the Text tab.

[westonruter]

At least when the HTML Code widget lands, there should be a admin pointer that appears when the user clicks the Text (HTML) tab of the Text widget and notifies users of the new widget specifically intended for arbitrary HTML.

[vfontj]

Until there's a new widget, here is a plugin that restores the classic WordPress text widget. It has been submitted to the repository, but until it is approved, it can be downloaded here: ​https://victorfont.com/go/classic-text-widget/

The source is on Github here: ​https://victorfont.com/go/classic-text-widget-source/

[westonruter]

Given the perceived urgency of having a plain HTML Code widget in trunk for testing and the next minor release, I'll take this.

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/233

[westonruter]

I didn't include the .textwidget wrapper around the content that is printed, so a <div class="textwidget"> would need to be added if a user wanted to have all of the styles that would apply to a text widget.

We should also check to make sure there isn't an existing widget with html_code as its ID base in the repo, and that the WP_Widget_HTML_Code class isn't used for that matter.

[westonruter]

Add unit tests and address PR feedback from timmydcrawford: ​https://github.com/xwp/wordpress-develop/pull/233/files/d75cfaa29632fc6191b6b11b456d9494a14c76df..a270b828b61df8b251600346e86a0c987dcf3d66

[westonruter]

Note that 40907.1.diff​ introduces new files. Will this work in a 4.8.1 minor release or not?

[westonruter]

@melchoyce should we update the Text widget's description from “Arbitrary text or HTML” to be something like “Arbitrary content”? This is because we want to direct users away from using the Text widget now for arbitrary HTML.

[westonruter]

@ipstenu would you please ack PHP files for ['"]html_code['"] and WP_Widget_HTML_Code in the plugin directory?

[westonruter]

In 40893:

Widgets: Add widget dedicated for HTML Code, taking over this role of the Text widget.

Props westonruter, timmydcrawford.
See #40951, #35243.
Fixes #40907.

[westonruter]

Re-opening for consideration in 4.8.1, committing to the 4.8 branch though note the presence of new files.

[Ipstenu]

Replying to westonruter:

@ipstenu would you please ack PHP files for ['"]html_code['"] and WP_Widget_HTML_Code in the plugin directory?

FYI, due to WCEU I won't be able to until I get to ... Paris :/

[dd32]

#41053 was marked as a duplicate.

[kaushik07]

Replying to sami.keijonen:

Why not leave the old text widget and have TinyMCE widget as a new widget? That would not break anything.

I Agree too. This will be best solution.

[pipdig]

+1 for a dedicated "HTML" widget, with a new "TinyMCE" or "Visual" widget separately. It seems strange that this wasn't the original plan. Out of curiosity, what was the rationale behind the decision to avoid that?

[alexvorn2]

Widget name is - "Text" widget, so it means you can add text not html code, so the way it goes by adding a new HTML widget is right, I think.

[synavista]

Replying to alexvorn2:

Widget name is - "Text" widget, so it means you can add text not html code, so the way it goes by adding a new HTML widget is right, I think.

Except for the fact that the description for the Text Widget is "Arbitrary text or HTML."

Nullifying/removing ANY existing HTML code makes the new widget bad by design.

[piggybanktechnology]

Replying to sami.keijonen:

Why not leave the old text widget and have TinyMCE widget as a new widget? That would not break anything.

I agree this is the right thing to do. Updates that break existing widgets are not cool. If the ability to put code in a widget is to disappear, there should at least be a "deprecated" period to give people time to find a new solution for widgets with code in them, and implement it.

[theMikeD]

I appreciate what is trying to be done here. But the core issue is that the addition of the rich text stuff to the text widget is breaking sites that use the text widget for arbitrary html. This is is a breaking change. Full stop. It cannot be reverted without a full DB backup and will just happen again the next time the widget is edited.

The mantra of WP is backwards compatibility. This fails that test, badly.

There are other views on this in #40960 FTR

[FolioVision]

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

• Introduce widget dedicated for HTML code
• New Text Widget - Switching Between Visual/Text Editor Strips Out Code
• 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 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.

[anonymized_11892634]

I can only echo your sentiments @FolioVision.

What is the planned fix for 4.8.1? Am I correct in thinking that the current plan is to create a new HTML widget? Is the recommended solution to instruct people to move to that new type of widget? If so, this is what my inbox is going to be filled with for the next few months:

Client: Why has the "........" widget stopped working?
Me: Are you using WordPress 4.8?
Client: I think so.
Me: You will need to copy the content from the Text widget which created this feature (make sure you switch to HTML view in the Text widget first). Then create a new widget using the "HTML" widget type. Then paste the previous HTML into this. If the widget still doesn't display correctly then you may need to retrieve the HTML from the original source or from a backup of your site.
Client: Why?
Me: I don't know.
Client: I'm never updating WordPress again.

[westonruter]

@philclothier please see https://core.trac.wordpress.org/ticket/40951#comment:63

[westonruter]

@melchoyce so per ​Slack, should we change the name of this widget to “Custom HTML” which will align with the corresponding block of the same name in Gutenberg? This is to distinguish the widget/block from something that just displays HTML code with syntax highlighting, as @jbpaul17 above initially interpreted it to be (in a Slack conversation I think). Gutenberg has a “Code” block for displaying such syntax-highlighted code.

[melchoyce]

Replying to westonruter:

@melchoyce so per ​Slack, should we change the name of this widget to “Custom HTML” which will align with the corresponding block of the same name in Gutenberg?

Yeah, let's go with "Custom HTML."

FWIW, I also think "Additional CSS" should be "Custom CSS," but I know @folletto has opposing thoughts on that position. (It's just felt so weird in context to me.)

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/236

[westonruter]

Widget rename in 40907-rename.0.diff​. I believe I've caught every replacement required. A second pair of 👀 would be appreciated.

[westonruter]

In 40926:

Widgets: Rename "HTML Code" widget to "Custom HTML" widget.

Correspondingly renames files, ID base from html_code to custom_html, and the filter from widget_html_code_content to widget_custom_html_content.

See #40907.

[slewisma]

+1 this explanation and position. Anything other than a solution that allows editing existing text widgets that contain arbitrary html, css and js is going to leave a lot of sites waiting to break and no admin accessible way to reliably recover the widget content to move it elsewhere.

I've got three client sites mid-development that cannot continue right now because the "improved" text widget breaks the ability to edit a text widget at all if it is in a Toolset Layout as a single widget and regular use of the text widget in a widget area "eats" existing content when opening the widget for editing. Yes I can go find the widget contents in MySQL to try to salvage it and re-introduce it another way but that is not practical.

Kudos to the many who are introducing work-arounds in the form of forked classic text widgets and import export tools but most of those mean wandering away from the out of the box Wordpress way and not easily coming back. It'd be far better to fix this fast by reverting to the prior version then work out the best way to introduce rich text widgets while all our sites are once again manageable and reliable.

I have no issue with renaming the old text widget to something like html widget as long as it doesn't break existing sites'''

Replying to FolioVision:

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

• Introduce widget dedicated for HTML code
• New Text Widget - Switching Between Visual/Text Editor Strips Out Code
• 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 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.

[alexvorn2]

Replying to slewisma:

I've got three client sites mid-development that cannot continue right now because the "improved" text widget breaks the ability to edit a text widget at all if it is in a Toolset Layout as a single widget and regular use of the text widget in a widget area "eats" existing content when opening the widget for editing. Yes I can go find the widget contents in MySQL to try to salvage it and re-introduce it another way but that is not practical.

Does the code breaks in Text Editor when you create a new post? Maybe that because how
wp_editor works, so that is the fault of the TinyMCE editor.
We could release the old Text widget as a plugin for everyone so your clients could continue work.

[alexvorn2]

Maybe this plugin will help as replacement for old widget - ​https://wordpress.org/plugins/enhanced-text-widget/

[slewisma]

If the old text widget is released as a plugin, will it be the default widget that opens existing text widgets? If not, it is not a good solution as users will still not have a way to open the existing widgets to copy what is in there now out to put in another kind of widget. And having to move the contents of all text widgets that contain html, css or js to another type of widget will take millions of hours of admin time across the universe for no good reason other than working around a poor plan / decision / implementation? Not a good way to go in my opinion. Meanwhile innocent admins that don't know better will break their sites and have to go searching for the solution. Also not a good plan.

If the solution drops in and takes over the management of all existing text widgets and users have the option of replacing those with the new widget if they want rich text, that is preferred. But, really, wouldn't it be best to figure out how to make sure the one, single text widget can serve both needs? Many years of habits have admins everywhere using the text widget mostly to insert html and shortcodes in places they cannot reach with the visual editor. And it is useful to sometimes put html and inline css in the post and page editor too so the use of tinyMCE should be more friendly to embedded html/css/js/shortcodes all around. Again, my opinion, based on watching client editors and admins make mistakes often over not knowing what the visual editor will do to what they're inserting.

Replying to alexvorn2:

Replying to slewisma:

I've got three client sites mid-development that cannot continue right now because the "improved" text widget breaks the ability to edit a text widget at all if it is in a Toolset Layout as a single widget and regular use of the text widget in a widget area "eats" existing content when opening the widget for editing. Yes I can go find the widget contents in MySQL to try to salvage it and re-introduce it another way but that is not practical.

Does the code breaks in Text Editor when you create a new post? Maybe that because how
wp_editor works, so that is the fault of the TinyMCE editor.
We could release the old Text widget as a plugin for everyone so your clients could continue work.

[FolioVision]

I've been thinking hard about this as well @slewisma. The proposed solution by westonruter is really a half measure and inadequate (thank you again for your hard work, Weston, you've done your best with an impossible brief). The only viable solution would be to add an HTML widget and leave the text widget alone. Apparently Matt doesn't want to do that (I'm not in the Slack conversation about it but that's what's reported). Matt summoned quora in Slack and pronounced an edict - this is not democratic in any shape or form. It doesn't serve the project or its existing users.

Matt wants this as it would suit WordPress.com and the strange grasping for low-end marketshare (people who aren't competent to manage websites or hosting and have no business having a self-hosted WordPress, Drupal, Joomla install - these users should be on WordPress.com, Typepad, SquareSpace or Tumblr - Medium would be too complex for them). These "new users" will just poison the WordPress ecosphere with absurd support demands and soil the project's reputation with complaints about broken sites. Our only hope is that they won't be able to find WordPress.org or use the plugin directory at all (otherwise every plugin created for a user with an IQ above room temperature will quickly slide to a 2 rating).

There seems to be very little respect among the current WordPress core team (it seems to me a voting majority are directly on the Automattic payroll) for mid-tier Wordpress users and agencies. Agencies and developers who have built the WordPress project and created the ecosphere from which Automattic now profits.

This makes users and agencies very angry, Matt. If your goal is to diminish the reputation of the WordPress project and continue to make agencies lives a misery by 1. too frequent updates 2. no real improvements (target areas could include performance, stability, security holes, native comments, native caching) 3. breaking updates, keep on trucking.

I've written you privately that there's no sin in making a mistake but there is a great sin in persisting in it.

What's needed here is to add an html widget and leave the text widget alone. There's no good reason to break WordPress yet again, particularly after the security debacle of WordPress 4.7.x. Those (foolish) early adopters who may already have broken widgets from too early upgrade to WordPress 4.8 should get some kind of compromise solution like the one Weston has worked so hard on (remigrating their widgets back to text after they've fought through the issues) wouldn't be fair either.

Those of you who are looking for a way to discreetly postpone these issues can use ​BusinessPress to stay on WordPress 4.6.x or WordPress 4.7.x with security updates until there's finally a drop-in solution. What a tremendous waste of everyone's time this misstep is.

[carasmo]

Replying to FolioVision

Very well written. I agree. I'm installing Business Press on everything as soon as possible.

[anonymized_11892634]

I would also much prefer that the Text widget is reverted back and renamed "HTML". The more I think about it, the more the current solution seems so backwards. Instead of simply creating a new Visual widget, we've got a fudged Text widget which then suggests that people use the new HTML widget. It's a horrific UX which does nothing to promote WordPress as straight forward and "user first".

What would be the negative impact of the following actions @westonruter?

1. Revert 'Text' widget to previous version.
2. Rename 'Text' widget to 'HTML Code'.
3. Create new 'Visual' widget using the 4.8 'Text' widget functionality.

Is this solution on the table at the moment? Or have you decided to press on with the currently developed plan?

[seothemes]

If anyone's interested I've made a plugin based on Weston's code and integrated codemirror for syntax highlighting. ​https://wordpress.org/plugins/html-widget/

[westonruter]

Let the Custom HTML widget be wide like the Text widget is

[westonruter]

In 41000:

Widgets: Let Custom HTML widget be "wide" as the Text widget is.

Also update WP_Customize_Widgets::$core_widget_id_bases with the new list of core widgets.

Props obenland, westonruter.
See #40907, #40951.

[westonruter]

Replying to philclothier:

Is this solution on the table at the moment? Or have you decided to press on with the currently developed plan?

I think it is off the table at the moment, yes. It was the second solution that I outlined in #40951 (comment 63). The third solution there, however, is what I honestly think is the best and it's what got the most 👍 from the core team, and this third is the solution that is currently being implemented here and #40951: adding a new Custom HTML widget and then introducing a legacy mode to the Text widget to preserve old HTML, while also adding pointers to direct users to use the new Custom HTML widget going forward.

[anonymized_11892634]

Replying to westonruter:

I think it is off the table at the moment, yes. It was the second solution that I outlined in #40951 (comment 63). The third solution there, however, is what I honestly think is the best and it's what got the most 👍 from the core team, and this third is the solution that is currently being implemented here and #40951: adding a new Custom HTML widget and then introducing a legacy mode to the Text widget to preserve old HTML, while also adding pointers to direct users to use the new Custom HTML widget going forward.

Ok that's fair enough. To me it seems like this is the long way around, but I'll trust your judgement. Hopefully 4.8.1 can be pushed soon so we can move forward with updated instructions for end users.

[wido]

Replying to westonruter:

@jbpaul17 by “HTML Code” it is meant to accept any acceptable HTML, and that includes script tags (if the user can unfiltered_html). This would contrast with a “JavaScript Code” (or “CSS Code”) widget which would expect just code in that language.

What about #37085 with kses_post allowed html tags? Should not allow forms, inputs, textarea etc...?

[westonruter]

@wido It will currently allow whatever is allowed in post content. So if Kses is expanded to allow for more tags in post content, then those tags will be allowed in the Custom HTML widget. This only applies if a user doesn't have the unfiltered_html capability, in which case they can use any HTML whatsoever

[westonruter]

In 41044:

Widgets: Add Custom HTML widget.

Ports [40893], [40926], [41000] to the 4.8 branch.
Props westonruter, timmydcrawford, obenland.
Fixes #40907 for 4.8.

[westonruter]

As noted in #40951 (comment 154), we may want to update the Custom HTML widget to explicitly add the just-in-time shortcode support if a plugin had added support for it. See custom-html-widget-shortcode-support.diff​. This would ensure that if a user moves from a Text widget to a Custom HTML widget, the shortcode handling will still work.

Alternatively, we could just go ahead and apply all the widget_text filters to the Custom HTML instance instead. See apply-widget_text-filter-in-custom-html-widget.diff​.

Thoughts?

[slewisma]

Many sites where the new text widget created challenges for me also depend on shortcodes in widgets as enabled in my plugin or functions.php code.

The issue of how / whether to apply filters from the text widget to the html widget is a battle of bad choices in my opinion. The cleanest solution would be to give the html widget its own filters and ask us to enable shortcode processing if we need it but I appreciate the magnitude of backwards compatibility impacts of doing this the "right", clean way.

If either of the alternatives (just enable shortcodes if they are enabled explicitly for the text widget or apply all text widget filters to the html widget) are implemented, is there a way to make it a short-term solution and indicate that developers should add filters to html widgets explicitly by some future date or release?

Replying to westonruter:

As noted in #40951 (comment 154), we may want to update the Custom HTML widget to explicitly add the just-in-time shortcode support if a plugin had added support for it. See custom-html-widget-shortcode-support.diff​. This would ensure that if a user moves from a Text widget to a Custom HTML widget, the shortcode handling will still work.

Alternatively, we could just go ahead and apply all the widget_text filters to the Custom HTML instance instead. See apply-widget_text-filter-in-custom-html-widget.diff​.

Thoughts?

[westonruter]

@slewisma there would still be:

• the widget_custom_html_content filter that only applies to the Custom HTML widget, and
• the widget_text_content filter that only applies to the Text widget

My suggestion is that we take the widget_text filter which currently applies before the widget_text_content filter, to also apply it before the widget_custom_html_content filter. Thus the widget_text filter would apply in both widgets.

This would remain in place going forward, but eventually the widget_text filter could get marked as deprecated, in favor of using the widget_text_content and widget_custom_html_content filters only.

[bobbingwide]

Replying to westonruter:

As noted in #40951 (comment 154), we may want to update the Custom HTML widget to explicitly add the just-in-time shortcode support if a plugin had added support for it. See custom-html-widget-shortcode-support.diff​. This would ensure that if a user moves from a Text widget to a Custom HTML widget, the shortcode handling will still work.

Tests should be other way around and the filter shouldn't be removed once added.

Alternatively, we could just go ahead and apply all the widget_text filters to the Custom HTML instance instead. See apply-widget_text-filter-in-custom-html-widget.diff​.

Thoughts?

Balancetags should be applied during save.

[westonruter]

Replying to bobbingwide:

Tests should be other way around

How so?

the filter shouldn't be removed once added.

I disagree. If we just-in-time add a filter, we should just-in-time remove it as well, to clean up after ourselves.

Balancetags should be applied during save.

I don't disagree with you, but this is just following how the Text widget is currently behaving. Somewhat strangely, there is actually an option use_balanceTags that is by default false and there is no UI for changing that. And when this option is false, then balanceTags does nothing. So perhaps the update method for the Custom HTML widget should in reality call the force_balance_tags function, but I think there is a problem with it and that is why there is a user preference to begin with: it can munge HTML, for example #39847. So I think we need a more reliable HTML validator before we forcibly apply it unconditionally.

[westonruter]

In 41086:

Widgets: Replace adding balanceTags on widget_custom_html_content filter in favor of just applying widget_text filters in the Custom HTML widget.

Ensures that users who copy HTML from the Text widget in legacy mode over to the Custom HTML widget will continue to get all of the same filters applied, including tag balancing and shortcodes, if a plugin added support. Plugins still have the widget_text_content and widget_custom_html_content filters they can use to target the specific widget types.

Amends [40893].
See #40951.
Fixes #40907 for trunk.

[westonruter]

In 41087:

Widgets: Replace adding balanceTags on widget_custom_html_content filter in favor of just applying widget_text filters in Custom HTML widget.

Ensures that users who copy HTML from the Text widget in legacy mode over to the Custom HTML widget will continue to get all of the same filters applied, including tag balancing and shortcodes, if a plugin added support. Plugins still have the widget_text_content and widget_custom_html_content filters they can use to target the specific widget types.

Merges [41086] onto 4.8 branch.
Amends [40893].
See #40951.
Fixes #40907 for 4.8.1.

[westonruter]

In 41115:

Widgets: Improve theme styling compatibility for Custom HTML widget by adding container with textwidget class.

The same styling from the Text widget should apply to the Custom HTML widget since users are expected to copy HTML from the (legacy) Text widget into the latter.

Amends [40893].
See #40907.
Fixes #41392.

[westonruter]

In 41116:

Widgets: Include widget_text class name on Custom HTML widget wrapper for theme styling compatibility, in addition to previously-added textwidget class on nested content container.

Amends [40893], [41115].
See #40907.
Fixes #41392 for trunk.

[westonruter]

In 41117:

Widgets: Improve theme styling compatibility for Custom HTML widget by adding content container with textwidget class and widget_text class on widget wrapper element.

The same styling from the Text widget should apply to the Custom HTML widget since users are expected to copy HTML from the (legacy) Text widget into the latter.

Merges [41115] and partially [41116] onto 4.8 branch.
Amends [40893].
See #40907.
Fixes #41392 for 4.8.1.

[bobbingwide]

Replying to westonruter:

option use_balanceTags that is by default false and there is no UI for changing that.

So what's the checkbox labelled 'WordPress should correct invalidly nested XHTML automatically' in Settings > Writing > Formatting for?

But yes, I agree that balancing tags should not be forced either on save or display.

[westonruter]

@bobbingwide now that you mention it, I did seem to recall there being such an option. However, I haven't seen it in quite some time. It doesn't appear on my Writing settings page. It turns out that the option only appears on old installs: ​https://github.com/WordPress/wordpress-develop/blob/4.8.0/src/wp-admin/options-writing.php#L59-L69

The option was removed in [32454] for #5161.

[westonruter]

In 41132:

Widgets: Rename Text widget's legacy mode to non-visual mode, restore boolean filter prop, and improve compatibility for widget_text filters applied in Custom HTML widget.

Props westonruter, obenland, timmydcrawford for testing.
Amends [41050].
See #35243, #40951, #40907.
Fixes #41394.

[westonruter]

In 41133:

Widgets: Rename Text widget's legacy mode to non-visual mode, restore boolean filter prop, and improve compatibility for widget_text filters applied in Custom HTML widget.

Merges [41132] onto 4.8 branch.
Amends [41050].
Props westonruter, obenland, timmydcrawford for testing.
See #35243, #40951, #40907.
Fixes #41394 for 4.8.1.

[westonruter]

In 41134:

Widgets: Improve notice in Text widget's legacy mode.

Also fixes phpunit test which broke in [41132].

Props melchoyce, westonruter, gk.loveweb.
See #41394, #35243, #40951, #40907.
Fixes #41386.

[westonruter]

In 41135:

Widgets: Improve notice in Text widget's legacy mode.

Retains 'new' in notice on 4.8 branch, in contrast with [41134]. Also fixes phpunit test which broke in [41132].

Merges [41134] onto 4.8 branch.
Props melchoyce, westonruter.
See #41394, #35243, #40951, #40907.
Fixes #41386 for 4.8.1.

[westonruter]

👉 Please test the new “codemirror-wp” feature plugin—being worked on for 4.9—which extends the Custom HTML widget to add syntax highlighting and checking. It also adds CodeMirror to the Additional CSS control in the Customizer and also to the file editors for themes and plugins. See the releases page to download a ZIP of the plugin for easy installation: ​https://github.com/WordPress/codemirror-wp

Report any issues at ​https://github.com/WordPress/codemirror-wp/issues

[anonymized_11892634]

Just testing ​https://github.com/WordPress/codemirror-wp now and it seems to work well. I'll keep playing with it. However, whilst doing that, this did raise another completely unrelated question (sorry).

Do we really need to have the word "Custom" in the widget name? Why not just "HTML"? When I did a quick visual scan looking for the widget, I immediately jumped to the "H" for HTML but couldn't see it. What's the difference between "HTML" and "Custom HTML" anyway?

Why don't we have "Custom Audio" and "Custom Text"?

[melchoyce]

Replying to philclothier:

Do we really need to have the word "Custom" in the widget name? Why not just "HTML"? When I did a quick visual scan looking for the widget, I immediately jumped to the "H" for HTML but couldn't see it. What's the difference between "HTML" and "Custom HTML" anyway?

It was named "Custom HTML" to match the new Gutenberg block (see #comment:39). We could name it HTML, but then we'd just need to rename it again (or reconsider the block name) once we convert widgets to blocks.

[alexvorn2]

Replying to melchoyce:

once we convert widgets to blocks.

what do you mean? the widgets will get converted to blocks? when? :|

[melchoyce]

Replying to alexvorn2:

Replying to melchoyce:

once we convert widgets to blocks.

what do yo mean? the widgets will get converted to blocks? when? :|

The longterm vision is to convert all widgets to blocks, yes. We'll likely start exploring this around the middle/end of next year (or maybe even later, depending on how things go with Gutenberg).