prompt devs to update when there's a critical WP change

[tellyworth]

"There has been a critical error on this website.", happens since f5835d27b9c3582550d692ff34014c2bf4286d97.

From the PHP error logs:

[20-Dec-2021 05:59:24 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function WordPressdotorg\MU_Plugins\Global_Header_Footer\wp_is_block_theme() in /var/www/html/wp-content/mu-plugins/wporg-mu-plugins/mu-plugins/blocks/global-header-footer/blocks.php:104
Stack trace:
#0 /var/www/html/wp-content/mu-plugins/wporg-mu-plugins/mu-plugins/blocks/global-header-footer/blocks.php(131): WordPressdotorg\MU_Plugins\Global_Header_Footer\remove_inner_group_container()
#1 /var/www/html/wp-content/plugins/gutenberg/lib/compat.php(132): WordPressdotorg\MU_Plugins\Global_Header_Footer\render_global_header(Array, '', Object(WP_Block))
#2 /var/www/html/wp-includes/class-wp-block.php(255): {closure}(Array, '', Object(WP_Block))
#3 /var/www/html/wp-includes/blocks.php(875): WP_Block->render()
#4 /var/www/html/wp-includes/blocks.php(913): render_block(Array)
#5 /var/www/html/wp-content/plugins/gutenberg/build/block-library/blocks/template-part.php(89): do_blocks('<!-- wp:wporg/g...')
#6 /var/www/html/wp-content/plugins/gutenberg/lib/compat.php(132): gutenberg_rende in /var/www/html/wp-content/mu-plugins/wporg-mu-plugins/mu-plugins/blocks/global-header-footer/blocks.php on line 104

There are several calls to wp_is_block_theme() in that commit; removing the first fails at the next. I'm not quite sure what the logic should be to protect them with function_exists().

[iandunn]

That's locally rather than production, right?

It looks like the function was renamed a couple weeks ago, but the local env should be running trunk. if you update WP does that fix the error?

[tellyworth]

Yeah it's local only. Running yarn seemed to fix it, so yeah you're right.

Not urgent now, but is there something in the local environment we could do to prompt devs to update when there's a critical WP change like this? Just thinking ahead for future projects.

[iandunn]

🤔 , that's a good question. In this case, I didn't realize the function was so new, so it wouldn't have worked to have some kind of migration script associated w/ commits.

Maybe a more effective way would be for Core & Gutenberg nightly updates to be installed automatically?

[tellyworth]

Yeah that's an option. Alternatively we could pin core to a branch, and force an auto update only when we change the pin.

Or even just a reminder message when you run build or start:all if core is out of date.

[tellyworth]

Weirdly, I keep finding my local install reverting to a broken state. I think my earlier comment about yarn seemingly updating WP was wrong, that might have been coincidence.

yarn run wp-env start --update should update to the core version set in .wp-env.json, right? That's WordPress/WordPress#master which should be trunk. But after running --update wp-admin reports 5.9-alpha-51926, and the front page is broken.

Am I missing a trick here?

[tellyworth]

Further: Updates within wp-admin weren't working because of permission errors. I'm nuking the lot and starting from scratch since it seems like local (permissions? Docker?) issues is the underlying problem.

[iandunn]

Hmm, I'm not sure, I don't actually use the Docker env. My setup is similar to this:

https://noisysocks.com/2021/11/12/set-up-a-wordpress-development-environment-using-homebrew-on-macos/

[tellyworth]

Ah I see. Yeah there seem to be a few things not working 100% as expected in the Docker env. I'll bring them up in issues - obviously not important for the theme launch, just so we remember them for reuse.

[dd32]

"There has been a critical error on this website."

Perhaps a solution here is just to disable that warning in all local development environments we have, so that the error is displayed, and trust that a developer upon seeing a fatal error would think to update their environment?

I don't think it makes sense to proactively prompt people to update their environments.. that should just be expected