WordPress 6.0 update deploy failed

Twansparant · May 25, 2022, 9:57am

Hi guys,

After the release of Wordpress 6.0 I updated the roots/wordpress version in my composer.json in an existing project to 6.0 like in this Bedrock commit:

"roots/wordpress": "^6.0",
"wpackagist-theme/twentytwentytwo": "^1.2"

Locally this worked great, I can see the wp-content folder is not there anymore.
However, when I tried to deploy these changes to an existing staging droplet, I’m getting his error:

TASK [deploy : WordPress Installed?] *******************************************
System info:
  Ansible 2.10.17; Darwin
  Trellis version (per changelog): "Improve handling of PHP versions and support PHP 8.0"
---------------------------------------------------
Warning: strpos(): Empty needle in
/srv/www/mydomain/releases/20220525094312/web/wp/wp-includes/link-template.php
on line 3535
Warning: strpos(): Empty needle in
/srv/www/mydomain/releases/20220525094312/web/wp/wp-includes/link-template.php
on line 3535
fatal: [82.196.1.191]: FAILED! => {"changed": false, "cmd": ["wp", "core", "is-installed", "--skip-plugins", "--skip-themes", "--require=/srv/www/mydomain/shared/tmp_multisite_constants.php"], "delta": "0:00:01.115367", "end": "2022-05-25 09:44:01.258353", "failed_when_result": true, "rc": 0, "start": "2022-05-25 09:44:00.142986", "stderr": "Warning: strpos(): Empty needle in /srv/www/mydomain/releases/20220525094312/web/wp/wp-includes/link-template.php on line 3535\nWarning: strpos(): Empty needle in /srv/www/mydomain/releases/20220525094312/web/wp/wp-includes/link-template.php on line 3535", "stderr_lines": ["Warning: strpos(): Empty needle in /srv/www/mydomain/releases/20220525094312/web/wp/wp-includes/link-template.php on line 3535", "Warning: strpos(): Empty needle in /srv/www/mydomain/releases/20220525094312/web/wp/wp-includes/link-template.php on line 3535"], "stdout": "", "stdout_lines": []}

When I lookup the strpos function call in link-template.php on line 3535:

	$mu_plugin_dir = wp_normalize_path( WPMU_PLUGIN_DIR );

	if ( ! empty( $plugin ) && 0 === strpos( $plugin, $mu_plugin_dir ) ) {
		$url = WPMU_PLUGIN_URL;
	} else {
		$url = WP_PLUGIN_URL;
	}

It seems the $mu_plugin_dir variable is empty?
Any ideas what’s going on here?

I already merged this Bedrock commit for the new Bedrock autoloader?

Downgrading roots/wordpress to ^5.9 fixes the failing deploys for now.

Thanks!

strarsis · May 25, 2022, 10:12am

Same deployment error yesterday with the ~~no-content~~ 6.0 package.

That particular Empty needle error occurred to me in the past for PHP fatal errors, like open base dir restriction errors. So the underlying issue may be something else.

strarsis · May 25, 2022, 7:27pm

Update: This error only occurs in the Trellis WordPress Installed? check.
When the current symlink is manually changed to the newly deployed release that failed the check, the site still loads fine, everything works as it should (even a simple wp core is-installed exits with success status code).
When I replace that command with /usr/bin/true (because a variable is also set and such, just commenting it out would require more modifications), the deployment completes without errors.

Commenting out the --require={{ deploy_helper.shared_path }}/tmp_multisite_constants.php part of the wp core is-installed --skip-plugins --skip-themes --require={{ deploy_helper.shared_path }}/tmp_multisite_constants.php command lets the deploy succeed.
So the underlying error is caused by --require={{ deploy_helper.shared_path }}/tmp_multisite_constants.php. Judging from the name tmp_multisite_constants.php of the required file, maybe WordPress 6.0 has a breaking change with regards to multisite constants.

Manual demonstration:
For simplicity, the same wp CLI command that is used by the deploy check is ran on the Trellis server:

Log into the Trellis server as web user.
Go into the site release directory that failed (e.g. /srv/www/example.com/20220525193449/).
Invoke the wp CLI command used by the deploy check:
wp core is-installed --skip-plugins --skip-themes --require=/srv/www/example.com/shared/tmp_multisite_constants.php
The command fails with the same PHP errors as during deploy.
Now re-run that wp CLI command, but without the --require=/srv/www/example.com/shared/tmp_multisite_constants.php part.
The command now exits without the PHP warnings.

evankford · May 25, 2022, 7:46pm

Adding my two cents here that I had to custom edit that multisite_constants.php in the last few months even before wordpress 6.0. Specifically, it works when I do this, sort of:

<?php
error_reporting(E_ALL & ~E_NOTICE);
// define('MULTISITE', false);
// define('SUBDOMAIN_INSTALL', false);
define('WPMU_PLUGIN_DIR', null);
define('WP_PLUGIN_DIR', null);
define('WP_USE_THEMES', false);

I just had to get it to work, so I’m not sure why.

strarsis · May 25, 2022, 7:48pm

Similar results here, when I use this tmp_multisite_constants.php

<?php
error_reporting(E_ALL & ~E_NOTICE);
define('MULTISITE', false);
define('SUBDOMAIN_INSTALL', false);
//define('WPMU_PLUGIN_DIR', null);
define('WP_PLUGIN_DIR', null);
define('WP_USE_THEMES', false);

with define('WPMU_PLUGIN_DIR', null); commented out, it fixes the error that otherwise occurs since WordPress 6.0 (so since basically yesterday when it came out).

strarsis · May 25, 2022, 7:54pm

That’s the line the PHP warnings are reported from by ansible (with define('WPMU_PLUGIN_DIR', null);):

github.com

WordPress/WordPress/blob/ec3b0158d85e7fb2ba72a70e8ce88f8221d1615d/wp-includes/link-template.php#L3535

      
        
            *                       The URL will be relative to its directory. Default empty.
            *                       Typically this is done by passing `__FILE__` as the argument.
            * @return string Plugins URL link with optional paths appended.
            */
            function plugins_url( $path = '', $plugin = '' ) {
            
            
	$path          = wp_normalize_path( $path );
            	$plugin        = wp_normalize_path( $plugin );
            	$mu_plugin_dir = wp_normalize_path( WPMU_PLUGIN_DIR );
            
            
	if ( ! empty( $plugin ) && 0 === strpos( $plugin, $mu_plugin_dir ) ) {
            		$url = WPMU_PLUGIN_URL;
            	} else {
            		$url = WP_PLUGIN_URL;
            	}
            
            
	$url = set_url_scheme( $url );
            
            
	if ( ! empty( $plugin ) && is_string( $plugin ) ) {
            		$folder = dirname( plugin_basename( $plugin ) );
            		if ( '.' !== $folder ) {

The code in the plugins_url function does not check whether $mu_plugin_dir is not empty, (hence the Warning: strpos(): Empty needle).

Edit: Changing that line so that it checks for an empty needle, the wp command just passes fine:

if ( ! empty( $plugin ) && ! empty( $mu_plugin_dir ) && 0 === strpos( $plugin, $mu_plugin_dir ) ) {

The exit code with and without the PHP error is 0 (success)…
But with PHP warnings the ansible check fails. This is because the ansible check not only checks for an exit code smaller 1 (some kind of success I guess), but also checks for an empty stderr from wp:

github.com

roots/trellis/blob/f1f8ff1c7d10dba602916aff4c04d0132c524da3/roles/deploy/hooks/finalize-before.yml#L13

      
        
              copy:
                src: "tmp_multisite_constants.php"
                dest: "{{ deploy_helper.shared_path }}/tmp_multisite_constants.php"
            
            
- name: WordPress Installed?
              command: wp core is-installed --skip-plugins --skip-themes --require={{ deploy_helper.shared_path }}/tmp_multisite_constants.php
              args:
                chdir: "{{ deploy_helper.new_release_path }}"
              register: wp_installed
              changed_when: false
              failed_when: wp_installed.stderr | default("") != "" or wp_installed.rc > 1
            
            
- name: Get WP theme template and stylesheet roots
              shell: >
                {% if not project.multisite.enabled | default(false) %}
                  wp option get {{ item }} --skip-plugins --skip-themes
                {% else %}
                  wp site list --field=url | xargs -I {} bash -c 'export url="{}"; echo -n "$url " && wp option get {{ item }} --skip-plugins --skip-themes --url=$url || echo'
                {% endif %}
              args:
                chdir: "{{ deploy_helper.current_path }}"

The PHP warnings end up in stderr, hence the ansible check and the deployment fails.
And the deployment follows a more conservative strategy by rather failing with PHP warnings from wp than risking trouble with the new deployment.

I am curious what changes were introduced in WordPress 6.0 that causes the PHP warnings, because in latest WordPress 5.x no PHP warnings were emitted with the same Trellis setup.

strarsis · May 25, 2022, 8:18pm

tmp_multisite_constants.php defines the WPMU_PLUGIN_DIR constant as null.
WordPress checks for undefined WPMU_PLUGIN_DIR constant and defines one with some default value:

github.com

WordPress/WordPress/blob/7f9c9dc73122e8d676b25be1f599ec487489060b/wp-includes/default-constants.php#L197-L198

      
        
            	if ( ! defined( 'WPMU_PLUGIN_DIR' ) ) {
            		define( 'WPMU_PLUGIN_DIR', WP_CONTENT_DIR . '/mu-plugins' ); // Full path, no trailing slash.

The question is: Is null an allowed/expected value for the WPMU_PLUGIN_DIR constant?
How should one set WPMU_PLUGIN_DIR to nothing otherwise?
WordPress core (at least since 6.0) doesn’t appear to be able to handle this case (hence the empty needle PHP warning).

Why is WPMU_PLUGIN_DIR set to null - would the default value that is assigned by WordPress be acceptable?

Related GitHub issue:

github.com/roots/trellis

`tmp_multisite_constants.php` defines constant that may be redefined afterwards

opened 12:52PM - 29 Oct 18 UTC

stefanotorresi

## Bug report - [x] I've read the [guidelines for Contributing to Roots Proje…cts](https://github.com/roots/guidelines/blob/master/CONTRIBUTING.md) - [ ] This is a feature request - [x] This is a bug report - [ ] This request isn't a duplicate of an [existing issue](https://github.com/roots/trellis/issues) _(unsure, could be related to #805)_ - [x] I've read the [docs](https://roots.io/trellis/docs) and followed them (if applicable) - [x] This is not a personal support request that should be posted on the [Roots Discourse](https://discourse.roots.io/c/trellis) forums --- **What is the current behavior?** When using a multisite configuration, the deployment fails during the ansible task `WordPress Installed?`. This is in turn caused by the `wp core is-installed` command exiting with non zero status because of a `ConstantAlreadyDefinedException`. This is related to roots/bedrock#380 and roots/docs#168. **What is the expected or desired behavior?** The deployment completes without error. The `wp core is-installed` command exits with 0. --- **Please provide steps to reproduce, including full log output:** 1. Configure the multisite installation as suggested by [the docs](https://roots.io/trellis/docs/multisite/), using [roots/wp-config](https://github.com/roots/wp-config). Note that the `MULTISITE` and `SUBDOMAIN_INSTALL` redefinition is now prevented, by design, with the usage of the new configuration model. 2. Run the deployment script: ``` $: ./bin/deploy.sh staging *** TASK [deploy : WordPress Installed?] *********************************************************************************************** System info: Ansible 2.6.4; Linux Trellis version (per changelog): "Allow customizing Nginx `worker_connections`" --------------------------------------------------- non-zero return code fatal: [***.***.***.***]: FAILED! => {"changed": false, "cmd": ["wp", "core", "is-installed", "--skip-plugins", "--skip-themes", "--require=/srv/www/***/shared/tmp_multisite_constants.php"], "delta": "0:00:00.367497", "end": "2018-10-26 17:40:16.192522", "failed_when_result": true, "rc": 255, "start": "2018-10-26 17:40:15.825025", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []} ``` 3. Logging into the target host and executing the command manually with the `--debug` flag yields the following output: ``` $: wp core is-installed --skip-plugins --skip-themes --require=/srv/www/***/shared/tmp_multisite_constants.php --debug Debug (bootstrap): Required file from config: /srv/www/***/shared/tmp_multisite_constants.php (0.01s) Debug (bootstrap): No readable global config found (0.051s) Debug (bootstrap): Using project config: /srv/www/***/releases/20181026173903/wp-cli.yml (0.051s) Debug (bootstrap): argv: /usr/bin/wp core is-installed --skip-plugins --skip-themes --require=/srv/www/***/shared/tmp_multisite_constants.php --debug (0.051s) Debug (bootstrap): ABSPATH defined: /srv/www/***/releases/20181026173903/web/wp/ (0.051s) Debug (bootstrap): Begin WordPress load (0.052s) Debug (bootstrap): wp-config.php path: /srv/www/***/releases/20181026173903/web/wp-config.php (0.052s) PHP Fatal error: Uncaught Roots\WPConfig\Exceptions\ConstantAlreadyDefinedException: Aborted trying to redefine constant 'MULTISITE'. `define('MULTISITE', ...)` has already been occurred elsewhere. in /srv/www/***/releases/20181026173903/vendor/roots/wp-config/src/Config.php:106 Stack trace: #0 /srv/www/***/releases/20181026173903/vendor/roots/wp-config/src/Config.php(26): Roots\WPConfig\Config::defined('MULTISITE') #1 /srv/www/***/releases/20181026173903/config/application.php(119): Roots\WPConfig\Config::define('MULTISITE', true) #2 phar:///usr/bin/wp/php/WP_CLI/Runner.php(1145) : eval()'d code(7): require_once('/srv/www/***...') #3 phar:///usr/bin/wp/php/WP_CLI/Runner.php(1145): eval() #4 phar:///usr/bin/wp/php/WP_CLI/Runner.php(1107): WP_CLI\Runner->load_wordpress() #5 phar:///usr/bin/wp/php/WP_CLI/Bootstrap/LaunchRunner.php(23): WP_CLI\Runner->start() #6 phar:///usr/bin/wp/php/bootstrap.php(75): WP_CLI\Bootstrap\LaunchRunner->process(Object(WP_CLI\Bootstrap\B in /srv/www/***/releases/20181026173903/vendor/roots/wp-config/src/Config.php on line 106 ``` --- This is caused by the explicit and one-time requirement of the file `roles/deploy/files/tmp_multisite_constants.php`, which defines constant that may be re-defined later by the application config. --- **Possible solutions:** Either of the following: - rethink the usage of `tmp_multisite_constants.php` (the purpose of which is unclear to me at the moment) so that it avoids constant definitions. This is arguably the most desirable approach, but I'm not able to assess exactly what this would entail and how to proceed, because I don't even know why this file is being required in the first place during the affected Ansible task. Furthermore, I'm not sure using `Roots\WPConfig\Config` inside this file is feasible, because the autoloader has not been loaded yet, and I'm not clear when `apply` should then happen. Maybe this suggests a design oversight in the new configuration model. Also, IMO sneaking in a bunch of constants in such a non-transparent way is not a very sensible thing to do in general. - Add an `if defined` block to the multisite configuration docs. This would also require to explain accordingly the presence and purpose of `tmp_multisite_constants.php`, which as previously mentioned I am unable to do. IMO it also grants a kind of "wtf" moment to trellis users, which makes this solution undesirable. - revert roots/docs#168; this is arguably a worse approach, because people may end up using the new configuration model regardless of what the docs suggests, since that model is encouraged in the first place by Bedrock docs, and keeping any usage of the bare `define` function would make docs inconsistent.

Related GitHub PR:

github.com/roots/trellis

Don't load plugins when running `wp core is-installed`

roots:master ← roots:fix-wp_installed

opened 09:46PM - 25 Mar 17 UTC

QWp6t

+4 -1

Certain plugins return early or die() if they're activated but the site isn't mu…ltisite. To resolve this, we can use `--skip-plugins`, but that doesn't unload mu-plugins. To address the latter, we can `define('WPMU_PLUGIN_DIR', null)`, which causes WordPress to not load any mu-plugins. Since some themes rely on mu-plugins, we can use `define('WP_USE_THEMES', false)` to minimize the number of theme-related events that are fired. But since that doesn't fully prevent the theme from being loaded, we also use `--skip-themes`. All of this combined should hopefully minimize the amount of WordPress that gets loaded to the point where we don't have any fatal errors arising from forcing a multisite installation to be loaded as non-multisite. We think this should work for _**most**_ situations. Another solution we've come up with is using a shell script to sniff out the error message returned by wp-cli when it's supposed to be multisite setup but WordPress isn't installed, something like this: ```yaml - name: WordPress Installed? shell: | WP_INSTALLED=$(wp core is-installed {{ project.multisite.enabled | default(false) | ternary('--network', '') }} 2>&1) [ -z "${WP_INSTALLED}" ] && exit 0 if [[ ! $WP_INSTALLED =~ "WordPress database error Table '{{ site_env.db_name }}.wp_blogs' doesn't exist" ]]; then echo $WP_INSTALLED 1>&2 fi exit 1 args: chdir: "{{ deploy_helper.current_path }}" executable: /bin/bash register: wp_installed changed_when: false failed_when: wp_installed.stderr != "" ``` But that will also fail if the error message is in a different language (not sure if wp-cli translates its error messages) or if the database prefix isn't `wp_`. So if we go this other route, it would also come with some potential pitfalls. Input from the community is welcome.

SteelWagstaff · May 27, 2022, 7:11pm

Thanks for your attention to this and extra details (I filed Bug: Autodeploy failures with WordPress 6.0 · Issue #1385 · roots/trellis · GitHub). We have the very same question as this point. Don’t know the answer yet – don’t find anything immediately obvious in developer notes or field guide, nor anything in quick comparison between releases: https://github.com/WordPress/WordPress/compare/6.0...5.9.3. Have asked about this in the #core-multisite WordPress Slack channel to see if someone there might be more knowledgeable: https://wordpress.slack.com/archives/C03BVB47S/p1653679302844629.

SteelWagstaff · May 27, 2022, 8:02pm

JJJ from WordPress community replied to ask

Is it possible that a PHP version running inside of the Trellis deployer was bumped? Newer versions of PHP are increasing error handling severity when “invalid” data types are passed through.

See: PHP: strpos - Manual

Not sure how to investigate this idea …

strarsis · May 27, 2022, 10:46pm

The Ansible check (“smoke test” basically) during deployment that uses the wp core is-installed [...] command will fail with a non-empty stderr:

github.com

roots/trellis/blob/f1f8ff1c7d10dba602916aff4c04d0132c524da3/roles/deploy/hooks/finalize-before.yml#L13


      
            copy:
              src: "tmp_multisite_constants.php"
              dest: "{{ deploy_helper.shared_path }}/tmp_multisite_constants.php"
          
          - name: WordPress Installed?
            command: wp core is-installed --skip-plugins --skip-themes --require={{ deploy_helper.shared_path }}/tmp_multisite_constants.php
            args:
              chdir: "{{ deploy_helper.new_release_path }}"
            register: wp_installed
            changed_when: false
            failed_when: wp_installed.stderr | default("") != "" or wp_installed.rc > 1
          
          - name: Get WP theme template and stylesheet roots
            shell: >
              {% if not project.multisite.enabled | default(false) %}
                wp option get {{ item }} --skip-plugins --skip-themes
              {% else %}
                wp site list --field=url | xargs -I {} bash -c 'export url="{}"; echo -n "$url " && wp option get {{ item }} --skip-plugins --skip-themes --url=$url || echo'
              {% endif %}
            args:
              chdir: "{{ deploy_helper.current_path }}"

The tmp_multisite_constants.php required by the wp command also raises the PHP error reporting level so that everything (including PHP warnings) except PHP notices are reported:

error_reporting(E_ALL & ~E_NOTICE);
[...]

So the strpos non-empty needle PHP warning will make stderr from wp non-empty and the Ansible check (and the deployment task) fails.

strarsis · June 1, 2022, 7:58pm

@SteelWagstaff, @Twansparant, @evankford, @nickkeenan, @jokanane, @masoninthesis:
Fixed in latest Trellis: Split `is-installed` check into a non-multisite and a mulitsite specific one by strarsis · Pull Request #1388 · roots/trellis · GitHub

nickkeenan · June 2, 2022, 5:00pm

After applying Pull Request 1388 for this issue, the first deploy to upgrade to roots/wordpress-no-content works like a charm. (This is upgrading an existing droplet, not a fresh install). However, subsequent deploys are failing for me at the WordPress Installed (non-multisite)? task:

non-zero return code
Error: This does not seem to be a WordPress installation.
Pass --path=`path/to/wordpress` or run `wp core download`.
fatal: [104.236.12.218]: FAILED! => {
    "changed": false,
    "cmd": [
        "wp",
        "core",
        "is-installed",
        "--skip-plugins",
        "--skip-themes"
    ],
    "delta": "0:00:00.470767",
    "end": "2022-06-02 16:12:22.850612",
    "failed_when_result": true,
    "invocation": {
        "module_args": {
            "_raw_params": "wp core is-installed --skip-plugins --skip-themes",
            "_uses_shell": false,
            "argv": null,
            "chdir": "/srv/www/{site_var}/releases/20220602161041",
            "creates": null,
            "executable": null,
            "removes": null,
            "stdin": null,
            "stdin_add_newline": true,
            "strip_empty_ends": true,
            "warn": true
        }
    },
    "rc": 1,
    "start": "2022-06-02 16:12:22.379845",
    "stderr_lines": [
        "Error: This does not seem to be a WordPress installation.",
        "Pass --path=`path/to/wordpress` or run `wp core download`."
    ],
    "stdout": "",
    "stdout_lines": []
}

Looking at the release directory after the failure, the wp directory is not present despite the composer task executing properly. (it is present in the /current release, the first deploy after applying this patch).

Anyone else having this issue on subsequent deploys?

strarsis · June 2, 2022, 6:47pm

Subsequent deploys worked fine for me with this PR.

When the wp directory is missing, composer failed to install WordPress core?
Do you have the same issue with a pre WordPress 6.x version - but with this PR in place?

Twansparant · June 2, 2022, 7:05pm

Yeah, for me as well?
Instead of roots/wordpress-no-content, can you try roots/wordpress?

Mike_Wheeler · June 2, 2022, 7:10pm

The fix for me is commenting out “define(‘WPMU_PLUGIN_DIR’, null);” from trellis/roles/deploy/files/tmp_multisite_constants.php

strarsis · June 2, 2022, 7:14pm

@Mike_Wheeler: This was one of three different variants

Add exception for the PHP `strpos()` empty needle warning by strarsis · Pull Request #1387 · roots/trellis · GitHub
Remove `WPMU_PLUGIN_DIR` constant to `null` in `tmp_multisite_constants.php` by strarsis · Pull Request #1386 · roots/trellis · GitHub
Split `is-installed` check into a non-multisite and a mulitsite specific one by strarsis · Pull Request #1388 · roots/trellis · GitHub

as a possible fix.

The now merged-in PR is the fix that separates the check for non-multisites and also ignores this particular PHP warning.

nickkeenan · June 2, 2022, 7:15pm

You were right on, @Twansparant, my issue is that I was using:

"roots/wordpress-no-content": "^6.0",

instead of

"roots/wordpress": "^6.0",

The first doesn’t require the roots/wordpress-core-installer dependency so my first deploy seems to have worked but subsequent deploys were missing that dependency.

Adjusting to “roots/wordpress”: “^6.0” makes subsequent deploys work, I think I got my wires crossed with the new composer packages.

strarsis · June 2, 2022, 7:15pm

~~If there are issues with deploying the new roots/wordpress-no-content (which is awesome by the way), it may not be related to this PR, but caused by another issue.~~
Edit: roots/wordpress starting with 6.0 should already omit the wp-content/ directory (see below).

strarsis · June 2, 2022, 7:56pm

~~"roots/wordpress-no-content": "6.0" also deploys fine for me with the new PR.~~
Edit: Indeed, it doesn’t really work after subsequent deploys. But it may not be necessary as roots/wordpress doesn’t contain wp-content/ anyway anymore starting with version 6.0 (see below).

nickkeenan · June 2, 2022, 8:07pm

Likely not, it’s far out of date. Will be doing a more involved droplet-replacing update this summer.