Block registration from within the theme is broken in upcoming WordPress release

[fabiankaegy]

In my testing for the upcoming WordPress 6.0 release at the end of May I've found an issue with how we register blocks within the theme scaffold. In order to even be able to register bocks from within a theme, a workaround was added here:

wp-scaffold/themes/10up-theme/includes/blocks.php

Line 51 in a2586e3

add_filter( 'plugins_url', __NAMESPACE__ . '\filter_plugins_url', 10, 2 );

to override the plugins_url value with the theme url.

This worked just fine with all the previous WordPress versions before 6.0 but with some underlying changes (I think this here: WordPress/wordpress-develop@f034bc8#diff-8c99af92e4ec0fdb307ddd9b42be1e1ef1efe4a9f31287c23f346244dddd1ce9R1210-R1246) the filter now breaks some core asset paths.

In order to resolve this issue we either need to somehow modify the filter we are adding to the plugins_url to only alter the path when the path is for the block we are trying to enqueue, and not for any paths.

Or we need to get WordPress core to allow for the inclusion of custom blocks from within themes.

[fabiankaegy]

I have created a patch with core here: https://core.trac.wordpress.org/ticket/55513 but I don't know whether it would get accepted and also whether it could land before the WordPress 6.0 feature freeze.

Flagging this to @joesnellpdx and @tlovett1

(The track ticket I created was a duplicate. Added my comment there: https://core.trac.wordpress.org/ticket/54647#comment:10)

[fabiankaegy]

The patch I've worked on has been merged into core here: https://core.trac.wordpress.org/changeset/53091

This means we will likely (unless someone finds issues with it and reverts the change) be able to remove our hacky solution of filtering the plugin_url in order to be able to register blocks within themes.

We will still need to make sure that every project that uses the filter removes it before updating to 6.0

[joesnellpdx]

@fabiankaegy

We need defined steps to follow to pass on to DEs and Tech Leads how to 1) remove filter and 2) instructions for timing and implementation.

I'm assuming we will have to have an implementation in place and pull the trigger at the same time we upgrade to 6.0? I also assume this means there will be some risk in issues during this transition and for sites that might auto update (thinking VIP) - meaning we can't just remove the filter now without causing issues?

Please together a guidance doc to help us get ahead of this (and correct me if my assumptions are off).

@tlovett1 anything else to add?

[joesnellpdx]

@fabiankaegy

I see the patch guidance here: https://github.com/10up/wp-scaffold/pull/103/files
Thanks!

Let me discuss next steps with @tlovett1 today.

[fabiankaegy]

@joesnellpdx Yes working on it. I have just created a draft pr #103 which would be my recommendation for how projects actually solve this issue. It would allow us to deploy the code even before WordPress 6.0 gets released and therefore make it a seamless update (at least from this perspective).

I'm keeping it as a draft for now till at least the first / second beta version of 6.0 to properly test it and to ensure that the patch actually makes it in 6.0 without getting reverted.

You can find all the details about the release schedule on the make.wordpress blog here: https://make.wordpress.org/core/6-0/
Beta 1 is scheduled for 12 April 2022

[fabiankaegy]

Also just for the record I have created the WordPress 6.0 Milestone here on the scaffold to keep track of all the various things we want to get included for 6.0

[tlovett1]

Makes sense to me. Let's discuss in the next block editor meeting. Thanks for driving this @fabiankaegy !