Skip to content
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

Custom post types without show_in_rest cannot load editor #3066

Closed
aduth opened this issue Oct 19, 2017 · 4 comments
Closed

Custom post types without show_in_rest cannot load editor #3066

aduth opened this issue Oct 19, 2017 · 4 comments
Labels
Core REST API Task Task for Core REST API efforts [Feature] Extensibility The ability to extend blocks or the editing experience [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes.

Comments

@aduth
Copy link
Member

aduth commented Oct 19, 2017

Previously: #1342 (comment)

This has been known and I assumed there was an issue, but a major blocking issue to relying on the REST API for building a post editor is that a custom post type must explicitly opt in to being available through the REST API, and therefore Gutenberg cannot load correctly otherwise.

Options for moving forward:

  • Load classic editor for these post types
  • Eliminate dependency on core REST API
  • Revise REST API permissions to allow access to non-whitelisted post types in administrative contexts
@joehoyle
Copy link

joehoyle commented Dec 3, 2017

I created https://core.trac.wordpress.org/ticket/42785 to get some progress on better defaults for content included in the REST API. This doesn't quite address all the cases here such as "private" post types, which I think we can also push ahead.

@danielbachhuber danielbachhuber added the [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes. label Mar 30, 2018
@danielbachhuber danielbachhuber added this to the Merge Proposal milestone Mar 30, 2018
@danielbachhuber
Copy link
Member

Cross-posting from the Trac ticket.

I'm unconvinced that show_in_rest should become opt-out instead of opt-in.

Given custom post types probably have custom editor UI (metaboxes and otherwise), it seems unlikely that Gutenberg will be a drop-in replacement for the existing UI. Also, I'm concerned we'd unintentionally expose data we don't mean to expose.

Lastly, such a significant change certainly shouldn't be in a minor release.

For the purposes of Gutenberg, loading the Classic Editor for post types with show_in_rest=false seems sufficient to me.

@danielbachhuber danielbachhuber added the [Feature] Extensibility The ability to extend blocks or the editing experience label Mar 30, 2018
@mtias mtias modified the milestones: Merge Proposal, Merge Proposal: Core API Apr 12, 2018
@dd32
Copy link
Member

dd32 commented Sep 18, 2018

I'm unconvinced that show_in_rest should become opt-out instead of opt-in.

Given custom post types probably have custom editor UI (metaboxes and otherwise), it seems unlikely that Gutenberg will be a drop-in replacement for the existing UI. Also, I'm concerned we'd unintentionally expose data we don't mean to expose.
[snip]
For the purposes of Gutenberg, loading the Classic Editor for post types with show_in_rest=false seems sufficient to me.

I personally agree with the above reasoning, it seems that falling back to the Classic Editor for post_types not supporting show_in_rest is the most compatible and perhaps expected behaviour here.

That means that this has been fixed by 5390ea2 & #3146

@dd32
Copy link
Member

dd32 commented Sep 18, 2018

Going to close this in preference for https://core.trac.wordpress.org/ticket/42785 - Gutenberg acts correctly here, when/if cores defaults change those post_types will pick up Gutenberg if the other conditions are met.

@dd32 dd32 closed this as completed Sep 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core REST API Task Task for Core REST API efforts [Feature] Extensibility The ability to extend blocks or the editing experience [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes.
Projects
None yet
Development

No branches or pull requests

5 participants