[wp-trac] [WordPress Trac] #35243: Extending the text widget to also allow visual mode

[WordPress Trac]

#35243: Extending the text widget to also allow visual mode
-------------------------+-----------------------------
 Reporter:  paaljoachim  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Widgets      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+-----------------------------

Comment (by azaozz):

 Replying to [comment:16 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 [https://github.com/xwp/wp-js-
 widgets 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.

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