Calling wp_get_theme before recovery mode is initialized causes warnings

[lkraav]

I've been running cron via system crontab for years. This is my first 5.1 -> 5.2 update, so not sure when in the beta cycle this might've started.

Warning: Use of undefined constant RECOVERY_MODE_COOKIE - assumed 'RECOVERY_MODE_COOKIE' (this will throw an Error in a future version of PHP) in /home/warmpress/wp-includes/class-wp-recovery-mode-cookie-service.php on line 66
Warning: Use of undefined constant COOKIEPATH - assumed 'COOKIEPATH' (this will throw an Error in a future version of PHP) in /home/warmpress/wp-includes/class-wp-recovery-mode-cookie-service.php on line 68
Warning: Use of undefined constant SITECOOKIEPATH - assumed 'SITECOOKIEPATH' (this will throw an Error in a future version of PHP) in /home/warmpress/wp-includes/class-wp-recovery-mode-cookie-service.php on line 69

[TimothyBlynJacobs]

I wasn't able to immediately replicate this. What version of WP-CLI are you running?

[lkraav]

I was out of date, indeed, but latest stable 2.1.0 does not improve the situation.

$ [-] sudo wp cli update
You have version 2.0.1. Would you like to update to 2.1.0? [y/n] y
Downloading from https://github.com/wp-cli/wp-cli/releases/download/v2.1.0/wp-cli-2.1.0.phar...
md5 hash verified: fa0fb31d1462a5c39a8d4d2cdb369462
New version works. Proceeding to replace.
Success: Updated WP-CLI to 2.1.0.

leho@crdy warmpress $ [-] wp @cxli cron event run --due-now
Warning: Use of undefined constant RECOVERY_MODE_COOKIE - assumed 'RECOVERY_MODE_COOKIE' (this will throw an Error in a future version of PHP) in /home/warmpress/wp-includes/class-wp-recovery-mode-cookie-service.php on line 66
Warning: Use of undefined constant COOKIEPATH - assumed 'COOKIEPATH' (this will throw an Error in a future version of PHP) in /home/warmpress/wp-includes/class-wp-recovery-mode-cookie-service.php on line 68
Warning: Use of undefined constant SITECOOKIEPATH - assumed 'SITECOOKIEPATH' (this will throw an Error in a future version of PHP) in /home/warmpress/wp-includes/class-wp-recovery-mode-cookie-service.php on line 69
Executed the cron event 'facetwp_indexer_cron' in 0.014s.
Executed the cron event 'action_scheduler_run_queue' in 0.032s.
Executed the cron event 'wp_privacy_delete_old_export_files' in 0.017s.
Executed the cron event 'fv_flowplayer_checker_event' in 0.031s.
Success: Executed a total of 4 cron events.

leho@crdy warmpress $ [-] wp cli info
OS:     Linux 4.14.14-gentoo+ #39 SMP PREEMPT Sat Jan 20 21:07:08 EET 2018 x86_64
Shell:  /bin/bash
PHP binary:     /usr/lib64/php7.2/bin/php
PHP version:    7.2.16
php.ini used:   /etc/php/cli-php7.2/php.ini
WP-CLI root dir:        phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:      phar://wp-cli.phar/vendor
WP_CLI phar path:       /home/warmpress
WP-CLI packages dir:    /home/leho/.wp-cli/packages/
WP-CLI global config:   /home/leho/.wp-cli/config.yml
WP-CLI project config:  /home/warmpress/wp-cli.yml
WP-CLI version: 2.1.0

[TimothyBlynJacobs]

Do you get anything different if you run the command directly, not through an alias?

Could you try adding a backtrace call inside wp_recovery_mode() right before the new instance is created? I think this might happen if an error is passed to the wp fatal error handler before cookie constants are defined.

[TimothyBlynJacobs]

It looks like this was because an mu-plugin was loading the currently active theme before wp_cookie_constants was defined. This also occurs before register_theme_directory() is called, so perhaps it could be thought of as a bug in the plugin.

We could try and account for this situation by checking if muplugins_loaded has been fired before checking if the theme is paused in WP_Theme::__construct. I think this might mean that the admin UI when the theme was paused might not be correct since the theme error would never be set.

[TimothyBlynJacobs]

I’m added a patch to drop the constructor entirely which should solve the issue. Instantiating WP_Recovery_Mode should no longer have any required timing. The injection was originally allowed so a multisite drop-in could be added with minimal code duplication, but since we’ve dropped extension support in v1, it makes sense to remove it for now.

Could you verifies this solve your issue @lkraav?

[lkraav]

Yup, no more Notices now. Tyvm!

[SergeyBiryukov]

Replying to TimothyBlynJacobs:

It looks like this was because an mu-plugin was loading the currently active theme before wp_cookie_constants was defined. This also occurs before register_theme_directory() is called, so perhaps it could be thought of as a bug in the plugin.

FWIW, I reproduced the issue by causing a syntax error in a mu-plugin that does not interact with themes in any way.

Since wp_cookie_constants() is called after mu-plugins are loaded, seems like any syntax error in any mu-plugin would cause this issue.

[SergeyBiryukov]

In 45205:

Bootstrap/Load: Remove WP_Recovery_Mode_Cookie_Service constructor to avoid referencing cookie constants before they are defined.

Instantiating WP_Recovery_Mode should no longer have any required timing.

Props TimothyBlynJacobs, lkraav.
Fixes #46882.