WordPress
Post Type Differences: Move away from hard-coding post types.
As we unify the post and site editors into a common abstraction <Editor postId postType /> it's becoming clearer over time that we have a lot of place where we're currently hard-coding differences between post types where we should ideally unify and check things like "post supports"... We're probably lacking several supports or configs to be able to do that consistently.
The good thing is that most of these are now centralized in the @wordpress/editor package. (not all of them yet).
In this issue, let's try to audit all these places and figure out the best path forward to address each of these:
- [ ] Autosave support: We're hard-coding template post type. There's current a core PR trying to make this a post type support config.
- [ ] Permalink/slug support We're relying on the permalink template property that is within each post instance instead of using a post type support or something like that.
- [ ] Global post types In a lot of places in the post and site editor UIs, we apply a specific color treatment to icons... for what we call "global post types" (template, template parts, synced patterns, navigation). The idea is to clarify to the user global changes from local changes. I'm not sure what the solution for that is but some kind of config on the post type would be helpful.
- [ ] Focusable entities When editing template part, pattern and navigation posts, the editor canvas enters "focus" mode, which means it shrinks away from the margins and is resizable. This could be an arbitrary design mode, but might warrant some support config and, optionally, a rename to distinguish this feature from others that use the term "focus", e.g., distraction-free mode.
- [ ] Post type titles and descriptions Template and template parts have a very specific way of retrieving titles and descriptions. Basically, if they don't have specific titles or descriptions, they fetch their descriptions and titles from a globally provided config object. All other post types just seem to use the regular title/description properties. There should be a way to remove this exception and maybe prefill these default title and descriptions on the template/template-part endpoints instead of having this custom logic repeated in a lot of places in our code base.
- [ ] Post Type Actions Some actions from the dataviews components and also from the editor sidebar rely on hard-coded post types to know whether the action is available or not. Ideally we should be using the same "rename", "remove", "duplicate"... actions regardless of the post types and remove these hard-coded checks as much as possible. We maybe lacking some "post type supports" for some of these actions.
- [ ] Scheduling/date support Some post types don't support scheduling changes or changing the publish date.
- [ ] Post status support Some post types don't support changing the post status in the UI, we should have a declarative way to know that.
- [ ] Transform into panel Some post types have a "transform into" panel in the sidebar.
- [ ] Layout applied in editor Some post types apply the theme layout (content width...) to the editor canvas while others don't. What's the discriminating factor here really?
- [ ] Block Editor Context In some post types we "fill" the block editor context with postId and postType of the currently edited post but for other we don't, the idea for this context is to actually fill the content of blocks like post title, post content, ...
This list is non-exhaustive, please feel free to edit the issue and add more hard-coded checks like that. Obviously, these don't necessarily have the same solutions but seeing them together can give us the right perspective to apply the right solution.
Also, please consider helping in some of this work.
cc @WordPress/gutenberg-core
Not sure how deep we want to go, but here are some other thoughts:
- Code editor mode
- Sync status
- Synced pattern overrides also require some hard-coded checks for 'wp_block' post types (but also only work for fully synced post instances). I guess this is an interesting case because there may never be any need to support another post type
- I think there's some additional parts to the 'focusable entities' that @ramonjd mentioned. The post editor also has things like typewriter mode and the space to click beneath the content that selects the last block, while for others the canvas shrinks to the height of the content, and then there's also resizability which only applies to some post types.
Autosave support: We're hard-coding template post type. There's current a core PR trying to make this a post type support config.
Committed in https://core.trac.wordpress.org/changeset/58201
Thanks @swissspidy I'm guessing it's not going to be possible to have this code somehow in Gutenberg too? Since we have to support two WP versions in the Gutenberg plugin, we might need to keep the old hard-coded check around for at least a couple WP releases.