We have noticed an issue on several sites that we deploy with Trellis+Bedrock.
It might be a bug in WordPress, but I post here because I only notice the behaviour in combination with Trellis. I hope to find other people that have the same issue. I will keep this post updated with my findings.
Bug description
After some time has passed after the deployment, we cannot access the WP-Admin.
The page just stays white and the Browser keeps loading. At some point, it loads but without the WP-Admin styles.
Debugging
While this is happening, the php process uses a lot of CPU (100%).
If you open another tab to access the WP-Admin, you will have 2 php processes at 100%.
Temporary Fix
The only way to fix it is to restart the (hanging) php-fpm process (or the whole server).
As this is also done in the finalizing stage of a deployment or provisioning, that also helps.
For now we are restarting the process at night or rebooting the server once a week.
Potential Cause
I looked in to the error.log and found this:
upstream timed out (110: Connection timed out) while reading response header from upstream,
client: [ā¦],
server: example.com,
request: "GET /wp/wp-admin/load-styles.php?c=1&dir=ltr&load%5Bchunk_0%5D=dashicons,admin-bar,common,forms,admin-menu,dashboard,list-tables,edit,revisions,media,themes,about,nav-menus,wp-pointer,widgets&load%5Bchunk_1%5D=,site-icon,l10n,buttons,wp-auth-check&ver=6.4.3 HTTP/2.0",
upstream: "fastcgi://unix:/var/run/php-fpm-wordpress.sock",
host: "example.com",
referrer: "https://example.com/wp/wp-admin/"
I looked in to the mentioned file, and changed the error_reporting to -1 to see what was happening.
Additionally, I added some error_log calls before/after the required files to see what is loaded.
Now, I get this (added line-breaks for readability):
FastCGI sent in stderr: "
PHP message: start;
PHP message: loaded noop;
PHP message: loaded class-wp-theme-json-resolver;
PHP message: loaded resolver;
PHP message: loaded global-styles-and-settings;
PHP message: loaded script-loader;
PHP message: loaded version;
PHP message: PHP Deprecated: urlencode(): Passing null to parameter #1 ($string) of type string is deprecated in /srv/www/example.com/releases/20240321183619/web/wp/wp-includes/script-loader.php on line 1655;
PHP message: PHP Deprecated: file_exists(): Passing null to parameter #1 ($filename) of type string is deprecated in /srv/www/example.com/releases/20240321183619/web/wp/wp-includes/global-styles-and-settings.php on line 412
" while reading response header from upstream,
client: [ā¦],
server: example.com,
request: "GET /wp/wp-admin/load-styles.php?c=1&dir=ltr&load%5Bchunk_0%5D=dashicons,admin-bar,site-health,common,forms,admin-menu,dashboard,list-tables,edit,revisions,media,themes,about,nav-menus,wp-poi&load%5Bchunk_1%5D=nter,widgets,site-icon,l10n,buttons,wp-auth-check&ver=6.4.3 HTTP/2.0",
upstream: "fastcgi://unix:/var/run/php-fpm-wordpress.sock:",
host: "example.com",
referrer: "https://example.com/wp/wp-admin/"
So it seems everything is loaded, but there is some problem afterwards.
Unfortunately, I did not debug this further yet, but I will the next time this issue happens.
From what I know, it could hang either at these lines:
$wp_styles = new WP_Styles();
wp_default_styles( $wp_styles );
or at getting the content of the styles
$content = get_file( $path ) . "\n";
So I will try to look in these calls more deeply.
Also in the Passing null to parameter #1 warnings from urlencode/file_exists.
Additional Context
On these sites we are using minimalistic child themes of either twentytwentythree or another twenty* theme.
So pretty standard behaviour, but block themes with FSE.
Possibly related
There was a similar bug in WordPress Core, which I reported and which was fixed in WordPress 6.3.
I reference this because here the problem was the symlinking/change of the real path to the WordPress directory after deployment. Maybe this is a factor here too.
Just submitted a PR to Bedrock to disable script concatenation by default: