WordPress.org

Make WordPress Core

Opened 7 weeks ago

Closed 5 days ago

Last modified 5 hours ago

#40907 closed feature request (fixed)

Introduce widget dedicated for HTML code

Reported by: westonruter Owned by: westonruter
Milestone: 4.8.1 Priority: normal
Severity: normal Version: 4.8
Component: Widgets Keywords: has-patch has-unit-tests commit fixed-major
Focuses: Cc:

Description (last modified by 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

Attachments (9)

initial-design.png (88.8 KB) - added by westonruter 6 weeks ago.
40907.0.diff (6.0 KB) - added by westonruter 6 weeks ago.
https://github.com/xwp/wordpress-develop/pull/233
initial-design-with-preview.png (335.6 KB) - added by westonruter 6 weeks ago.
40907.1.diff (11.1 KB) - added by westonruter 6 weeks ago.
Add unit tests and address PR feedback from timmydcrawford: https://github.com/xwp/wordpress-develop/pull/233/files/d75cfaa29632fc6191b6b11b456d9494a14c76df..a270b828b61df8b251600346e86a0c987dcf3d66
40907-rename.0.diff (10.0 KB) - added by westonruter 4 weeks ago.
https://github.com/xwp/wordpress-develop/pull/236
40907-wide-widget.0.diff (1.4 KB) - added by westonruter 3 weeks ago.
Let the Custom HTML widget be wide like the Text widget is
custom-html-widget-shortcode-support.diff (1.2 KB) - added by westonruter 6 days ago.
apply-widget_text-filter-in-custom-html-widget.diff (2.2 KB) - added by westonruter 6 days ago.
apply-widget_text-filter-in-custom-html-widget.2.diff (5.3 KB) - added by westonruter 5 days ago.

Download all attachments as: .zip

Change History (82)

#1 @westonruter
7 weeks ago

  • Description modified (diff)

#2 @westonruter
7 weeks ago

  • Description modified (diff)

#3 follow-ups: @sami.keijonen
7 weeks ago

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

#4 in reply to: ↑ 3 @Kopepasah
7 weeks ago

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.

Last edited 7 weeks ago by Kopepasah (previous) (diff)

#5 in reply to: ↑ 3 @westonruter
7 weeks ago

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).

#6 @jbpaul17
7 weeks ago

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.

#7 follow-up: @westonruter
7 weeks ago

@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.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


7 weeks ago

#9 @westonruter
7 weeks ago

  • Description modified (diff)

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


7 weeks ago

#11 @welcher
7 weeks ago

  • Keywords good-first-bug added

#12 @carasmo
6 weeks ago

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.

#13 @carasmo
6 weeks ago

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

This ticket was mentioned in Slack in #forums by jeffr0. View the logs.


6 weeks ago

#15 @westonruter
6 weeks ago

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.

#16 @westonruter
6 weeks ago

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.

#17 @vfontj
6 weeks ago

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/

#18 @westonruter
6 weeks ago

  • Keywords good-first-bug removed
  • Owner set to westonruter
  • Status changed from new to accepted

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

#19 @westonruter
6 weeks ago

  • Keywords has-patch needs-testing needs-unit-tests added; needs-patch removed
  • Version set to 4.8

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


6 weeks ago

#21 @westonruter
6 weeks ago

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.

#22 @westonruter
6 weeks ago

  • Keywords has-unit-tests added; needs-testing needs-unit-tests removed

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

#23 @westonruter
6 weeks ago

  • Keywords commit added

@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.

#24 follow-up: @westonruter
6 weeks ago

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

#25 @westonruter
6 weeks ago

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

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.

#26 @westonruter
6 weeks ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

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

#27 in reply to: ↑ 24 @Ipstenu
6 weeks ago

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 :/

#28 @dd32
6 weeks ago

#41053 was marked as a duplicate.

#29 in reply to: ↑ 3 @kaushik07
6 weeks ago

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.

#30 @pipdig
6 weeks ago

+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?

#31 follow-up: @alexvorn2
5 weeks ago

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.

#32 in reply to: ↑ 31 @synavista
5 weeks ago

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.

#33 in reply to: ↑ 3 @piggybanktechnology
5 weeks ago

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.

#34 @theMikeD
5 weeks ago

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

#35 follow-up: @FolioVision
5 weeks 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.

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


5 weeks ago

#37 @philclothier
5 weeks ago

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.

Last edited 5 weeks ago by philclothier (previous) (diff)

#39 follow-up: @westonruter
4 weeks ago

@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.

Last edited 4 weeks ago by westonruter (previous) (diff)

This ticket was mentioned in Slack in #core-editor by westonruter. View the logs.


4 weeks ago

#41 in reply to: ↑ 39 @melchoyce
4 weeks ago

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.)

#42 @westonruter
4 weeks ago

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

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


4 weeks ago

#44 @westonruter
4 weeks ago

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.

#45 in reply to: ↑ 35 ; follow-up: @slewisma
4 weeks ago

+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:

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.

#46 in reply to: ↑ 45 ; follow-up: @alexvorn2
4 weeks ago

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.

#47 @alexvorn2
4 weeks ago

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

Last edited 4 weeks ago by alexvorn2 (previous) (diff)

#48 in reply to: ↑ 46 @slewisma
4 weeks ago

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.

#49 follow-up: @FolioVision
4 weeks ago

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.

Last edited 4 weeks ago by FolioVision (previous) (diff)

#50 in reply to: ↑ 49 @carasmo
4 weeks ago

Replying to FolioVision

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

#51 follow-up: @philclothier
4 weeks ago

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?

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


4 weeks ago

#53 @seothemes
3 weeks ago

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
3 weeks ago

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

#54 @westonruter
3 weeks ago

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.

#55 in reply to: ↑ 51 ; follow-up: @westonruter
3 weeks ago

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.

#56 in reply to: ↑ 55 @philclothier
3 weeks ago

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.

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


3 weeks ago

#58 in reply to: ↑ 7 @wido
2 weeks ago

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...?

#59 @westonruter
2 weeks ago

@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

#60 @westonruter
10 days ago

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

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.

#61 follow-ups: @westonruter
6 days ago

  • Keywords commit fixed-major removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

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?

#62 in reply to: ↑ 61 @slewisma
6 days ago

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?

#63 @westonruter
6 days ago

@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.

#64 in reply to: ↑ 61 ; follow-up: @bobbingwide
6 days ago

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.

#65 in reply to: ↑ 64 ; follow-up: @westonruter
5 days ago

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.

#66 @westonruter
5 days ago

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

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.

#67 @westonruter
5 days ago

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.

#68 @westonruter
5 days ago

  • Keywords commit fixed-major added

#69 @westonruter
2 days ago

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.

#70 @westonruter
2 days ago

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.

#71 @westonruter
2 days ago

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.

#72 in reply to: ↑ 65 @bobbingwide
19 hours ago

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.

#73 @westonruter
5 hours ago

@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.

Note: See TracTickets for help on using tickets.