New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce 'block-editor' post type supports attribute for custom post types with custom controllers #2457

Open
mathetos opened this Issue Aug 18, 2017 · 31 comments

Comments

@mathetos

mathetos commented Aug 18, 2017

Issue Overview

This issue is primarily a Core issue for consideration when Gutenberg gets incorporated into WordPress Core.

Custom Post Types should have to declare Gutenberg Support. Currently the "Gutenberg" link is added by default to all post types. Clicking on that link with a custom post type currently takes the user to an error page saying: "No route was found matching the URL and request method" -- a pretty terrible user experience.

Expected Behavior

The "Gutenberg" link should only appear on post types that have declared support for Gutenberg. If that is not there, then the post type edit screen will be loaded with the now current traditional edit screen.

Possible Solution

Add a new "supports" option when post types are registered, like so:

$args = array(
		'supports' => array( 'gutenberg', 'author', 'thumbnail', 'excerpt', 'comments' )
	);

The default for "supports" should NOT include 'gutenberg' so that it has to be intentionally declared since most post types that exist today will fail as-is.

@steveangstrom

This comment has been minimized.

Show comment
Hide comment
@steveangstrom

steveangstrom Aug 19, 2017

I agree, but I suggest that a descriptive declaration such as "block-editor" is more applicable as "gutenberg" is a project name and stands out amid the other declarations.

steveangstrom commented Aug 19, 2017

I agree, but I suggest that a descriptive declaration such as "block-editor" is more applicable as "gutenberg" is a project name and stands out amid the other declarations.

@mathetos

This comment has been minimized.

Show comment
Hide comment
@mathetos

mathetos Aug 22, 2017

Good point @steveangstrom

Most likely we'll want to make sure "block-editor" overrides "editor" if both are declared accidentally as well.

mathetos commented Aug 22, 2017

Good point @steveangstrom

Most likely we'll want to make sure "block-editor" overrides "editor" if both are declared accidentally as well.

@BE-Webdesign

This comment has been minimized.

Show comment
Hide comment
@BE-Webdesign

BE-Webdesign Aug 24, 2017

Contributor

Custom Post Types should have to declare Gutenberg Support.

Pretty sure that is the intent of the block editor ( Gutenberg ), even though it might not be clear because the link is added. A lot of the WordPress end of things have yet to be ironed out/polished as the interactions within Gutenberg are the main focus of development for now. Polish, will be coming soonish!

Contributor

BE-Webdesign commented Aug 24, 2017

Custom Post Types should have to declare Gutenberg Support.

Pretty sure that is the intent of the block editor ( Gutenberg ), even though it might not be clear because the link is added. A lot of the WordPress end of things have yet to be ironed out/polished as the interactions within Gutenberg are the main focus of development for now. Polish, will be coming soonish!

@kevinwhoffman

This comment has been minimized.

Show comment
Hide comment
@kevinwhoffman

kevinwhoffman Aug 24, 2017

Contributor

@mathetos I do agree this would avoid some of the most complicated compatibility issues, but in the end I think it leads us toward a tale of two WP Admins.

We need to think through the side effects of declaring support for one type of editor or another. Gutenberg, as it exists today, is a full-screen replacement, which means toggling support for it affects not just the editor, but also what hooks are available and how meta boxes work. The internals and appearance of the entire sidebar change as well.

By not declaring support for Gutenberg, we preserve the interfaces that exist today, but at what cost? Here are some of the harmful side effects:

  • This path would lead us towards a fractured admin experience with no foreseeable point of convergence. Simple actions like adding a title, publishing a post, or managing revisions shouldn't change from one post type to the next based on whether a developer has declared Gutenberg support.
  • If the only way to ensure that existing interfaces continue to function is to avoid registering support for Gutenberg, then we prevent a significant portion of the audience from ever seeing Gutenberg on their existing sites.
  • This decision would also increase the burden on plugin developers who now have to ensure their meta boxes/blocks work both in "legacy" mode and within Gutenberg. The burden is not as heavy on plugins that define their own post types, but for plugins that add meta boxes to existing post types, they would now have to support a dual code base.

I've been mulling over a solution like this for a few months, but ultimately the scope creep of the editor out into the edit screen means that declaring support for one editor or another isn't as straightforward as it sounds. Instead it seems to replace a major problem with several smaller ones.

Contributor

kevinwhoffman commented Aug 24, 2017

@mathetos I do agree this would avoid some of the most complicated compatibility issues, but in the end I think it leads us toward a tale of two WP Admins.

We need to think through the side effects of declaring support for one type of editor or another. Gutenberg, as it exists today, is a full-screen replacement, which means toggling support for it affects not just the editor, but also what hooks are available and how meta boxes work. The internals and appearance of the entire sidebar change as well.

By not declaring support for Gutenberg, we preserve the interfaces that exist today, but at what cost? Here are some of the harmful side effects:

  • This path would lead us towards a fractured admin experience with no foreseeable point of convergence. Simple actions like adding a title, publishing a post, or managing revisions shouldn't change from one post type to the next based on whether a developer has declared Gutenberg support.
  • If the only way to ensure that existing interfaces continue to function is to avoid registering support for Gutenberg, then we prevent a significant portion of the audience from ever seeing Gutenberg on their existing sites.
  • This decision would also increase the burden on plugin developers who now have to ensure their meta boxes/blocks work both in "legacy" mode and within Gutenberg. The burden is not as heavy on plugins that define their own post types, but for plugins that add meta boxes to existing post types, they would now have to support a dual code base.

I've been mulling over a solution like this for a few months, but ultimately the scope creep of the editor out into the edit screen means that declaring support for one editor or another isn't as straightforward as it sounds. Instead it seems to replace a major problem with several smaller ones.

@mathetos

This comment has been minimized.

Show comment
Hide comment
@mathetos

mathetos Aug 24, 2017

This issue is made with the assumption that Gutenberg will be introduced into Core. This issue isn't creating a problem, its helping navigate a way forward in light of the current trajectory of the project.

Generally speaking, I only see a few options for what that might look like currently:

  1. Gutenberg changes drastically to not encroach throughout the edit screen -- which seems to be your preference @kevinwhoffman
  2. Gutenberg takes over all post type screens by default, then anyone building a CPT has to do all kinds of somersaults to work around it or with it -- not a fun idea.
  3. Have the authors of post types make an intentional decision to support Gutenberg for their post type or not. Making that intentional decision naturally means the CPT author will be ready to deal with the hooks available and how meta data works for their post type with Gutenberg.

The third option -- which I'm suggesting -- seems the most reasonable as well as backward compatible. That is of course unless something drastic changes between now and when Gutenberg is ready for Core integration, which might be the case; you never know.

mathetos commented Aug 24, 2017

This issue is made with the assumption that Gutenberg will be introduced into Core. This issue isn't creating a problem, its helping navigate a way forward in light of the current trajectory of the project.

Generally speaking, I only see a few options for what that might look like currently:

  1. Gutenberg changes drastically to not encroach throughout the edit screen -- which seems to be your preference @kevinwhoffman
  2. Gutenberg takes over all post type screens by default, then anyone building a CPT has to do all kinds of somersaults to work around it or with it -- not a fun idea.
  3. Have the authors of post types make an intentional decision to support Gutenberg for their post type or not. Making that intentional decision naturally means the CPT author will be ready to deal with the hooks available and how meta data works for their post type with Gutenberg.

The third option -- which I'm suggesting -- seems the most reasonable as well as backward compatible. That is of course unless something drastic changes between now and when Gutenberg is ready for Core integration, which might be the case; you never know.

@kevinwhoffman

This comment has been minimized.

Show comment
Hide comment
@kevinwhoffman

kevinwhoffman Aug 24, 2017

Contributor

I see two major challenges facing Gutenberg, the first based on the past and the second on the future:

  1. Don't break existing sites.
  2. Create a consistent admin experience moving forward.

Declaring Gutenberg support for a post type solves the first goal, but it creates two separate admin experiences going forward. This is what I mean by solving one problem by introducing another.

Have the authors of post types make an intentional decision to support Gutenberg for their post type or not. Making that intentional decision naturally means the CPT author will be ready to deal with the hooks available and how meta data works for their post type with Gutenberg.

This is great for the author of the post type, but any other developer attempting to extend the functionality of the post type does not have knowledge of the editor type and therefore would have to prepare their plugin for both legacy and Gutenberg scenarios. Many plugins don't define post types at all as their entire purpose is to extend any post type's functionality.

For example's sake, let's say I'm a modern developer and I convert my plugin's shortcode to a Gutenberg block like many other contributors are suggesting. But then I find out that most of my existing customers are using this legacy interface. Now any future development on my plugin has to include maintenance and updates for both new and old implementations with no plan for future convergence.

Imagine writing documentation for your plugin's shortcode-turned-block two completely different ways for Gutenberg and legacy users, and expecting the user to know which is which. Or having to ask users whether they are using the Gutenberg interface or the legacy interface in order to properly debug an issue. Or even worse, what if one user has multiple post types on their site, some of which use Gutenberg and others which use legacy mode? Now the same customer has to learn how to use your plugin two different ways by inserting a shortcode in one post type and a block in another.

Contributor

kevinwhoffman commented Aug 24, 2017

I see two major challenges facing Gutenberg, the first based on the past and the second on the future:

  1. Don't break existing sites.
  2. Create a consistent admin experience moving forward.

Declaring Gutenberg support for a post type solves the first goal, but it creates two separate admin experiences going forward. This is what I mean by solving one problem by introducing another.

Have the authors of post types make an intentional decision to support Gutenberg for their post type or not. Making that intentional decision naturally means the CPT author will be ready to deal with the hooks available and how meta data works for their post type with Gutenberg.

This is great for the author of the post type, but any other developer attempting to extend the functionality of the post type does not have knowledge of the editor type and therefore would have to prepare their plugin for both legacy and Gutenberg scenarios. Many plugins don't define post types at all as their entire purpose is to extend any post type's functionality.

For example's sake, let's say I'm a modern developer and I convert my plugin's shortcode to a Gutenberg block like many other contributors are suggesting. But then I find out that most of my existing customers are using this legacy interface. Now any future development on my plugin has to include maintenance and updates for both new and old implementations with no plan for future convergence.

Imagine writing documentation for your plugin's shortcode-turned-block two completely different ways for Gutenberg and legacy users, and expecting the user to know which is which. Or having to ask users whether they are using the Gutenberg interface or the legacy interface in order to properly debug an issue. Or even worse, what if one user has multiple post types on their site, some of which use Gutenberg and others which use legacy mode? Now the same customer has to learn how to use your plugin two different ways by inserting a shortcode in one post type and a block in another.

@mattiman2

This comment has been minimized.

Show comment
Hide comment
@mattiman2

mattiman2 Sep 7, 2017

@kevinwhoffman that's a good summary of the main challenges. The thing is though, that the problem of breaking existing sites is entirely created by the Gutenberg project itself wanting to move forward so quickly and having such a large scope (especially forcing meta boxes into "legacy", whatever that will mean). Creating a constant admin experience is important of course. But not breaking half of all existing Wordpress sites would seem more important at the moment.

mattiman2 commented Sep 7, 2017

@kevinwhoffman that's a good summary of the main challenges. The thing is though, that the problem of breaking existing sites is entirely created by the Gutenberg project itself wanting to move forward so quickly and having such a large scope (especially forcing meta boxes into "legacy", whatever that will mean). Creating a constant admin experience is important of course. But not breaking half of all existing Wordpress sites would seem more important at the moment.

@mtias

This comment has been minimized.

Show comment
Hide comment
@mtias

mtias Nov 20, 2017

Contributor

A block-editor might be a good property to declare. @pento any thoughts? Might be similar to some of the fallback meta-box handling.

Worth noting gutenberg already handles when a post type doesn't support editor.

Contributor

mtias commented Nov 20, 2017

A block-editor might be a good property to declare. @pento any thoughts? Might be similar to some of the fallback meta-box handling.

Worth noting gutenberg already handles when a post type doesn't support editor.

@pento

This comment has been minimized.

Show comment
Hide comment
@pento

pento Nov 22, 2017

Member

I'm not wild about the opt-in option for CPTs. I like the editor check, and I'd be cool with a block-editor CPT support flag that defaults to true, allowing CPTs to explicitly opt out of Gutenberg.

I'm also interested in ways we can detect whether a particular CPT is going to work in Gutenberg, similar to meta boxes.

I'd like to see some examples of CPT usage that declares editor support, but breaks in Gutenberg.

Member

pento commented Nov 22, 2017

I'm not wild about the opt-in option for CPTs. I like the editor check, and I'd be cool with a block-editor CPT support flag that defaults to true, allowing CPTs to explicitly opt out of Gutenberg.

I'm also interested in ways we can detect whether a particular CPT is going to work in Gutenberg, similar to meta boxes.

I'd like to see some examples of CPT usage that declares editor support, but breaks in Gutenberg.

@BE-Webdesign

This comment has been minimized.

Show comment
Hide comment
@BE-Webdesign

BE-Webdesign Nov 22, 2017

Contributor

I think if we can get more and more meta boxes to work, this problem sort of goes away. The main breakage I see is all meta box related. Originally I was more on the opt-in train of thought, but after seeing how things are playing out, I think opt-out would be ideal, if we can minimize the problems surrounding meta boxes.

Contributor

BE-Webdesign commented Nov 22, 2017

I think if we can get more and more meta boxes to work, this problem sort of goes away. The main breakage I see is all meta box related. Originally I was more on the opt-in train of thought, but after seeing how things are playing out, I think opt-out would be ideal, if we can minimize the problems surrounding meta boxes.

@SilentComics

This comment has been minimized.

Show comment
Hide comment
@SilentComics

SilentComics Dec 12, 2017

I too believe opt-out would be a better approach. CPTs should start at least with the same editing options than regular posts. You might want to opt out if the CPT is layout-specific though, but their aim is often only taxonomies.
In an ideal world CPTs should have Gutenberg's layout-editing capacities. But also let them override or add layout blocks if needed.

SilentComics commented Dec 12, 2017

I too believe opt-out would be a better approach. CPTs should start at least with the same editing options than regular posts. You might want to opt out if the CPT is layout-specific though, but their aim is often only taxonomies.
In an ideal world CPTs should have Gutenberg's layout-editing capacities. But also let them override or add layout blocks if needed.

@espiat

This comment has been minimized.

Show comment
Hide comment
@espiat

espiat Dec 13, 2017

Will be there a possibility for theme and plugin authors to label the plugin as "Gutenberg-ready" in the repository? If yes, is the information viewable in the plugin repo api or in the frontend like "Last updated: ", "Tested up to: ", ...?

espiat commented Dec 13, 2017

Will be there a possibility for theme and plugin authors to label the plugin as "Gutenberg-ready" in the repository? If yes, is the information viewable in the plugin repo api or in the frontend like "Last updated: ", "Tested up to: ", ...?

@jiffymac

This comment has been minimized.

Show comment
Hide comment
@jiffymac

jiffymac Jan 11, 2018

@BE-Webdesign would it not make sense to have opt-in until the Meta Box issue is solved then move to opt-out. That solves both issues of not breaking things and moving towards a consistent admin experience.

jiffymac commented Jan 11, 2018

@BE-Webdesign would it not make sense to have opt-in until the Meta Box issue is solved then move to opt-out. That solves both issues of not breaking things and moving towards a consistent admin experience.

@DrewAPicture

This comment has been minimized.

Show comment
Hide comment
@DrewAPicture

DrewAPicture Mar 5, 2018

Member

It seems that one part of the argument that's starkly missing from the discussion here is the case where a custom post type doesn't even use the editor, for instance. Maybe it's just a collection of custom meta boxes or even a custom editing experience. That would be a case where i would want to explicitly exclude a custom post type from Gutenberg "support".

It's one thing to replace the experience of editing written or embedded content in the editor with editing written or embedded content in Gutenberg, it's another entirely to replace what could be a completely asynchronous, non-linear editing experience with something like Gutenberg. Apples to oranges is probably OK, apples to potatoes, probably not so much.

What if anything is going to be the current approach on allowing (or disallowing) post types to "opt-in" to Gutenberg/block-editor support?

Member

DrewAPicture commented Mar 5, 2018

It seems that one part of the argument that's starkly missing from the discussion here is the case where a custom post type doesn't even use the editor, for instance. Maybe it's just a collection of custom meta boxes or even a custom editing experience. That would be a case where i would want to explicitly exclude a custom post type from Gutenberg "support".

It's one thing to replace the experience of editing written or embedded content in the editor with editing written or embedded content in Gutenberg, it's another entirely to replace what could be a completely asynchronous, non-linear editing experience with something like Gutenberg. Apples to oranges is probably OK, apples to potatoes, probably not so much.

What if anything is going to be the current approach on allowing (or disallowing) post types to "opt-in" to Gutenberg/block-editor support?

@pento

This comment has been minimized.

Show comment
Hide comment
@pento

pento Mar 7, 2018

Member

CPTs don't opt-in to Gutenberg support, they opt-out. Currently, that's by declaring that they don't support editor. We discussed having a separate block-editor flag, I think the primary use case for that would be declaring that the CPT supports Classic, but not Gutenberg.

I don't mind the option of 5.0 landing with the current behaviour, that CPTs will use Classic if they don't support editor. We can figure out a way for these CPTs to use Gutenberg in a later release.

CPTs that provide a custom interface are not affected by Gutenberg. The replace_editor filter added in WordPress 4.9 will continue to be respected, and plugins that override the edit screen earlier in the process (ACF being a notable example here) will continue to be able to override it.

Member

pento commented Mar 7, 2018

CPTs don't opt-in to Gutenberg support, they opt-out. Currently, that's by declaring that they don't support editor. We discussed having a separate block-editor flag, I think the primary use case for that would be declaring that the CPT supports Classic, but not Gutenberg.

I don't mind the option of 5.0 landing with the current behaviour, that CPTs will use Classic if they don't support editor. We can figure out a way for these CPTs to use Gutenberg in a later release.

CPTs that provide a custom interface are not affected by Gutenberg. The replace_editor filter added in WordPress 4.9 will continue to be respected, and plugins that override the edit screen earlier in the process (ACF being a notable example here) will continue to be able to override it.

@DrewAPicture

This comment has been minimized.

Show comment
Hide comment
@DrewAPicture

DrewAPicture Mar 7, 2018

Member

Noted. For what it's worth, this is the first time I've heard of the replace_editor hook ;-)

Member

DrewAPicture commented Mar 7, 2018

Noted. For what it's worth, this is the first time I've heard of the replace_editor hook ;-)

@kevinwhoffman

This comment has been minimized.

Show comment
Hide comment
@kevinwhoffman

kevinwhoffman Mar 7, 2018

Contributor

@pento Can you clarify when you would use the replace_editor filter versus just not declaring support for editor when registering the post type?

Contributor

kevinwhoffman commented Mar 7, 2018

@pento Can you clarify when you would use the replace_editor filter versus just not declaring support for editor when registering the post type?

@pento

This comment has been minimized.

Show comment
Hide comment
@pento

pento Mar 8, 2018

Member

Sure, replace_editor is for when you want to provide an entirely custom editing interface for the CPT. For example, this is how Gutenberg uses it.

The current Core behaviour when your CPT removes editor support is to load the editor interface, without the content editor.

For 5.0, I was considering the option of having CPTs that remove editor to automatically fall back to Classic, where their current Core behaviour would be maintained: the content editor wouldn't show. This fall back would potentially change in future WordPress releases, if we add the ability for the block editor to be loaded without the block interface. The CPT may then only fall back to Classic if it has an incompatible meta box, or if the Classic Editor plugin is installed.

Member

pento commented Mar 8, 2018

Sure, replace_editor is for when you want to provide an entirely custom editing interface for the CPT. For example, this is how Gutenberg uses it.

The current Core behaviour when your CPT removes editor support is to load the editor interface, without the content editor.

For 5.0, I was considering the option of having CPTs that remove editor to automatically fall back to Classic, where their current Core behaviour would be maintained: the content editor wouldn't show. This fall back would potentially change in future WordPress releases, if we add the ability for the block editor to be loaded without the block interface. The CPT may then only fall back to Classic if it has an incompatible meta box, or if the Classic Editor plugin is installed.

@kevinwhoffman

This comment has been minimized.

Show comment
Hide comment
@kevinwhoffman

kevinwhoffman Mar 8, 2018

Contributor

For 5.0, I was considering the option of having CPTs that remove editor to automatically fall back to Classic, where their current Core behaviour would be maintained: the content editor wouldn't show.

For CPTs that do not declare editor support, I think you are right to maintain the existing behavior through 5.0 (show the classic edit screen without TinyMCE editor). Many plugins use CPTs to house user experiences that are critical to their functionality. These tend to be the most complex pieces of functionality, such as form-building, that are the most difficult and time-consuming to map to Gutenberg. This means they're least likely to be ported to blocks when 5.0 drops.

In comparison, shortcodes and widgets are easier to blockify, and based on observation, that is where most plugins are focusing their first steps into Gutenberg.

Contributor

kevinwhoffman commented Mar 8, 2018

For 5.0, I was considering the option of having CPTs that remove editor to automatically fall back to Classic, where their current Core behaviour would be maintained: the content editor wouldn't show.

For CPTs that do not declare editor support, I think you are right to maintain the existing behavior through 5.0 (show the classic edit screen without TinyMCE editor). Many plugins use CPTs to house user experiences that are critical to their functionality. These tend to be the most complex pieces of functionality, such as form-building, that are the most difficult and time-consuming to map to Gutenberg. This means they're least likely to be ported to blocks when 5.0 drops.

In comparison, shortcodes and widgets are easier to blockify, and based on observation, that is where most plugins are focusing their first steps into Gutenberg.

@jasonbahl

This comment has been minimized.

Show comment
Hide comment
@jasonbahl

jasonbahl Apr 9, 2018

So, I'm working on a project where I want to use a Gutenberg layout, with all fixed/locked blocks that store in postmeta.

It took me a while to realize that Gutenberg wasn't showing up because I didn't have editor support added. It felt natural to not register "editor" support, as my post_type doesn't make use of anything stored in post_content. But that caused the Gutenberg interface to not display.

Just throwing out there that "editor" support is (in my opinion) tightly coupled to post_content, but Gutenberg isn't necessarily tightly coupled to post_content.

So I'd suggest there be an additional supports flag for block-editor or gutenberg or whatever. Something that's more explicit.

That way, other plugins that assume editor is coupled with post_content can continue making that assumption without being disrupted by Gutenberg.

jasonbahl commented Apr 9, 2018

So, I'm working on a project where I want to use a Gutenberg layout, with all fixed/locked blocks that store in postmeta.

It took me a while to realize that Gutenberg wasn't showing up because I didn't have editor support added. It felt natural to not register "editor" support, as my post_type doesn't make use of anything stored in post_content. But that caused the Gutenberg interface to not display.

Just throwing out there that "editor" support is (in my opinion) tightly coupled to post_content, but Gutenberg isn't necessarily tightly coupled to post_content.

So I'd suggest there be an additional supports flag for block-editor or gutenberg or whatever. Something that's more explicit.

That way, other plugins that assume editor is coupled with post_content can continue making that assumption without being disrupted by Gutenberg.

@jasonbahl

This comment has been minimized.

Show comment
Hide comment
@jasonbahl

jasonbahl Apr 9, 2018

^ perhaps I'm mistaken. Even blocks that store to postmeta will also store some content in the post_content for Gutenberg, eh? So I suppose Gutenberg is always tightly coupled with post_content, eh?

jasonbahl commented Apr 9, 2018

^ perhaps I'm mistaken. Even blocks that store to postmeta will also store some content in the post_content for Gutenberg, eh? So I suppose Gutenberg is always tightly coupled with post_content, eh?

@jasonbahl

This comment has been minimized.

Show comment
Hide comment
@jasonbahl

jasonbahl Apr 9, 2018

^ I'm correcting myself again. In my case, I have a post_type that pulls data in from a 3rd party API and the data should not be mutable in the wp-admin, but it should be viewable. So, I will be using Gutenblocks to display read-only data. So, no data will be stored in post_content at all, but I still want Gutenberg as the interface.

So, Gutenberg isn't necessarily tightly coupled with post_content, where "editor" is.

Still vote to have a more explicit "supports" declaration for Gutenberg. Possibly with some fallback to editor. But more explicit is better in my opinion.

jasonbahl commented Apr 9, 2018

^ I'm correcting myself again. In my case, I have a post_type that pulls data in from a 3rd party API and the data should not be mutable in the wp-admin, but it should be viewable. So, I will be using Gutenblocks to display read-only data. So, no data will be stored in post_content at all, but I still want Gutenberg as the interface.

So, Gutenberg isn't necessarily tightly coupled with post_content, where "editor" is.

Still vote to have a more explicit "supports" declaration for Gutenberg. Possibly with some fallback to editor. But more explicit is better in my opinion.

@danielbachhuber

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber
Member

danielbachhuber commented Apr 26, 2018

Related #3462

@mathetos

This comment has been minimized.

Show comment
Hide comment
@mathetos

mathetos Apr 26, 2018

This is an old issue (I probably was thinking too far ahead when I wrote it), and we've had a lot of discussion and a TON of development has happened since this all started. So, how about I summarize.

Based on @pento s comment here :

I don't mind the option of 5.0 landing with the current behaviour, that CPTs will use Classic if they don't support editor. We can figure out a way for these CPTs to use Gutenberg in a later release.

CPTs that provide a custom interface are not affected by Gutenberg. The replace_editor filter added in WordPress 4.9 will continue to be respected, and plugins that override the edit screen earlier in the process (ACF being a notable example here) will continue to be able to override it.

It sounds like this is the plan for merging into Core:

  1. There will be no block-editor flag for CPTs
  2. If I register a CPT and I want to support the editor at all, I'm going to get Gutenberg
  3. If I register a CPT and I want to customize everything about the edit screen, I'll have the option to use the replace_editor filter just like Gutenberg does.

If I've got that right, here's a few examples to consider:

ACF and other Page Builders
Already mentioned, but obviously they'll be using replace_editor just like Gutenberg does.

Most plugins that use Shortcodes
They'll most likely create blocks, or update their docs to highlight the shortcode block. They'll be fine.

Freelancers/Agencies that build CPTs in their sleep
If they want to use something like CMB2 or whatnot, they can set editor support to false, and create all their metaboxes including the main content editor with the classic TinyMCE editor.

Or they need to learn how to create a trimmed down Gutenberg block experience. This is made a bit easier with Gutenberg features like this one, and ideally this one if it gets addressed.

But the ideal experience in a post-Gutenberg-merge world is that the editor always means Gutenberg, so it's kind of all or nothing.

Is that the gist @pento ?

mathetos commented Apr 26, 2018

This is an old issue (I probably was thinking too far ahead when I wrote it), and we've had a lot of discussion and a TON of development has happened since this all started. So, how about I summarize.

Based on @pento s comment here :

I don't mind the option of 5.0 landing with the current behaviour, that CPTs will use Classic if they don't support editor. We can figure out a way for these CPTs to use Gutenberg in a later release.

CPTs that provide a custom interface are not affected by Gutenberg. The replace_editor filter added in WordPress 4.9 will continue to be respected, and plugins that override the edit screen earlier in the process (ACF being a notable example here) will continue to be able to override it.

It sounds like this is the plan for merging into Core:

  1. There will be no block-editor flag for CPTs
  2. If I register a CPT and I want to support the editor at all, I'm going to get Gutenberg
  3. If I register a CPT and I want to customize everything about the edit screen, I'll have the option to use the replace_editor filter just like Gutenberg does.

If I've got that right, here's a few examples to consider:

ACF and other Page Builders
Already mentioned, but obviously they'll be using replace_editor just like Gutenberg does.

Most plugins that use Shortcodes
They'll most likely create blocks, or update their docs to highlight the shortcode block. They'll be fine.

Freelancers/Agencies that build CPTs in their sleep
If they want to use something like CMB2 or whatnot, they can set editor support to false, and create all their metaboxes including the main content editor with the classic TinyMCE editor.

Or they need to learn how to create a trimmed down Gutenberg block experience. This is made a bit easier with Gutenberg features like this one, and ideally this one if it gets addressed.

But the ideal experience in a post-Gutenberg-merge world is that the editor always means Gutenberg, so it's kind of all or nothing.

Is that the gist @pento ?

@pento

This comment has been minimized.

Show comment
Hide comment
@pento

pento Apr 26, 2018

Member

Thanks for the summary, @mathetos. As @danielbachhuber's comment suggests, there are a few inter-related issues.

I think a block-editor flag would be useful as a transition tool, for a couple of different uses cases.

  • For a CPT that works in classic, but not the block editor, they would set the block-editor flag to false, to automatically fall back to classic.
  • For a CPT that works in the block editor, but doesn't have show_in_rest set, or uses a custom endpoint (as described in #3462), they can explicitly define block-editor support, which will cause the block editor to either default that CPT's show_in_rest setting to true, or assume that the custom endpoint exposes post data in the same way that a generated CPT endpoint does.
  • For CPTs that neither define show_in_rest, nor block-editor, fall back to classic.

It's important to note that that the behaviour of falling back to classic would only be guaranteed for WordPress 5.0: a future release will change this behaviour: CPTs that don't explicitly opt out will likely start loading in the block editor, and those that do opt out will potentially show a "you need to install the Classic Editor plugin" message. I would expect CPTs that use replace_editor to continue to function normally, though there may be some Core libraries that will be moved to the Classic Editor plugin at some later date, so simply reproducing the classic interface is not a permanent solution. 🙂

Obviously, these changes won't happen without being appropriately announced, but you should be planning on updating your code to support the block editor where you can, and rolling out the Classic Editor plugin where you cannot.

We definitely don't want to leave folks with a transition process that they don't understand, or to cut support off prematurely. But it does need to be explicitly clear that everyone will eventually need to transition to either supporting the block editor, or requiring the classic editor.

Member

pento commented Apr 26, 2018

Thanks for the summary, @mathetos. As @danielbachhuber's comment suggests, there are a few inter-related issues.

I think a block-editor flag would be useful as a transition tool, for a couple of different uses cases.

  • For a CPT that works in classic, but not the block editor, they would set the block-editor flag to false, to automatically fall back to classic.
  • For a CPT that works in the block editor, but doesn't have show_in_rest set, or uses a custom endpoint (as described in #3462), they can explicitly define block-editor support, which will cause the block editor to either default that CPT's show_in_rest setting to true, or assume that the custom endpoint exposes post data in the same way that a generated CPT endpoint does.
  • For CPTs that neither define show_in_rest, nor block-editor, fall back to classic.

It's important to note that that the behaviour of falling back to classic would only be guaranteed for WordPress 5.0: a future release will change this behaviour: CPTs that don't explicitly opt out will likely start loading in the block editor, and those that do opt out will potentially show a "you need to install the Classic Editor plugin" message. I would expect CPTs that use replace_editor to continue to function normally, though there may be some Core libraries that will be moved to the Classic Editor plugin at some later date, so simply reproducing the classic interface is not a permanent solution. 🙂

Obviously, these changes won't happen without being appropriately announced, but you should be planning on updating your code to support the block editor where you can, and rolling out the Classic Editor plugin where you cannot.

We definitely don't want to leave folks with a transition process that they don't understand, or to cut support off prematurely. But it does need to be explicitly clear that everyone will eventually need to transition to either supporting the block editor, or requiring the classic editor.

@maddisondesigns

This comment has been minimized.

Show comment
Hide comment
@maddisondesigns

maddisondesigns Apr 26, 2018

@pento Is the Classic Editor plugin going to be updated so that it's more flexible? At the moment it only provides a simple checkbox that basically turns off Gutenberg, or provides an Edit (Classic) link under the Page/Post title.

Ideally it would be good to be able to select which post type uses Gutenberg and which doesn't. i.e. Display a separate checkbox for every CPT on the site and also for one Pages and one for Posts. What if someone is happy for their site to use Gutenberg on Posts but want the classic editor on Pages and on their CPT? Having Edit (Classic) link is one thing, but if someone wants to use both types of editor (for whatever reason), having everything default to Gutenberg is going to be really frustrating for them.

maddisondesigns commented Apr 26, 2018

@pento Is the Classic Editor plugin going to be updated so that it's more flexible? At the moment it only provides a simple checkbox that basically turns off Gutenberg, or provides an Edit (Classic) link under the Page/Post title.

Ideally it would be good to be able to select which post type uses Gutenberg and which doesn't. i.e. Display a separate checkbox for every CPT on the site and also for one Pages and one for Posts. What if someone is happy for their site to use Gutenberg on Posts but want the classic editor on Pages and on their CPT? Having Edit (Classic) link is one thing, but if someone wants to use both types of editor (for whatever reason), having everything default to Gutenberg is going to be really frustrating for them.

@pento

This comment has been minimized.

Show comment
Hide comment
@pento

pento Apr 26, 2018

Member

@maddisondesigns: No, adding that kind of UI isn't planned for the Classic Editor plugin. I understand that people may want to have more advanced UI control, we can certainly add any filters such a plugin would need to be able to create that.

Member

pento commented Apr 26, 2018

@maddisondesigns: No, adding that kind of UI isn't planned for the Classic Editor plugin. I understand that people may want to have more advanced UI control, we can certainly add any filters such a plugin would need to be able to create that.

@danielbachhuber danielbachhuber changed the title from Custom Post Types should have to declare Gutenberg Support to Introduce 'block-editor' post type supports attribute for custom post types with custom controllers Apr 26, 2018

@greatislander

This comment has been minimized.

Show comment
Hide comment
@greatislander

greatislander Jun 2, 2018

Contributor

@pento Following up on your comment:

I think a block-editor flag would be useful as a transition tool, for a couple of different uses cases.

Is there anything I can do to help move this forward? I expect a ticket in WordPress Core Trac to introduce the new flag would be needed; then corresponding code to enable Gutenberg for CPTs with the 'supports' => [ 'block-editor' ]?

Contributor

greatislander commented Jun 2, 2018

@pento Following up on your comment:

I think a block-editor flag would be useful as a transition tool, for a couple of different uses cases.

Is there anything I can do to help move this forward? I expect a ticket in WordPress Core Trac to introduce the new flag would be needed; then corresponding code to enable Gutenberg for CPTs with the 'supports' => [ 'block-editor' ]?

@danielbachhuber

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Jun 4, 2018

Member

@greatislander Let's land a PR here (with corresponding unit tests), and then use it as the basis of the core ticket we open. Ultimately, this won't land in core until WP 5.0

Member

danielbachhuber commented Jun 4, 2018

@greatislander Let's land a PR here (with corresponding unit tests), and then use it as the basis of the core ticket we open. Ultimately, this won't land in core until WP 5.0

@greatislander

This comment has been minimized.

Show comment
Hide comment
@greatislander

greatislander Jun 4, 2018

Contributor

@danielbachhuber I'll try to take a look at this soon.

Contributor

greatislander commented Jun 4, 2018

@danielbachhuber I'll try to take a look at this soon.

@danielbachhuber

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Aug 9, 2018

Member

assume that the custom endpoint exposes post data in the same way that a generated CPT endpoint does.

#8682 is related because it's another implicit expectation of functionality that may or may not be available on non-wp/v2 routes.

Member

danielbachhuber commented Aug 9, 2018

assume that the custom endpoint exposes post data in the same way that a generated CPT endpoint does.

#8682 is related because it's another implicit expectation of functionality that may or may not be available on non-wp/v2 routes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment