[wp-trac] [WordPress Trac] #62715: Block Hooks: Apply to content-like Custom Post Types

[WordPress Trac]

#62715: Block Hooks: Apply to content-like Custom Post Types
-----------------------------+--------------------
 Reporter:  Bernhard Reiter  |      Owner:  (none)
     Type:  enhancement      |     Status:  new
 Priority:  normal           |  Milestone:  6.8
Component:  General          |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+--------------------
 Per [59523] and [59543], Block Hooks are applied to post content and
 synced patterns, respectively.

 This involved adding `update_ignored_hooked_blocks_postmeta` to the
 `rest_pre_insert_*` hook (for the `page`, `post`, and `wp_block` post
 types), and `insert_hooked_blocks_into_rest_response` to the
 `rest_prepare_*` hook (for the same post types).

 The downside of adding those filters to those hooks on an individual post
 type basis is that Block Hooks are only applied to those post types, but
 not to user-defined Custom Post Types; extenders would have to do so
 themselves.

 Arguably, they shouldn't have to; Block Hooks should work out of the box
 for a CPT (assuming that it is a "content-like" CPT). We might thus want
 to consider inlining the code from those two functions into the Posts REST
 API controller (namely, into the `prepare_item_for_database` and
 `prepare_item_for_response` methods, respectively). We can consider adding
 some criteria to make sure that Block Hooks are aren't accidentally
 applied to ancillary post types, such as the ones used for Global Styles.

 Furthermore, the two aforementioned functions now contain logic to map a
 given post type (e.g. `post` or `wp_block`) to the corresponding block
 type (`core/post-content` and `core/block`, in this example). This is
 required so that the block markup can be temporarily wrapped in a block of
 that type, thus allowing Block Hooks to insert hooked blocks as the first
 or last child of the containing block.

 These mappings should be filterable by the user, so that the user can
 extend them to include custom-defined post types and block types,
 respectively -- or to remove mappings, if needed.

 (Stretch goal: In the future, we might want to use these mappings to
 (partially) unify the implementations of blocks like Post Content, Synced
 Pattern, and possibly Navigation and Template Part, which all render
 content that they get separately from the database.)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62715>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform