[wp-trac] [WordPress Trac] #59574: Blocks: No toggle shown for hooked blocks added via filter

[WordPress Trac]

#59574: Blocks: No toggle shown for hooked blocks added via filter
-----------------------------+------------------------------
 Reporter:  Bernhard Reiter  |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------

Comment (by Bernhard Reiter):

 `$context`, as specified as a filter argument, can be fairly
 heterogeneous. It can be

 - a `WP_Template` object (for templates or template parts)
 - an array (for patterns),
 - or a `WP_Post` object with `post_type` set to `wp_navigation` (for
 navigation menus).

 (The latter is being added by
 https://github.com/WordPress/gutenberg/pull/57754 and
 https://github.com/WordPress/wordpress-develop/pull/5946.)

 How do we best map this variety of `$context`s to a REST API endpoint
 query string syntax (where we can e.g. limit to "only template parts for
 the header area"), and keep it extensible?

 We can think of these different "entities" at different levels. One is
 WordPress’ PHP classes and types (see above). But there’s also the DB
 level (where templates, template parts, and Navigation menus are all
 stored in `wp_posts`, with different `post_type`s; it's a bit more subtle
 for patterns), and finally the REST API level, where there are different
 endpoints (`/templates/`, `/block-patterns/patterns/`, and
 `/navigation/`).

 Maybe the latter would be a good fit to inspire the query syntax for the
 hooked blocks' context, as they're operating in the same realm -- the REST
 API.

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