WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 6 months ago

Last modified 2 months ago

#35243 closed enhancement (fixed)

Extending the text widget to also allow visual mode

Reported by: paaljoachim Owned by: westonruter
Milestone: 4.8 Priority: normal
Severity: normal Version:
Component: Widgets Keywords: has-patch commit needs-dev-note
Focuses: ui, accessibility Cc:

Description (last modified by westonruter)

TinyMCE widget by Black Studio is a very popular widget.
https://wordpress.org/plugins/black-studio-tinymce-widget/

What about adding a TinyMCE (rich text) widget to WordPress Core?

Attachments (3)

text-widget.png (20.0 KB) - added by melchoyce 11 months ago.
35243.0.diff (19.5 KB) - added by westonruter 7 months ago.
https://github.com/xwp/wordpress-develop/pull/230
35243.diff (23.5 KB) - added by obenland 7 months ago.
Add PHP unit tests

Download all attachments as: .zip

Change History (94)

#1 @swissspidy
2 years ago

  • Component changed from General to Widgets
  • Focuses administration removed

#2 @westonruter
23 months ago

Should this be adding a new widget or just extending the Text widget to allow a “visual” mode to accompany the current default HTML (with wpautop checkbox)?

This to me would seem much more user friendly, as I imagine most users wouldn't be wanting to enter raw HTML into a widget to achieve the desired results.

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


22 months ago

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


22 months ago

#5 @paaljoachim
22 months ago

  • Summary changed from Adding a TinyMCE widget to Core? to Extending the text widget to also allow visual mode.

That is a very good idea Weston!

#6 @westonruter
22 months ago

  • Description modified (diff)
  • Summary changed from Extending the text widget to also allow visual mode. to Extending the text widget to also allow visual mode

Depends on #35760 (Provide API for TinyMCE editor to be dynamically instantiated via JS)

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


22 months ago

#8 @jorbin
22 months ago

I don't really like this idea. TinyMCE carries a fairly large overhead to it, and this is going to create another place that needs to be tested for all of our editor changes.

Would love to hear what @iseulde or @azaozz think since they are the editor gurus.

#9 @westonruter
22 months ago

I can imagine if I were an end user/producer, though, that it would be very unhelpful/non-intuitive that I wouldn't be able to put rich text into a text widget. Users aren't going to know they have to enter HTML, and that is definitely not user-friendly.

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


19 months ago

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


19 months ago

#12 follow-up: @westonruter
11 months ago

I've opened an issue to add TinyMCE support to the Text widget via the JS Widgets plugin, which seems like a natural fit: https://github.com/xwp/wp-js-widgets/issues/25

#13 @westonruter
11 months ago

  • Milestone changed from Awaiting Review to Future Release

#14 @melchoyce
11 months ago

I agree that the text widget should have some basic text formatting options, like bold, italic, lists, and links. Maybe even media. ;) (#32417) As a user, I expect to be able to add a link to my widgets without needing to know HTML.

Mocked up in text-widget.png.

#15 in reply to: ↑ 12 ; follow-up: @azaozz
11 months ago

Replying to westonruter:

I've opened an issue to add TinyMCE support to the Text widget via the JS Widgets plugin

Yeah, this is a good idea and has been long time coming. There are still a few things to consider/meet before starting on this:

  1. It would be pretty bad to repeat the errors from the "Custom CSS" implementation. First thing to do when core is "absorbing" the features of a plugin is to contact the plugin's authors, and try to get them on board. If nothing else, this is a common courtesy.
  1. There was a Feature Project to add a Media (image/audio/video) widget. Is it worth merging with it or taking it over? Having HTML editing support would also mean the users will be able to add media there.
  1. Think we should fix/improve/change the way widgets are saved before we start expanding them. Saving widgets data in a custom post type makes most sense as far as I see. Implementing that API change, together with a way to convert old widgets data, should probably happen before we "absorb" that plugin functionality into core.
  1. I'm not sure if there are any plans for the UI in the customizer (is the mockup above for the "Widgets" screen or for the customizer sidebar?), but editing inline, i.e. not from the customizer sidebar or from a popup, would make things 100 times better.
Last edited 11 months ago by azaozz (previous) (diff)

#16 in reply to: ↑ 15 ; follow-ups: @westonruter
11 months ago

Let me clarify…

Replying to azaozz:

Replying to westonruter:

I've opened an issue to add TinyMCE support to the Text widget via the JS Widgets plugin

Yeah, this is a good idea and has been long time coming. There are still a few things to consider/meet before starting on this:

  1. It would be pretty bad to repeat the errors from the "Custom CSS" implementation. First thing to do when core is "absorbing" the features of a plugin is to contact the plugin's authors, and try to get them on board. If nothing else, this is a common courtesy.

Agreed. We need to do better at communicating with existing plugin authors. I will note that one of the authors was involved in writing Custom CSS and the Jetpack team was pinged, but we fell short at connecting until too late in the cycle.

My interest in adding TinyMCE to the Text widget in JS Widgets plugin is as a demonstration/prototype for how JS components can be integrated with a newly proposed JS-based widget foundation. The JS Widgets plugin is not anywhere close to merging so the TinyMCE Text widget would just be living there as a proof of concept that could in the future be incorporated into core after the proper feature plugin/project merge process. In other words, no core patch is in view here for the immediate future.

  1. There was a Feature Project to add a Media (image/audio/video) widget. Is it worth merging with it or taking it over? Having HTML editing support would also mean the users will be able to add media there.

I believe this is #32417, which has an overwhelming number of watchers and support. I recall it got bogged down with scope. @melchoyce do you see a TinyMCE Text widget being a simplification/superset of the media widget?

  1. Think we should fix/improve/change the way widgets are saved before we start expanding them. Saving widgets data in a custom post type makes most sense as far as I see. Implementing that API change, together with a way to convert old widgets data, should probably happen before we "absorb" that plugin functionality into core.

I agree widgets need architectural improvements before we start focusing on creating new widgets significantly. Storing widgets as a custom post type is proposed in #35669 (with feature plugin), however I don't think it's necessarily a dependency. Also #33507/#35574 improve widgets architecture to allow them work with JavaScript first-and-foremost, and the JS Widgets plugin is an implementation of these tickets. Adding JS components to widgets is currently very painful in core. So that's why I was thinking implementing a visual/rich Text widget there would make sense to prototype.

  1. I'm not sure if there are any plans for the UI in the customizer (is the mockup above for the "Widgets" screen or for the customizer sidebar?), but editing inline, i.e. not from the customizer sidebar or from a popup, would make things 100 times better.

I think the mockup is for how the widget would by default appear on the widgets admin screen and customizer alike. Inline/frontend editing of customizable elements (partials) doesn't yet have a ticket, AFAIK. But I think there are some good opportunities for allowing a widget control to appear floating next to a given rendered widget or also for the title and content (of the Text widget) to be edited inline with direct manipulation.

#17 in reply to: ↑ 16 ; follow-up: @melchoyce
11 months ago

  1. There was a Feature Project to add a Media (image/audio/video) widget. Is it worth merging with it or taking it over? Having HTML editing support would also mean the users will be able to add media there.

I believe this is #32417, which has an overwhelming number of watchers and support. I recall it got bogged down with scope. @melchoyce do you see a TinyMCE Text widget being a simplification/superset of the media widget?

There might still be merit to a standalone media widget, but I would be totally satisfied with having an "add media" button in the text widget.

#18 @Presskopp
11 months ago

If the widget titled TEXT will be opened more to media, wouldn't that make it more a "content" widget or "Side-Content" or something?? It's somehow related to the ticket #38061

#19 @knutsp
11 months ago

Create a new general content widget that have two primary options:

  1. Use existing content from posts/pages/CPTs in the same manner as for menus
  2. Add special content as text/rich text with media

Migrate all text widgets to this type.

Store this widget as a special built_in post type.

Special case: If such widget is changed from option 1 to option 2, the content is copied, may be modified and do no longer show the (possibly changed) content of the original post. Similar to menu labels for pages.

#20 @melchoyce
11 months ago

I think we're maybe thinking about this a little too much and getting off track. :)

We could consider renaming it to something like "content," but I honestly don't think it's that big of a deal to keep calling it "text," even if we do add an "add new media" option. Especially if we build a standalone media widget that can complement it in terms of findability.

#21 in reply to: ↑ 16 @azaozz
11 months ago

Replying to westonruter:

My interest in adding TinyMCE to the Text widget in JS Widgets plugin is as a demonstration/prototype for how JS components can be integrated with a newly proposed JS-based widget foundation. The JS Widgets plugin is not anywhere close to merging so the TinyMCE Text widget would just be living there as a proof of concept that could in the future be incorporated into core after the proper feature plugin/project merge process. In other words, no core patch is in view here for the immediate future.

Sure, we should do that. Think the proper way would be to have "lighter" editor UI that is non-WYSIWYG as there will be a preview on the same screen (i.e. white background, standard text size, no theme specific CSS, etc.).

However for the core text widget we should do a "full blown" editor instance that has the same features as the "main editor" on the Edit Post screen, perhaps without most WYSIWYG enhancements as a full preview will be right there.

I agree widgets need architectural improvements before we start focusing on creating new widgets significantly. Storing widgets as a custom post type is proposed in #35669 (with feature plugin), however I don't think it's necessarily a dependency.

Right, not a dependency, but would be nice to get done together. Expanding the text widget to support HTML and most (or all?) features of the post editor (embeds, galleries, images with captions, etc.) will make it a lot more popular. At the same time it will need more space to save its content. Would be good to remove the limitations of saving widgets data as options.

Also #33507/#35574 improve widgets architecture to allow them work with JavaScript first-and-foremost, and the JS Widgets plugin is an implementation of these tickets. Adding JS components to widgets is currently very painful in core. So that's why I was thinking implementing a visual/rich Text widget there would make sense to prototype.

#33507 and #35574 sound good but perhaps they go in another direction and/or don't go far enough. We are planning to change the way widget data is stored completely, and to import the old widget data. When we do that many things will be improved significantly, including the enhancements from these two tickets.

Inline/frontend editing of customizable elements (partials) doesn't yet have a ticket, AFAIK. But I think there are some good opportunities for allowing a widget control to appear floating next to a given rendered widget or also for the title and content (of the Text widget) to be edited inline with direct manipulation.

Yeah, it can work with a "floating" editor dialog (in something like a modal), or from an editor area on the left side of the screen while the actual widget is on the right side. However from UI/UX point of view inline editing means that the actual spot on the site is being edited, and is by far the easiest to understand. (Widgets are brand new concept for most users, and it's quite hard for many to grasp it.)

I'm wondering if we should try to make the new Text widget editable inline. Seems that won't be that hard if it is all AJAX/REST API. We can insert the widget as usual. Then instead of showing a "settings form", we can create an inline editor instance and make the newly inserted widget editable right where it is in the theme. That's the best WYSIWYG/preview there is :)

If not possible (yet), we should probably add a "full-blown" editor instance but without WYSIWYG enhancements (see above). One thing we can try in this case would be to make the editing form as wide as the actual widget.

#22 in reply to: ↑ 17 ; follow-up: @azaozz
11 months ago

Replying to melchoyce:

There might still be merit to a standalone media widget, but I would be totally satisfied with having an "add media" button in the text widget.

Yeah, exactly. Thinking we should add "full featured" editor there, same as on the Edit Post screen. It will support galleries, images with captions, embeds, even shortcodes. This will make the "Text widget" a true "side content" capable.

Then the users will be able to decide if they want just an image, a video, an audio, bunch of links, styled text or all of the above in it.

Last edited 11 months ago by azaozz (previous) (diff)

#23 in reply to: ↑ 22 ; follow-up: @melchoyce
11 months ago

Replying to azaozz:

Replying to melchoyce:

There might still be merit to a standalone media widget, but I would be totally satisfied with having an "add media" button in the text widget.

Yeah, exactly. Thinking we should add "full featured" editor there, same as on the Edit Post screen. It will support galleries, images with captions, embeds, even shortcodes. This will make the "Text widget" a true "side content" capable.

Then the users will be able to decide if they want just an image, a video, an audio, bunch of links, styled text or all of the above in it.

"Full featured" as in "exactly mimics the editor," or "full featured" as in supports views and has some formatting available? I don't think the text widget needs to be any more complex than what I mocked up in terms of interface — for example, I don't think it needs the kitchen sink. B/I/Lists/Links seems like an adequate first step towards making the text widget a better, more modern experience.

#24 follow-up: @westonruter
11 months ago

  • Keywords needs-patch added
  • Milestone changed from Future Release to 4.8

@azaozz also I understand that without #35760 it isn't currently feasible to make the full featured WP TinyMCE editor available in the Text widget since it currently requires wp_editor() to be called in PHP for each instance and new editors can't be dynamically built for new instances of Text widgets that are added. Is that accurate? If the Editor was not the full editor but rather a vanilla TinyMCE editor, then it seems it would be more feasible to dynamically instantiate new ones in JS however.

Nevertheless, one key feature of the Text widget visual editor would be the WP Links interface which isn't part of vanilla TinyMCE.

Do you or @iseulde have recommendations on the JS code required to dynamically create new basic editors as mocked by @melchoyce?

#25 follow-up: @westonruter
11 months ago

One more question regarding the Text widget: what should be done about the “Automatically add paragraphs” checkbox (the filter property)? It means whether wpautop is applied. But if it is a TinyMCE editor then really this means that shortcodes would need to be allowed and so really it needs to apply the_content filters which will include wpautop but also wptexturize and also do_shortcode among others. See previously reported in #10457 (Parse shortcodes in text widgets by default)… which is 7 years old! But applying these other filters will likely have back-compat implications. Also, applying the_content filters may not work as expected always because the filters running will amy expect a $post global to be set which corresponds to the content being filtered.

In any case, I think it only makes sense to show the filter checkbox when the non-visual editor is shown. We could employ a back-compat solution whereby we introduce a new tinymce property for the Text widget which gets set to true when the Visual editor is shown. If the property is false (or absent) then the HTML tab should be displayed instead, along with the filter checkbox displayed. Once you select the Visual tab, however, then filter would be implied to be true and the checkbox would be hidden. This will ensure that the Visual editor is opt-in when upgrading WP.

#26 in reply to: ↑ 23 @azaozz
11 months ago

Replying to melchoyce:

"Full featured" as in "exactly mimics the editor," or "full featured" as in supports views and has some formatting available?

Uh, sorry, should have explained better :)
As in support embeds/views, formatting, etc. but not "exactly mimics". I meant this for the "back-end" of the implementation (load all TinyMCE plugins, process shortcodes, etc.), not for the UI.

I don't think the text widget needs to be any more complex than what I mocked up in terms of interface — for example, I don't think it needs the kitchen sink. B/I/Lists/Links seems like an adequate first step towards making the text widget a better, more modern experience.

Yep, the mockup looks great. Don't think it needs more buttons. Can also add all the keyboard shortcuts as in the "main" editor.

#27 in reply to: ↑ 24 @azaozz
11 months ago

Replying to westonruter:

@azaozz also I understand that without #35760 it isn't currently feasible to make the full featured WP TinyMCE editor available in the Text widget since it currently requires wp_editor() to be called in PHP for each instance...

Not quite. wp_editor() was made so plugins can add an editor exactly the same as the "main" editor, with the same features, plugins and UI. Once TinyMCE is loaded on a page, we can initialize (from JS) as many instances of it as we need.

This is currently not supported as separate option in wp_editor() as that function also outputs the HTML around both editors. If that HTML is generated in another way, we can initialize an unlimited amount of other instances (as long as the browser has enough memory/CPU power), either with the same configuration or different.

Nevertheless, one key feature of the Text widget visual editor would be the WP Links interface which isn't part of vanilla TinyMCE.

Yes, one of the harder things would be to add the (old) wplink dialog as it is external to TinyMCE. The new inline link would work properly as it is essentially a TinyMCE plugin.

Do you or @iseulde have recommendations on the JS code required to dynamically create new basic editors as mocked by @melchoyce?

Until #35760 is done, the best way would be to load wp-tinymce.php or tinymce.js directly the same way as in class-wp-editor.php: https://core.trac.wordpress.org/browser/tags/4.7.1/src/wp-includes/class-wp-editor.php#L1245 including the translated strings. Then initialize it with a "mostly hard-coded" init settings. It will still need tinyMCEPreInit object with baseURL and suffix properties that come from PHP.

Most of the actual init options should be filterable only in JS. Think this is the better option as if we use all available PHP filters from class-wp-editor.php, the Text widget instance of the editor will end up affected by most WordPress plugins that are meant only for the main editor.

Once the init options object is created (and filtered), we can initialize as many editor instances as needed. Note that the editor, once initialized, cannot be moved in the DOM. This is a security limitations for iframes in all browsers. If moving is necessary, it has to be unloaded, then initialized again.

#28 in reply to: ↑ 25 ; follow-up: @azaozz
11 months ago

Replying to westonruter:

what should be done about the "Automatically add paragraphs" checkbox...

Think this should go. Don't think we should expose a "disable wpautop" setting there regardless if wpautop is used or not. Generally I think it would be better to not use autop (keeps things faster and simpler). On the other hand we have a Text editor tab that will look different, so.... Not sure :)

In any case, I think it only makes sense to show the filter checkbox when the non-visual editor is shown. We could employ a back-compat solution whereby we introduce a new tinymce property for the Text widget which gets set to true when the Visual editor is shown. If the property is false (or absent) then the HTML tab should be displayed instead, along with the filter checkbox displayed. Once you select the Visual tab, however, then filter would be implied to be true and the checkbox would be hidden. This will ensure that the Visual editor is opt-in when upgrading WP.

Think we can assume autop is needed for the Text editor. Also, nearly all "full HTML" can run through wpautop without functional change. I mean, even if autop is not needed and all <p> tags are in place, we can still run it through wpautop without breaking anything. This would be enough for back-compat imho.

#29 in reply to: ↑ 28 @melchoyce
11 months ago

Replying to azaozz:

Replying to melchoyce:

"Full featured" as in "exactly mimics the editor," or "full featured" as in supports views and has some formatting available?

Uh, sorry, should have explained better :)
As in support embeds/views, formatting, etc. but not "exactly mimics". I meant this for the "back-end" of the implementation (load all TinyMCE plugins, process shortcodes, etc.), not for the UI.

Cool 👍

Replying to azaozz:

Replying to westonruter:

what should be done about the "Automatically add paragraphs" checkbox...

Think this should go. Don't think we should expose a "disable wpautop" setting there regardless if wpautop is used or not. Generally I think it would be better to not use autop (keeps things faster and simpler). On the other hand we have a Text editor tab that will look different, so.... Not sure :)

I think we should probably mimic the editor. The "add paragraphs" checkbox never made any sense to me other than "people don't have a way to add paragraphs without manually coding p tags so I guess we need to add an option to add them for people instead."

In any case, I think it only makes sense to show the filter checkbox when the non-visual editor is shown.

Could this be a good compromise to handle back-compat?

#30 @superbotics
10 months ago

  • Focuses ui accessibility administration template added
  • Keywords 2nd-opinion added; needs-patch removed

Better way treat all widgets as post type
and all other stuff as post meta fields
Supporting Revisions, Template files and all good features of post types.

so that they will work out of the box supporting plugins like ACF for create widgets on the fly.

Current Widget UI can be used to build only the order and choose widgets for particular sidebars. This will help developer add awesome new features easily

#31 @westonruter
10 months ago

  • Keywords needs-patch added; 2nd-opinion removed

@superbotics what you're proposing is out of scope for the enhancement in this ticket for the Text widget. What you are describing may indeed be part of the work on editor blocks this year.

#32 @SergeyBiryukov
10 months ago

  • Focuses administration template removed

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


10 months ago

#34 @mattmedeiros
10 months ago

If this widget is going to operate in the customizer as well, you may want to take a peek at what we've done with https://wordpress.org/plugins/note

It also comes with column creation features. Just adding .02 here.

Last edited 10 months ago by mattmedeiros (previous) (diff)

#35 @celloexpressions
10 months ago

I'd suggest focusing on inline formatting (links, bold, italic, etc.) initially and leaving out media or other blocks. That could create issues with widgets being blocks in a block-based editor, but this particular widget block containing multiple types of content as blocks in a way that may not make sense down the road.

Another thought - perhaps the existing text widget should transition into an "HTML" or even just "Text" (like the editor tab) widget and content should be handled via other distinct blocks within widget areas, such as a media block/widget. That seems like a potentially better concept long-term within the block paradigm. Otherwise, nesting blocks could feel very odd and unintentional here, with a text widget that largely acts as its own block container/sidebar/content area.

#36 @azaozz
9 months ago

I'd suggest focusing on inline formatting (links, bold, italic, etc.) initially and leaving out media

I was with the impression that we want a "universal" widget that will support the same content as the post editor. I really like the mockup which has the "Add Media" button suggesting you will be able to add images, videos, embeds, galleries, etc.


I don't see any disadvantages for having an "universal" widget. The advantages are:

  • The users will be familiar with how to use it from the start as the workflow will be identical to editing a post.
  • We will avoid adding 5-6 different widgets for different content and with different controls, restrictions and workflows.

If we go with a cut-down, inline tags only widget the disadvantages will be:

  • It will be very inferior to what's available in plugins. Not really sure why we would want to add that to core given the opportunity for something much better.
  • We will (eventually) have to add many different widgets for the different content: video, audio, galleries, embeds, etc.
  • As it would support HTML, some users will eventually learn to paste the media types we excluded. For example it will be very easy to compose the content in the post editor then copy and paste the HTML. Forcing the users to do that by not providing sufficient UI would be a failure imho.

Also, regardless of whether we add media support or not, adding HTML support to the text widget makes the "Media Widget" #32417 completely redundant. I mean, there will be two widgets that will do exactly the same thing but have different UI (either the Media Library, copy/paste HTML, or yet another new UI in the media widget). That's not going to be good UX.

Last edited 9 months ago by azaozz (previous) (diff)

#37 @celloexpressions
9 months ago

My understanding of widgets is that they're intended to be distinct blocks of (often dynamic) content. They're the type of thing that a post or a sidebar/widget area may be made up of. A "universal" widget would behave similarly to an entire area, confusing the block concept by requiring some things to be nested blocks within a block that's essentially nested within an area of the same block unnecessarily, and where you can't continue nesting and organizing any type of block.

With a new block based editor, I would expect widget areas to behave the same way that content areas do - as an area where you can add text or other types of blocks. Introducing a distinct widget block that has this functionality, particularly in the form of an editor interface that we're moving away from, doesn't make sense.

#38 follow-up: @joyously
8 months ago

As it would support HTML, some users will eventually learn to paste the media types we excluded. For example it will be very easy to compose the content in the post editor then copy and paste the HTML. Forcing the users to do that by not providing sufficient UI would be a failure imho.

This is already standard practice, and advice seen in many support forums. I think large amounts of content belong in posts/pages and users should be guided to "do the right thing" by ease of use. Widgets can move around on theme switch or by the user moving them, but also by viewing the page on different sized windows. As @celloexpressions says

My understanding of widgets is that they're intended to be distinct blocks of (often dynamic) content.

Keeping the editor simple encourages the user to keep the widget content simple.
And I don't understand why it's so difficult to add a call to filter the widget with do_shortcode in core since shortcodes are a core thing. I'm not saying the output of a shortcode should be visible in your new Visual mode, just that shortcodes should work in text widgets because they work in content.

#39 in reply to: ↑ 38 @westonruter
8 months ago

Replying to joyously:

And I don't understand why it's so difficult to add a call to filter the widget with do_shortcode in core since shortcodes are a core thing. I'm not saying the output of a shortcode should be visible in your new Visual mode, just that shortcodes should work in text widgets because they work in content.

The main challenge I see with shortcodes in the text widget is that certain shortcodes presume that they are being rendered in the context of the_content for a given post. Since a widget instance is not a post (yet, but #35669) these shortcodes could behave unexpectedly, such as if they are trying to obtain all of the attachments for the current post (as gallery does) or aggregating postmeta for display. There would need to be restrictions on which shortcodes would be allowed, or at least shortcodes would need to be educated on this new context.

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


8 months ago

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


8 months ago

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


8 months ago

#44 follow-up: @azaozz
8 months ago

Related: #39993, #39994, #39995.

After the patch on #35760 we should be able to make this enhancement relatively easily. As there are separate media widgets, the Text widget would be "pure" HTML.

We should add the TinyMCE buttons and the corresponding Quicktags buttons for the Text tab, then disable the wpview plugin as oEmbeds won't be supported (they require a post_ID to work). Also think the wpautoresize plugin and the TinyMCE media plugin won't be needed here.

#45 in reply to: ↑ 44 ; follow-up: @westonruter
8 months ago

Replying to azaozz:

As there are separate media widgets, the Text widget would be "pure" HTML.

So you don't think that the existing Text widget should be upgraded to support a Visual mode? You think there should rather be an entirely new widget type introduced? That would certainly make things easier for back-compat and migration, since there wouldn't be any such work to do.

#46 in reply to: ↑ 45 @azaozz
8 months ago

Replying to westonruter:

So you don't think that the existing Text widget should be upgraded to support a Visual mode?

Uh, sorry, that's not what I meant :) The Visual and Text editors, formatted text, lists, links, etc. as opposite to having images, galleries, videos, etc. (same as Mel's https://core.trac.wordpress.org/attachment/ticket/35243/text-widget.png).

On the other hand, as you mention it is probably worth exploring adding a new widget and even deprecating the current widget (hiding it in the UI) if it is not used.

I don't think back-compat will be particularly hard, but it is true that many users have pasted many different "things" in the Text widget over the years and chances are we may break something.

The only back-compat decision for the default Text widget would be about the autop chechbox. I think we should remove it completely. Then if $instance['filter'] is set, can run the content through wpautop on loading and displaying, but save the <p> tags and remove $instancefilter?` when editing. This would make it better and simpler.

Version 1, edited 8 months ago by azaozz (previous) (next) (diff)

#47 @westonruter
7 months ago

Here's a (working) work in progress in the core media widgets plugin repo: https://github.com/xwp/wp-core-media-widgets/pull/97

#48 @gk.loveweb
7 months ago

Few months ago, I have created WP plugin to enhance Text Widget functionality. https://wordpress.org/plugins/visual-text-editor/ It unregister Text Widget and register a new widget using same widget id as Text Widget.

https://github.com/emgk/visual-text-editor/blob/master/includes/class-visual-editor.php#L97-L100
https://github.com/emgk/visual-text-editor/blob/master/includes/class-widget.php#L23-L26

#49 @westonruter
7 months ago

  • Keywords needs-testing added

Visual text widget is further refined and ready for testing by checking out this pull request: https://github.com/xwp/wp-core-media-widgets/pull/97

A few notes:

  • A new widget_text_content filter is introduced which applies on the text instance property with wptexturize, wpautop, convert_smilies, and capital_P_dangit… the filters for the_content which do not depend on there being a global post. Note that embeds and shortcodes are not processed.
  • The filter property is removed from the widget instance when it is updated. The new widget_text_content filter applies after widget_text and it will only apply if the filter property is not set, so that the new filters will only apply once a user has touched a widget with the new TinyMCE editor active.
  • The feature plugin subclasses WP_Widget_Text whereas the core patch would actually modify the class itself.
  • In the customizer, changes to the visual editor get synced to the changeset and previewed after 1 second to reduce the amount of refreshes as changes are made (see also #38954).
  • TinyMCE is initialized when a widget control is expanded. Note there is currently a 100ms delay in initialization since wp.editor.initialize() seems to not enable contenteditable in the editor iframe when the textarea is not fully visible (such as while/before slideDown).
  • Every time you hit the Save button on the widget in the widgets admin screen, a flicker is currently noticeable as the TinyMCE editor has to be re-initialized. Ideally we could avoid this.

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


7 months ago

#51 @westonruter
7 months ago

Visual (TinyMCE) text widget is now available in the Media Widgets plugin, if you are on trunk. Tomorrow we plan to create a core patch. Please test feature plugin: https://wordpress.org/plugins/wp-core-media-widgets/

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 months ago

#53 @afercia
7 months ago

  • Owner set to westonruter
  • Status changed from new to assigned

Assigning to @westonruter, as all tickets milestoned for 4.8 should have an owner at this point.

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


7 months ago

#55 @westonruter
7 months ago

  • Keywords has-patch added; needs-patch removed

Core patch split out from plugin is ready. Please test. I want to commit it to trunk by EOD Wednesday PDT.

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


7 months ago

#57 @azaozz
7 months ago

  • Keywords commit added; needs-testing removed

Looks good and works well :)

@obenland
7 months ago

Add PHP unit tests

#58 @westonruter
7 months ago

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

In 40631:

Widgets: Extend the Text widget with TinyMCE.

Introduces rich text formatting: bold, italic, lists, links.

Props westonruter, azaozz, timmydcrawford, obenland, melchoyce.
See #35760.
Fixes #35243.

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


7 months ago

#60 @jbpaul17
7 months ago

  • Keywords needs-dev-note added

#61 @westonruter
6 months ago

In 40673:

Widgets: Ensure return value of widget_text filter is not dropped but passed into widget_text_content filter for rendering.

Amends [40631].
Props vijustin, swissspidy, westonruter.
See #35243.
Fixes #40772.

#62 @westonruter
6 months ago

In 40675:

Widgets: Add missing wp-editor-area CSS class for textarea in the TinyMCE-extended Text widget to ensure proper styles are applied.

Removes extra border around TinyMCE-wrapped textarea and removes gap at bottom due to lack of display:block.

Props johnjamesjacoby, westonruter.
See #35243.
Fixes #40755.

#63 @BackuPs
6 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Hi All

How do i extend the textwidget tinymce available formatting buttons with my own? How can i add a extra icon?

http://i.imgur.com/NAHciGW.png

Can anybody shine a light on that?

Thank you !

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


6 months ago

#65 @westonruter
6 months ago

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

@BackuPs no need to re-open the ticket.

This will be documented in a forthcoming dev-note, but here is a snippet for adding a button:

jQuery( document ).on( 'tinymce-editor-setup', function( event, editor ) {
        editor.settings.toolbar1 += ',mybutton';
        editor.addButton( 'mybutton', {
                text: 'My button',
                icon: false,
                onclick: function () {
                        editor.insertContent('&nbsp;<b>It\'s my button!</b>&nbsp;');
                }
        });
});

This is an adaptation of https://www.tinymce.com/docs/demo/custom-toolbar-button/

Thanks to @azaozz for working out this example with me over Slack.

#67 @paaljoachim
6 months ago

This is so very late and I should have posted this months ago... I apologize for not doing so.

I miss not being able to select alignment and paragraph/headings.

Sometimes one just needs to add some text with a link with some header text and paragraph text and perhaps even align the header in the center and the rest as default left. I feel that the updated widget has been too limited.

Something like this:

Header text (h2) (alignment center)

Text (paragraph default alignment left. A link or two.)

Wireframe:
[[Image(https://www.dropbox.com/s/zpi9a6464l8blgh/An-adjustment-Visual-text-widget.jpg?dl=0)]https://www.dropbox.com/s/zpi9a6464l8blgh/An-adjustment-Visual-text-widget.jpg?dl=0]

I am not sure if it the image will show up. My thoughts are on then adding alignment and the heading/paragraph drop down to make the widget even more useful. Thanks.

#68 @westonruter
6 months ago

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.

#69 follow-up: @theMikeD
5 months ago

  • Keywords 2nd-opinion ux-feedback added
  • Severity changed from normal to major

The decision to update the text widget rather than create a new rich text widget was a very poorly thought through one. In one step you have destroyed the custom code in countless widgets using the existing text widget, and rendered invalid every tutorial on adding custom code into a widget.

Other related bugs are filling up with issues around code being removed by this new feature.

This need to be reverted in 4.8.1 and re-introduced as a Rich Text widget. IMHO this is an urgent issue that needs to be resolved asap.

#70 in reply to: ↑ 69 @BackuPs
5 months ago

Replying to theMikeD:

The decision to update the text widget rather than create a new rich text widget was a very poorly thought through one. In one step you have destroyed the custom code in countless widgets using the existing text widget, and rendered invalid every tutorial on adding custom code into a widget.

Other related bugs are filling up with issues around code being removed by this new feature.

This need to be reverted in 4.8.1 and re-introduced as a Rich Text widget. IMHO this is an urgent issue that needs to be resolved asap.

I could not agree more... but this will be like talking to a deaf person if you ask me as i dont expect the wp core team to acknowledge or change this.

#71 @westonruter
5 months ago

  • Keywords 2nd-opinion ux-feedback removed
  • Severity changed from major to normal

This issue was closed on a completed milestone. Comments should be directed to #40951.

@BackuPs We are definitely evaluating options and will have a proposal today. Please keep comments constructive.

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


5 months ago

#73 @westonruter
5 months ago

In 40941:

Widgets: Add accessibility mode support for TinyMCE-enhanced Text and Media widgets (Video, Audio, Images).

Amends [40640], [40631].
Props westonruter, afercia.
See #35243, #32417.
Fixes #40986.

#74 @westonruter
5 months ago

In 41028:

Widgets: Enqueue assets needed by media and text widgets in their _register_one() methods.

The WP_Widget::_register_one() method is more guaranteed to be called as opposed to its wrapper WP_Widget::_register() which plugins may bypass for performance reasons.

Amends [40631], [40640].
See #35243, #32417.
Fixes #41021.

#75 @westonruter
4 months ago

In 41050:

Widgets: Add legacy mode for Text widget and add usage pointers to default visual mode.

The Text widget in legacy mode omits TinyMCE and retains old behavior for matching pre-existing Text widgets. Usage pointers added to default visual mode appear when attempting to paste HTML code into the Visual tab and when clicking on the Text tab, informing users of the new Custom HTML widget.

Props westonruter, melchoyce, gitlost for testing, obenland for testing, dougal for testing, afercia for testing.
See #35243.
Fixes #40951.

#76 @westonruter
4 months ago

In 41051:

Widgets: Add accessibility mode support for TinyMCE-enhanced Text and Media widgets (Video, Audio, Images).

Merges [40941] to 4.8 branch.
Amends [40640], [40631].
Props westonruter, afercia.
See #35243, #32417.
Fixes #40986 for 4.8.1.

#77 @westonruter
4 months ago

In 41052:

Widgets: Enqueue assets needed by media and text widgets in their _register_one() methods.

The WP_Widget::_register_one() method is more guaranteed to be called as opposed to its wrapper WP_Widget::_register() which plugins may bypass for performance reasons.

Merges [41028] to the 4.8 branch.
Amends [40631], [40640].
See #35243, #32417.
Fixes #41021 for 4.8.1.

#78 @westonruter
4 months ago

In 41053:

Widgets: Add legacy mode for Text widget and add usage pointers to default visual mode.

The Text widget in legacy mode omits TinyMCE and retains old behavior for matching pre-existing Text widgets. Usage pointers added to default visual mode appear when attempting to paste HTML code into the Visual tab and when clicking on the Text tab, informing users of the new Custom HTML widget.

Merges [41050] to 4.8 branch.
Props westonruter, melchoyce, gitlost for testing, obenland for testing, dougal for testing, afercia for testing.
See #35243.
Fixes #40951 for 4.8.1.

#79 @westonruter
4 months ago

In 41088:

Widgets: Check for existence of wp.customize.state before attempting to access in Text widget.

Amends [40631].
See #35243.
Fixes #41361 for trunk.

#80 @westonruter
4 months ago

In 41089:

Widgets: Check for existence of wp.customize.state before attempting to access in Text widget.

Merges [41088] onto 4.8 branch.
Amends [40631].
See #35243.
Fixes #41361 for 4.8.1.

#81 @westonruter
4 months ago

In 41094:

Widgets: Improve Text widget's reliability in syncing Visual tab's contents with Text tab and with hidden sync inputs.

Amends [40631].
Props azaozz, westonruter, rinkuyadav999 for testing.
See #35243.
Fixes #40974 for trunk.

#82 @westonruter
4 months ago

In 41095:

Widgets: Improve Text widget's reliability in syncing Visual tab's contents with Text tab and with hidden sync inputs.

Merges [41094] onto 4.8 branch.
Amends [40631].
Props azaozz, westonruter, rinkuyadav999 for testing.
See #35243.
Fixes #40974 for 4.8.1.

#83 @westonruter
4 months ago

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.

#84 @westonruter
4 months ago

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.

#85 @westonruter
4 months ago

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.

#86 @westonruter
4 months ago

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.

#87 @westonruter
4 months ago

In 41136:

Customize: Update Text widget starter content to utilize visual mode.

Amends [38991].
Props dlh, westonruter.
See #35243, #38114.
Fixes #41410.

#88 @westonruter
4 months ago

In 41137:

Customize: Update Text widget starter content to utilize visual mode.

Merges [41136] onto 4.8 branch.
Amends [38991].
Props dlh, westonruter.
See #35243, #38114.
Fixes #41410 for 4.8.1.

#89 @westonruter
3 months ago

In 41245:

Widgets: Fix extensibility of Text widgets so that JS logic will initialize on subclassed widgets.

Amends [40631].
See #35243.
Fixes #41540.

#90 @westonruter
3 months ago

In 41260:

Widgets: Prevent visual Text widget from decoding encoded HTML.

Also apply the_editor_content filters on widget text with format_for_editor() as is done for the post editor.

Amends [40631].
Props westonruter, azaozz.
See #35243.
Fixes #41596.

#91 @ocean90
2 months ago

In 41392:

Widgets: Prevent visual Text widget from decoding encoded HTML.

Also apply the_editor_content filters on widget text with format_for_editor() as is done for the post editor.

Merge of [41260] to the 4.8 branch.

Amends [40631].
Props westonruter, azaozz.
See #35243.
Fixes #41596.

Note: See TracTickets for help on using tickets.