6.0: Throw a _doing_it_wrong in register_block_pattern if not registered on `init` hook.

[johnstonphilip]

In WP 6.0, block patterns are now being loaded after initial page load via the REST API.

This means that any block patterns not registered on the init hook will no longer show up.

Therefore, the ​register_block_pattern function should only be used on the init hook, and if not, it should throw a ​_doing_it_wrong so the code author knows.

For more see:
​https://github.com/WordPress/gutenberg/issues/40736

[costdev]

Thanks @johnstonphilip!

Milestoning for 6.0 for visibility and because the need for this was introduced during the 6.0 cycle (i.e. I'm considering it a regression without the _doing_it_wrong()).

Trac ticket: https://core.trac.wordpress.org/ticket/55655

See my comments here ​https://github.com/WordPress/gutenberg/issues/40736#issuecomment-1115494306 about forcing registration to only be when hooked to init. I'm wondering what the impact to extenders will be.

See my comments here ​WordPress/gutenberg#40736 (comment) about forcing registration to only be when hooked to init. I'm wondering what the impact to extenders will be.

I think it will be problematic.

Both post types and taxonomy require developers wait until the _init hook or later_ to register a custom object. As the init hook is relatively early, later registration can come in handy when the developer wishes to know something about the request when registering the custom object.

That may also be the case here where waiting for the query to be parsed may be helpful.

[peterwilsoncc]

I put the Gutenberg issue on the WP 6.0 project board for the editor folks to action.

I'll keep this ticket open for now as it looks like the code might need to be manually backported to WP.

[hellofromTonya]

6.0 RC1 is minutes away. Given there are BC concerns about making init a hard requirement, moving this to 6.1. It could be considered for a minor too.

[johnstonphilip]

@hellofromTonya I don't believe there are any BC concerns because this is already broken on 6.0 for anyone using a hook other than init. The _doing_it_wrong will at least offer an explanation as to why it is broken.

[hellofromTonya]

To help contributors and followers, the main conversation for this issue is in this Gutenberg issue ​https://github.com/WordPress/gutenberg/issues/40736.

For the BC concerns, please refer to ​@peterwilsoncc's comment in that issue:

WordPress has a core philosophy to maintain backward compatibility, so neither a doing it wrong call or saying it's not possible is the answer. Something needs to be fixed.

​bdd024e removed examples of Gutenberg registering block patterns on hooks other than init. Extenders learnt to use current_screen from Core & Gutenberg.

[audrasjb]

Just updated the PR to change @since mentions.

As per today's bug scrub, it appears the related upstream PR was merged.

@peterwilsoncc @costdev do you think this PR could ship with 6.1?

[desrosj]

Unfortunately, this one won't make it. RC1 is due out within the hour.

Notice at the end of WP_Block_Patterns_Registry::register() there's code to detect and store a pattern not registered on init. The code in this PR would bail out before that code and the subsequent code that works with the registered_patterns_outside_init property. In other words, a _doing_it_wrong() with an early bail-out negates the tracking and use case of the registered_patterns_outside_init property and its usage.

[hellofromTonya]

Correct me if I'm wrong, but reading the resolution of ​https://github.com/WordPress/gutenberg/issues/40736, the fix implemented was:

A combination of ​https://github.com/WordPress/wordpress-develop/pull/2672 (Core) and ​https://github.com/WordPress/gutenberg/pull/40818 (Gutenberg) should fix this.

[53404] / #55567 added tracking and handling of patterns registered outside of init action via the registered_patterns_outside_init property. Adding a _doing_it_wrong() would disable that change.

Thinking this ticket then is close as wontfix.

[hellofromTonya]

Moving this ticket back to Awaiting Review as it needs further discussion and might be a close candidate.

[costdev]

I agree with closing the ticket, though maybe invalid and a note that backports in #55567 already solved this issue would be more accurate than wontfix?