Missing WP_Block_Type_Registry Class break site - WP 6.0.1

[bahiirwa]

The plugin returns a warning for moving to from WP 6.0.1 to CP.

However, when the theme/plugin activated is block based, WP_Block_Type_Registry class is missing and throws

Fatal error: Uncaught Error: Class 'WP_Block_Type_Registry' not found in /www/villageattheglenscom_746/public/wp-content/plugins/stackable-ultimate-gutenberg-blocks-premium/src/blocks.php:121

This breaks the site and installation until one changes the theme physicall by deleting the block theme and plugins. WP CLI will not work to change plugins and themes at this stage.

[mattyrob]

Looking at the current API endpoint for migration, we need to add

1. The TwentyTwentyTwo theme
2. The Stackable: Ultimate Gutenberg Blocks plugin (https://wpstackable.com)

[bahiirwa]

That might not be exhaustive as many plugins and themes are adopting this.

Can't we scan the theme/plugin for the class or the minimum version to throw an error if the required CP/WP version has the particular class ? https://github.com/ClassicPress/ClassicPress-Migration-Plugin/pull/94 does half of this

https://developer.wordpress.org/reference/classes/wp_block_type_registry/ came after WP 5.0.0

[mattyrob]

Scanning plugins and themes is a reasonable suggestion but with some major technical barriers.

First we would simply swap a curated list of breaking plugins and themes for a list of breaking functions. Next there is actually the process of scanning all of the files prior to allowing migration - on sites with large numbers of plugins that could be a poor user experience. And lastly, the scanning would have to be smart enough to detect conditional loading - I have a plugin that works perfectly well on ClassicPress but it contains a call to register_block_type() - this call is only made if the Block editor is detected and the class with this function is then loaded. So the risk of false positives blocking migration gets more of a consideration.

One other possibility is we simply retire the migration plugin and leave it to users to complete the process via FTP.

[viktorix]

What if we simply scan plugin/theme readme files checking for "requires" tag? It's not perfect, but can provide a basic check for incompatible plugins.

I wouldn't retire migration plugin just yet. People do use it.

Maybe additional warning for WordPress 6.x can help a bit. User will be more aware of possibly issues.

[KTS915]

Another vote for the "requires" tag! The migration plugin is never going to be perfect but at least that means we're holding developers to their claims!

[mattyrob]

Plugin header checks have been in the migration plugin code since version 1.4.0. There is a PR to add the same for themes - I'd have to refresh my memory on that PR.

I can only think that the plugin that cause this issue omitted the header.

[bahiirwa]

@mattyrob Thanks for pointing out the version number. I was using 1.3.1. On manual update to 1.4.1, I get this message

The issue might be valid if we get a way to detect the class requirement in the future.

[viktorix]

I've been thinking about a possible way to scan for problematic functions and have 2 ideas I'm just sharing in case one of them is doable/good that doesn't ruin user experience:

1. Make the scan work in the background. Similar to how thumbnail regeneration plugins work or WooCommerce database update works in the background. Once it's complete, it will provide results and if everything is good make button to start migration active.
2. Offload checks to CP server through an API. It sends a list of plugin slugs and version, including theme, to our API and we run checks on these plugins/theme if they are available in the repo. This wouldn't really work with premium plugins/theme though. We could also store results per plugin/theme and version so if anyone else requested them we wouldn't need to run checks on files again.

Just ideas I'm throwing out there. Maybe it'll help someone come up with a better solution.