[wp-trac] [WordPress Trac] #60754: Block Hooks: Incorrect context passed when setting ignored hooked blocks metadata

[WordPress Trac]

#60754: Block Hooks: Incorrect context passed when setting ignored hooked blocks
metadata
-------------------------------------------------+-------------------------
 Reporter:  Bernhard Reiter                      |       Owner:  Bernhard
                                                 |  Reiter
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  6.5.3
Component:  General                              |     Version:  6.5
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests fixed-      |     Focuses:
  major dev-reviewed                             |
-------------------------------------------------+-------------------------
Changes (by Bernhard Reiter):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"58041" 58041]:
 {{{
 #!CommitTicketReference repository="" revision="58041"
 Block Hooks: Pass correct context to filters.

 The `$context` argument passed to filters such as `hooked_block_types`,
 `hooked_block`, and `hooked_block_{$hooked_block_type}` allows them to
 conditionally insert a hooked block. If the anchor block is contained in a
 template or template part, `$context` will be set to a `WP_Block_Template`
 object reflecting that template or part.

 The aforementioned filters are applied when hooked block insertion is run
 upon reading a template (or part) from the DB (and before sending the
 template/part content with hooked blocks inserted over the REST API to the
 client), but also upon writing to the DB, as that's when the
 `ignoredHookedBlocks` metadata attribute is set.

 Prior to this changeset, the `$context` passed to Block Hooks related
 filters in the latter case reflected the template/part that was already
 stored in the database (if any), which is a bug; instead, it needs to
 reflect the template/part that will result from the incoming `POST`
 network request that will trigger a database update.

 Those incoming changes are encapsulated in the `$changes` argument passed
 to the `reset_pre_insert_template` and  `reset_pre_insert_template_part`
 filters, respectively, and thus to the
 `inject_ignored_hooked_blocks_metadata_attributes` function that is hooked
 to them. `$changes` is of type `stdClass` and only contains the fields
 that need to be updated. That means that in order to create a
 `WP_Block_Template` object, a two-step process is needed:

 - Emulate what the updated `wp_template` or `wp_template_part` post object
 in the database will look like by merging `$changes` on top of the
 existing `$post` object fetched from the DB, or from the theme's block
 template (part) file, if any.
 - Create a `WP_Block_Template` from the resulting object.

 To achieve the latter, a new helper method
 (`_build_block_template_object_from_post_object`) is extracted from the
 existing `_build_block_template_result_from_post` function. (The latter
 cannot be used directly as it includes a few database calls that will fail
 if no post object for the template has existed yet in the database.)

 While somewhat complicated to implement, the overall change allows for
 better separation of concerns and isolation of entities. This is visible
 e.g. in the fact that `inject_ignored_hooked_blocks_metadata_attributes`
 no longer requires a `$request` argument, which is reflected by unit tests
 no longer needing to create a `$request` object to pass to it, thus
 decoupling the function from the templates endpoint controller.

 Unit tests for `inject_ignored_hooked_blocks_metadata_attributes` have
 been moved to a new, separate file. Test coverage has been added such that
 now, all three relevant scenarios are covered:

 - The template doesn't exist in the DB, nor is there a block theme
 template file for it.
 - The template doesn't exist in the DB, but there is a block theme
 template file for it.
 - The template already exists in the DB.

 Those scenarios also correspond to the logical branching inside
 `WP_REST_Templates_Controller::prepare_item_for_database`, which is where
 `inject_ignored_hooked_blocks_metadata_attributes` gets its data from.

 Reviewed by gziolo.
 Merges [57919] to the to the 6.5 branch.

 Props tomjcafferkey, bernhard-reiter, gziolo, swissspidy.
 Fixes #60754.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60754#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform