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

Gutenberg and Custom Post Types #6757

Closed
maddisondesigns opened this Issue May 15, 2018 · 10 comments

Comments

Projects
None yet
4 participants
@maddisondesigns
Copy link

maddisondesigns commented May 15, 2018

There's very little in the handbook/documentation in regards to how Gutenberg is going to work with Custom Post Types. Trying to find answers to basic questions within these Github issues is also near impossible as there's so many contradicting answers due to how things have changed over this past year.

I have some simple questions that I'm sure a lot of other developers would like to know the answers to as well...

  • Will Gutenberg be enabled by default on CPTs?
    At one stage in my testing, I thought that it was but in testing with the latest version of Gutenberg, it seems that isn't. On one of my existing dev sites where I've added the Gutenberg plugin, none of my CPTs use Gutenberg when I try to edit them (thankfully).

  • If not enabled by default, how is Gutenberg enabled?
    From what I can tell, at the moment you have to explicitly do two things when using register_post_type(). 1) Pass 'show_in_rest' => true in your args and 2) Specify 'editor' in the 'supports' array. Currently 'show_in_rest' appears to default to false (thankfully). Is this going to be the final solution to enabling/disabling Gutenberg in CPTs or is it likely to change?

  • Why do we need to install the Classic Editor plugin?
    If we can explicitly configure our CPTs to not use Gutenberg, then they will obviously need to default back to the classic editor, which also leads me to assume that this functionality is remaining in core. If this is the case, why are we forced to install the Classic Editor plugin just so we can use it on Pages & Posts, if that functionality is being left in Core to support CPTs? And again, if it is, why is this functionality not being exposed with a simple hook to enable developers to enable/disable it per post type, instead of having to resort to installing a plugin?

  • Is the Classic Editor functionality being left in Core?
    If the Classic Editor functionality is being completely stripped from core, what happens to CPTs that opt not to use Gutenberg (either explicitly or by default)? Will the site need to have the Classic Editor Plugin installed for CPTs to make use of it? What are the plans for mitigating the breakage of CPTs on millions of sites that don't install the Classic Editor plugin from day 1?

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented May 15, 2018

Great question, @maddisondesigns !

The most up-to-date thinking is defined in #2457 (comment) The underlying implementation still needs to be put into place though. We'll make sure the behavior is formally documented when we do.

@danielbachhuber danielbachhuber added this to the Merge Proposal: Core milestone May 15, 2018

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented May 15, 2018

Closing in favor of #2457. We'll make sure the behaviors are documented when the implementation is finalized.

@danielbachhuber danielbachhuber removed this from the Merge Proposal: Core milestone May 15, 2018

@maddisondesigns

This comment has been minimized.

Copy link
Author

maddisondesigns commented May 16, 2018

@danielbachhuber Thanks for that link.

So, from reading that, Classic Editor functionality wont be removed from core in 5.0, but may be removed at a later date. If that's the case, why not simply put an option in Settings initially instead of forcing people to install the classic Editor plugin from day 1. When the time comes that the Classic Editor code is removed from core, then you simply have to remove that setting as well. It seems ridiculous that you're basically duplicating code on peoples websites by installing the plugin, when that same code will exist in core (initially).

I'm also extremely concerned about

CPTs that don't explicitly opt out will likely start loading in the block editor

There are going to be hundreds of thousands of sites that are using CPTs, and who are either no longer in touch with their original developer or have no way of updating the theme/plugin that is creating these CPTs. Simply switching them over to the block editor by default, should not be considered. You should be leaving them to default to the Classic Editor and showing them the same "you need to install the Classic Editor plugin" message that you plan on showing for CPTs that do explicitly opt out.

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented May 16, 2018

So, from reading that, Classic Editor functionality wont be removed from core in 5.0, but may be removed at a later date.

Correct: the Classic Editor will be removed at a later date.

If that's the case, why not simply put an option in Settings initially instead of forcing people to install the classic Editor plugin from day 1.

See WordPress' philosophy as in regards to decisions, not options. This particular decision is a hard decision. It's not something open for debate at this point.

There are going to be hundreds of thousands of sites that are using CPTs, and who are either no longer in touch with their original developer or have no way of updating the theme/plugin that is creating these CPTs.

Can you share the data you have to support this statement?

Simply switching them over to the block editor by default, should not be considered.

To clarify, Gutenberg will only be enabled for CPTs with 'editor' post type support and show_in_rest=true, not all CPTs.

@ghost

This comment has been minimized.

Copy link

ghost commented May 16, 2018

... and show_in_rest=true, not all CPTs.

Old CPTs might not have set show_in_rest because it defaults to false. That default will be changed to true with #42785, so Gutenberg will probably hijack a lot of these old CPTs.

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented May 16, 2018

That default will be changed to true with 42785, so Gutenberg will probably hijack a lot of these old CPTs.

Just to clarify, we're unlikely to change the default behavior for show_in_rest for WordPress 5.0 (per reasons described in https://core.trac.wordpress.org/ticket/42785#comment:30).

#2457 (comment) is the most recent thinking.

@ghost

This comment has been minimized.

Copy link

ghost commented May 16, 2018

#42785 is assigned, has-patch, milestone recently set to 5.0 by owner, listed in Next Major Release.

If recent thinking changed the situation, please close it.

@maddisondesigns

This comment has been minimized.

Copy link
Author

maddisondesigns commented May 17, 2018

See WordPress' philosophy as in regards to decisions, not options.

"decisions, not options" is simply WordPress core developer speak for, "we're not changing our mind". There are literally dozens of instances where core dev "decisions, not options" have been the exact opposite of what the whole community wants. Same goes for your 80/20 rule which you constantly break. I'm so sick of seeing people quoting "decisions, not options" simply because they just refuse to change their mind or don't want to hear any further arguments.

Can you share the data you have to support this statement?

You only have to look at the number of developers/agencies that use things like ACF, CMB, PODS and the like. The majority of the time, custom meta boxes are used in conjunction with CPTs. You are going to break hundreds of thousands of sites by changing the show_in_rest default!

To clarify, Gutenberg will only be enabled for CPTs with 'editor' post type support and show_in_rest=true, not all CPTs.

The whole reason I mentioned what I did, is exactly the same reason that @tkes mentioned it. You literally have a ticket (#42785) sitting there for 5.0 that will change the default of show_in_rest to true! This is going to guarantee that EVERY SINGLE SITE where I've used CPTs and ACF is going to break, because they have editor post type support, and because I haven't defined show_in_rest BECAUSE IT'S SUPPOSED TO DEFAULT TO false! Where do I send my invoice for all my time that will need to be spent on fixing hundreds of sites? Should I just send that to Automattic? And are you going to advise all my customers that it's WordPress cores "decisions, not options" that caused their site to break, and not actually the developers fault?

screenshot_658

@aaronjorbin

This comment has been minimized.

Copy link
Member

aaronjorbin commented May 17, 2018

I've updated 42785 to reflect the current thinking.

Part of "Decisions, not options" is "In the presence of good rationale, maintainers should be willing to change their mind often." Repeating things over and over doesn't make reasoning any better. Providing numbers and concrete examples as @danielbachhuber suggested can.

If you are aware of metaboxes or metabox helpers that are broken with Gutenberg that haven't been reported yet, I would encourage you to open bug reports. https://plugincompat.danielbachhuber.com/ is also useful for tracking plugin compatibility.

@aaronjorbin

This comment has been minimized.

Copy link
Member

aaronjorbin commented May 17, 2018

Here is one of the articles that inspired "decisions, not options" which includes the quote about good rationale. It's always worth a read or re-read. http://ometer.com/features.html

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