Questions about the future of Custom Post Types that don't require Block Editing / Content Editing

[ohfuchs]

Hi,

Firstly, I would like to say that I couldn't find any discussion or similar on this topic. If it has already been discussed, I would appreciate a link.

I thought it was about time to migrate some custom post types to the block editor. However, I'm wondering how to handle CPTs that don't require a block-based system (or post_content).

Currently, the behavior is such that CPTs use the old post edit screen unless supports => ['editor'] has been declared. Now, I'm contemplating whether the old system will be revised for the case that content editing isn't wanted or if these CPTs will be transitioned to the block editor. The latter would be the logical choice for me, but without the overhead of the blocks editing experience.

In my vision, I could utilize the space currently occupied by the Blocks for custom components to build various post settings. The right sidebar should retain its place, and there should still be a way to edit the title depending on declared support.

I have tried to create this behavior but couldn't find a clean way to achieve it. I mainly looked into the layout and interface-skeleton components. However, as far as I can see, there is no way to place custom content there. By setting a random editor mode using wp.data.dispatch( 'core/edit-post' ).switchEditorMode('custom'), I was able to partially hide the block features, but without the ability to replace them (metaboxes kind of work).

In general, I would appreciate more flexibility and extensibility regarding custom Editor Modes. However, I may be overlooking existing options.

At the end, the question remains whether CPTs that do not require content editing should be migrated to the Block Editor?

[stokesman]

Have you experimented any more with this since you posted? If you haven't seen it WooCommerce does this for their product post type. The post type doesn’t use the built-in block editor but instead a very customized one. It's likely a bit more custom than what you have in mind but could be worth referencing.

In my vision, I could utilize the space currently occupied by the Blocks for custom components to build various post settings. The right sidebar should retain its place, and there should still be a way to edit the title depending on declared support.

I've done something similiar and here’s the basics of what I did:

• Leave out 'editor' in the CPT supports argument so the built-in block editor won’t load.
• Add an action with add_meta_boxes_{$post_type} (to ensure the rest of this only applies on that CPT edit page) and from there:
  • Add an action with edit_form_after_title to output an empty tag with a unique id for for the next part.
  • Enqueue a script to initialize the editor UI (rendering it into the element added in the previous point).

At the end, the question remains whether CPTs that do not require content editing should be migrated to the Block Editor?

I'd say no. Since a post of such type won’t contain blocks there is no reason. Yet it could be advantageous to implement a custom editor UI based on the Gutenberg packages so you can leverage components and reactivity.

[ohfuchs]

Thank you for your response. Yes, in the meantime, I built a full integration based on metaboxes. I also considered creating my own editor instance but decided that it might become too maintenance-intensive.

What I basically did is:

• Added 'editor' support to the post type

• Added a metabox with a unique element <div id=”my-root”></div>

• Used registerPlugin to:

  • Render a Portal to #my-root, containing my custom components.
  • Render a PluginSidebar which will automatically open after load.
  • Render another Portal to the main toolbar #editor .editor-document-tools, on an element I placed dynamically. For this, I used a subscription to the 'editor' datastore. This approach was also inspired by some WooCommerce code.

• Optionally, I could switch the editor mode to a random value to get rid of unwanted features (blocks), but for now, I left them be. The Block editor only takes a very small area of the screen and can easily be scrolled out of view.

I think creating such a custom solution is great if you want to do complex stuff, but not if you just want the core features like taxonomies, title or post_status but just without post_content (Blocks).

I’m satisfied with my solution, but still wondering what the official roadmap on this kind of post types is.

[stokesman]

I'm glad you've found a workable way forward.

… but still wondering what the official roadmap on this kind of post types is.

Understandably, it does seem a mostly overlooked use case but I could be missing some threads that have covered it.

This PR #59242 has some related discussion with #59242 (comment) showing some of the mockups created in the context of the effort to revamp the whole wp-admin.