WordPress/wordpress-playground

Fatal error with browser storage

adamziel opened this issue · 2 comments

adamziel commented

@beafialho reported that:

I ran into an error when I select “Browser” in the storage option:

Fatal error: Uncaught Error: Call to undefined function wp_check_php_mysql_versions() in /wordpress/wp-settings.php:2 Stack trace: #0 /wordpress/wp-config.php(2): require_once() #1 /wordpress/wp-load.php(2): require_once('/wordpress/wp-c...') #2 /wordpress/wp-blog-header.php(2): require_once('/wordpress/wp-l...') #3 /wordpress/index.php(2): require('/wordpress/wp-b...') #4 {main} thrown in /wordpress/wp-settings.php on line 2

Done is:

  • The root cause is identified and described
  • The problem is fixed
  • There is an test case (E2E?) in place to prevent regressions
adamziel commented

Another error:

After the editing and submitting the PR, I got this error message and the site didn’t work anymore:

Fatal error: Cannot redeclare WpOrg\Requests\Transport\Curl::test2() in /wordpress/wp-includes/Requests/src/Transport/Curl.php on line 2
There has been a critical error on this website. Please check your site admin email inbox for instructions. [Learn more about troubleshooting WordPress.](https://href.li/?https://wordpress.org/documentation/article/faq-troubleshooting/)
adamziel commented

wp_check_php_mysql_versions() is defined in wp-includes/load.php, which tells me that file must have been somehow lost. At the same time, WordPress would not load at all if that file was missing, so it must have gotten corrupted in another way.

One way this could have happened, is if the browser loaded mismatched versions of the WordPress wp.data file and the wp.js file. The wp.js contains a map of where each file starts and ends in wp.data and, given a wrong wp.data input, it would produce the correct directory structure, but each file would have the wrong contents.

I don't understand yet what is the connection with the browser storage. That could be purely coincidental, e.g. perhaps @beafialho opened the settings modal and updated both the used WordPress version AND the storage engine, which loaded the outdated and cached .data file after the page reload. I don't think we can infer much more given the information available. Let's conclude search for the root cause here and keep monitoring the situation.

I've opened #855 to track the larger cache busting issue.