Allow Filtering of Editor Modes

[0aveRyan]

Description

Allow filtering of Editor Modes to let Plugins register custom editors
Example uses:

• Block Outline
• Device Previews
• Geolocation Editor
• Syndication Editor
• SEO Report

• Known issues surrounding keyboard shortcut language/display in UI.

Screenshots

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[0aveRyan]

I'm happy to update the keyboard shortcut language, tests, etc once there's feedback on this.

[gziolo]

That’s an interesting idea. It probably would make sense also to automate rendering of the selected mode in here:
https://github.com/WordPress/gutenberg/blob/master/edit-post/components/layout/index.js#L91

@mtias, how does it fit in the roadmap for extensibility?

[0aveRyan]

@gziolo @mtias worth noting discussion on #9334 about potential for an official Focus Mode, and a Revisions Mode integrating the diff viewer could be powerful.

This is one of a few high-level things I think could benefit from explicit action/filters. The new Editor View and Blocks are fantastic, but there are still situations entirely new views would be beneficial instead of registering a new sidebar box for every block.

I see three unique/potential needs for views to be enabled by plugins:

Document-Level Settings

• Position a Background Image inside a faux widescreen TV for a digital signage plugin (taking full advantage of device screen real estate)
• A Title's Editor for News Publishers, who often have post_title, medium_title, short_title, fb_title and twitter_title to view these titles side-by-side.
• A Dateline View where you can set important geolocation(s) using a fullscreen map, write a Dateline and have autosuggested location taxonomy terms.

Per-Block Metadata

• Legal Approval (should have view-only access to content, but have unique approval/comment metabox)
• Editorial Notes (would want to enable highlights/comments not visible in other views, and would be greatly enhanced if it didn't need to be a default box on every block and had unique view)

Reduced Views

• Media/Image view where Media Editors can view adjacent blocks but only have edit access and media tools.
• Syndicated Content View (way to make most blocks and attributes read-only, but allow site-specific image captions, post title's, etc)
• Ad insertion

[scarstens]

This would be a critical feature for before Meredith Corp would be able to start customizing and integrating Gutenberg into its WordPress CMS. There are actually several places where extensibility of the current experience is impossible, and its blocking our ability to get sign off on using Gutenberg at all.

[0aveRyan]

@mtias any thoughts on this..? the need for filterability here persists IMO, despite some really great changes to how modes/options have improved recently

[mcsf]

In terms of suggested features, this is quite compelling! Thanks for all the notes. I'd like to see plugins offer these to users, and I think this is generally achievable.

However, architecturally, I'm not sure they fit with the Editor / Code modal binary; ultimately, I don't think we'd be offering a sane API for developers, nor something conducive to good experiences for users.

There are other ways to go about it. For instance:

• Register a plugin using the registerPlugin API, thereby adding a toggle for the plugin. When toggled, global state changes can alter which blocks remain visible (e.g. internal editoral notes), how certain blocks should be rendered (e.g. decorate block with SEO reports), etc.
• Register a plugin using the registerPlugin API, thereby adding a toggle for the plugin. When toggled, a plugin sidebar reveals all the controls necessary to a certain task or workflow (e.g. document-wide properties, outline of specific block types). See example plugin: Drop It.
• Register a plugin using the registerPlugin API, thereby adding a toggle for the plugin. When toggled, new UI elements in the editor chrome can provide dedicated views, e.g. the Content Structure popover (also known as Document Outline).
• Write an altogether new editing mode for maximum control of the user experience. It's a more challenging option that can be the right one for ambitious or intentionally immersive plugins. This separate mode would sit alongside @wordpress/edit-post, currently the sole provider of a Gutenberg editor. Most likely, this view would have its own URL or at least hinge on specific load-time GET params (e.g. the classic editor can be revealed via wp-admin/post.php?classic-editor).

[mcsf]

As this is already labeled Future and @mtias and I are working on prioritizing work for 5.0, I'm going to close the issue.

Write an altogether new editing mode for maximum control of the user experience.

Depending on its course, development for 5.1 may provide some inspiration on how to tackle this approach and lead to consolidation of patterns in @wordpress/edit-post that might ultimately make the task easier for third-party developers. I suggest following that closely.

Finally, I'll reiterate that, despite the Future label, any work on features such as those listed in this issue can be started today.

[0aveRyan]

@mcsf thanks for responding to this. I totally understand the priority is 5.0 work and I'm not suggesting this takes priority.

That said, there are plenty of places WordPress doesn't provide a sane API but provides filter for extensibility and customization. Perhaps I'm missing nuances for how this could be detrimental, but there shouldn't be harm in leaving the door open for others to extend the editor in ways outside the official roadmap.

[chrisvanpatten]

@0aveRyan I think one of the challenges is that client side filters have a much bigger impact on reliability… there are just many more ways a JS filter can break the experience that are harder for end-users to debug and recover from.

I think tackling this within the context of the Plugins API as opposed to a filter makes a lot of sense, as plugins can be isolated in such a way that a broken JS plugin doesn't bring down the whole user experience with it.

[mcsf]

Thanks for the balanced arguments in this thread. :)

Perhaps I'm missing nuances for how this could be detrimental

@0aveRyan: I'll echo @chrisvanpatten's arguments, and also add that there's generally been an attempt to avoid opening new patterns for extension when we don't know much about their possible uses. This is in good mesure based on our collective learnings from WP's history, in which have occasionally:

• found ourselves having to support well into the future some interface that we weren't sure about to begin with and have since realized that it's blocking other development;
• seen that incomplete interfaces can lead to third-party developers working with private entities and ending up in a fragile situation (e.g. many plugins relying on DOM read and writes to get application state in meta-boxes).

I think tackling this within the context of the Plugins API as opposed to a filter makes a lot of sense, as plugins can be isolated in such a way that a broken JS plugin doesn't bring down the whole user experience with it.

💯. My hope is also that certain patterns may emerge across plugins in such a way that helper plugins (or NPM modules) arise to ease some processes or designs. Then over time we can make informed decisions as to what we can bring back into the core framework.

[0aveRyan]

Alright, all fair points. I had been seeing relatively equal danger between PHP & JS filters, but yeah undetectable client-side errors definitely are fair reason to want to avoid something this significant.

The combination of your first & last suggestion @mcsf would be enough to accomplish a quasi-mode without truly creating a new mode -- creating a different render view when plugin state is toggled combined with listening for a query param would be enough to deep-link into a wp.plugin already active, hide all default blocks, render a custom block (likely using meta storage) and use some align-wide classes to accomplish a larger, more edge-to-edge UI.

I hadn't seen wp.plugins modify render for the content area -- examples mostly center on the sidebar, so I guess I have a fun weekend project now.

[chrisvanpatten]

I hadn't seen wp.plugins modify render for the content area -- examples mostly center on the sidebar, so I guess I have a fun weekend project now.

To this point, I'm truthfully not sure if it's possible to do a "takeover" like this (I've never tried), but if it isn't possible that feels like a good first extension point.

[0aveRyan]

@chrisvanpatten Yeah, haven't tried yet, but two things I'm going to test soon 1) Render new View/Edit for all content blocks based on wp.plugin active state and 2) On wp.plugin active toggle, hide all content blocks, unhide/render a custom block where all props source via meta and then on plugin deactivation re-hide custom/reveal content blocks.

[mcsf]

You may be heading in a slightly different direction than I'd have picked, but that's not necessarily bad 😄. If you end up with interesting finds, feel free to loop me in.