WordPress 6.0 update deploy failed

trellis
,
16

@Mike_Wheeler: This was one of three different variants

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.

1 Like
17

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.

2 Likes
18

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).

1 Like
20

"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).

21

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

22

The roots/wordpress package starting with 6.0 should already omit the themes:

  • With the release of WordPress 6.0 roots/wordpress will change to serve only WordPress–no themes.

The roots/wordpress-no-content package is indeed just a bare-bones composer package that downloads the no-content WordPress ZIP from WordPress. It doesn’t install on its own on a Bedrock site, the roots/wordpress-core-installer package is also required for actually installing the raw files.
You could require the roots/wordpress-no-content and roots/wordpress-core-installer packages yourself in a Bedrock site, but this isn’t necessary as this is already handled by the roots/wordpress meta-package: The roots/wordpress package since version 6.0 indeed requires both, the roots/wordpress-no-content package and the roots/wordpress-core-installer package:

So for a WordPress core without the default themes and plugins (e.g. “Hello Dolly”), just use the roots/wordpress package starting with 6.0.

https://discourse.roots.io/t/wordpress-6-0-released-updates-to-our-wordpress-composer-package-are-now-live/23223

5 Likes
23

I’ve got no further comments really but can confirm the exact same behaviour as others have reported in this thread; using roots/wordpress together with changes in @strarsis PR #1388 works for now.

24

Thanks, that did the trick :slight_smile:

25

Summoning @tGeorgel, @Mike_Wheeler:
The deployment task for multisite sites now doesn’t use temporary PHP constants anymore and
should work now in any case (initial multisite site deployment, already configured multisite site, with WordPress < 6.0 and with WordPress ≥ 6.0): Exempt from `is-installed` check the DB error dump PHP warning for not yet set up multisite sites by strarsis · Pull Request #1391 · roots/trellis · GitHub

2 Likes
26

Just a quick note for people like me using the roles trellis_flush_rewrite_rules_during_deploy and/or trellis-backup-during-deploy:

Both of them mirrored the “WP installed?”-steps from before and will throw the same errors when invoked…

They have been updated to reflect the current changes (thanks @codepuncher !) and you may need to manually update and install these in your galaxy.yml.

And a big thanks to @strarsis for the work done on this!

2 Likes
27

Hm, could common tasks like WP Installed? be re-used by Trellis Roles from Trellis core?
This reduces code duplication and ensure that always one and most recent task is used.

1 Like
28

Please pardon me for adding to a closed thread.

I’m hitting a problem in a previous Trellis droplet I’ve rebased over latest Trellis codebase.

On initial deploy, WordPress Installed (non-multisite) fails.

On the server itself, where I would expect wp core --is-installed to return, “Error: The site you have requested is not installed.”, it returns nothing.

Wp is installed: wp --info returns:

OS:	Linux 5.4.0-122-generic #138-Ubuntu SMP Wed Jun 22 15:00:31 UTC 2022 x86_64
Shell:	/bin/bash
PHP binary:	/usr/bin/php8.0
PHP version:	8.0.21
php.ini used:	/etc/php/8.0/cli/php.ini
MySQL binary:	/usr/bin/mysql
MySQL version:	mysql  Ver 15.1 Distrib 10.5.16-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
SQL modes:
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:	/srv/www/example.com/releases/20220803202003
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:	/srv/www/example.com/releases/20220803202003/wp-cli.yml
WP-CLI version:	2.6.0

Provisioning seems to have run successfully. What am I missing here? Did I miss, or neglect to remove a file or variable?

FYI:

non-zero return code
fatal: [143.198.161.xxx]: FAILED! => {
    "changed": false,
    "cmd": [
        "wp",
        "core",
        "is-installed",
        "--skip-plugins",
        "--skip-themes"
    ],
    "delta": "0:00:00.302903",
    "end": "2022-08-03 21:15:44.909393",
    "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/example.com/releases/20220803211520",
            "creates": null,
            "executable": null,
            "removes": null,
            "stdin": null,
            "stdin_add_newline": true,
            "strip_empty_ends": true,
            "warn": false
        }
    },
    "rc": 255,
    "start": "2022-08-03 21:15:44.606490",
    "stderr": "",
    "stderr_lines": [],
    "stdout": "",
    "stdout_lines": []
}
29

Exit code 255 indicates a fatal PHP error (the exit code is from the PHP interpreter itself by the way). Can you check the PHP error logs (site-specific and system-wide) to find out what exactly caused it? It may be some plugin or theme.

1 Like
30

Thanks, starsis. This is embarrassing, but, where are those php error logs? I’m only finding:

/srv/www/example.com/logs/error.log (empty)
/srv/www/example.com/logs/access.log (empty)
/var/log/php8.0-fpm.log
[03-Aug-2022 20:42:38] NOTICE: fpm is running, pid 49585
[03-Aug-2022 20:42:38] NOTICE: ready to handle connections
[03-Aug-2022 20:42:38] NOTICE: systemd monitor interval set to 10000ms
[03-Aug-2022 20:43:42] NOTICE: Reloading in progress ...
[03-Aug-2022 20:43:42] NOTICE: reloading: execvp("/usr/sbin/php-fpm8.0", {"/usr/sbin/php-fpm8.0", "--nodaemonize", "--fpm-config", "/etc/php/8.0/fpm/php-fpm.conf"})
[03-Aug-2022 20:43:42] NOTICE: using inherited socket fd=7, "/run/php/php8.0-fpm.sock"
[03-Aug-2022 20:43:42] NOTICE: using inherited socket fd=7, "/run/php/php8.0-fpm.sock"
[03-Aug-2022 20:43:42] NOTICE: fpm is running, pid 49585
[03-Aug-2022 20:43:42] NOTICE: ready to handle connections
[03-Aug-2022 20:43:42] NOTICE: systemd monitor interval set to 10000ms
/var/log/nginx/access.log
/var/log/nginx/error.log (empty)

And some that don’t seem relevant:

/var/log/mail.log
/var/log/dpkg.log
/var/log/kern.log
/var/log/cloud-init-output.log
/var/log/cloud-init.log
/var/log/fontconfig.log
/var/log/ubuntu-advantage-timer.log
/var/log/alternatives.log
/var/log/auth.log
/var/log/unattended-upgrades/unattended-upgrades.log
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log
/var/log/unattended-upgrades/unattended-upgrades-shutdown.log
/var/log/php8.1-fpm.log
/var/log/apt/history.log
/var/log/apt/term.log
/var/log/landscape/sysinfo.log
/var/log/fail2ban.log
/var/log/droplet-agent.update.log
/sys/kernel/tracing/error_log
/sys/kernel/debug/tracing/error_log
31

Can you turn PHP error reporting directly on when using the PHP CLI?

php -d display_errors=on $(which wp)

(Note: (which wp prints the path to the wp binary and $() interpolates it so the php interpreter binary runs it, allowing to pass additional options as for force-enabling (hopefully) the PHP error reporting.)

Invoke this command inside the current/release directory of the troubling site on the server.
Does it show the PHP fatal error?

32

Well, there is no “current” directory as the deploy didn’t get that far. Running as web user. No output. I’m going to try deploying a basic Bedrock site…

Got further!

Finalize the deploy...
rmtree failed: [Errno 13] Permission denied: 'views-for-wpforms'
33

rmtree failed is related to a Trellis deploy issue:

34

@mZoo: Were you able to fix/find out the reason for this issue?

35

Thanks a lot for asking man. Not yet. I spun up a local vagrant box to see if there were php errors and there aren’t (though a bunch of depreciation warnings that pop-up with current WP codebase and php 8.1).

Still getting the 255 error.

Running any php -d display_errors=on $(which wp) command returns nothing. Same after removing all plugins and themes from web/app directories.

36

Man this just keeps on going. Provisioned a new droplet and after three or four deploys of wpackagist plugin composer failures, back to the original problem from a few days ago:

non-zero return code
sudo: a terminal is required to read the password; either use the -S option
to read from standard input or configure an askpass helper
fatal: [67.205.178.xxx]: FAILED! => {
    "changed": true,
    "cmd": "sudo service php8.0-fpm reload",
    "delta": "0:00:00.013650",
    "end": "2022-08-05 03:40:43.968472",
    "invocation": {
        "module_args": {
            "_raw_params": "sudo service php8.0-fpm reload",
            "_uses_shell": true,
            "argv": null,
            "chdir": null,
            "creates": null,
            "executable": null,
            "removes": null,
            "stdin": null,
            "stdin_add_newline": true,
            "strip_empty_ends": true,
            "warn": false
        }
    },
    "rc": 1,
    "start": "2022-08-05 03:40:43.954822",
    "stderr_lines": [
        "sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper"
    ],
    "stdout": "",
    "stdout_lines": []
}

And on the server:

root@...:/home/admin# cat /etc/sudoers.d/web-services
# Ansible managed

web ALL=(root) NOPASSWD: /usr/sbin/service.php8.0-fmp.*

And

root@/home/admin# php --version
PHP 8.0.21 (cli) (built: Aug  1 2022 07:40:52) ( NTS )

and

web@...:/home/admin$ sudo service php8.0-fpm reload
[sudo] password for web:

Additionally

root@:/home/admin# ls -l $(which php)
lrwxrwxrwx 1 root root 21 Aug  5 01:15 /usr/bin/php -> /etc/alternatives/php
root@:/home/admin# ls -l /etc/alternatives/ | grep php
lrwxrwxrwx 1 root root  15 Aug  5 01:15 php -> /usr/bin/php8.0
lrwxrwxrwx 1 root root  22 Aug  5 01:16 php-config -> /usr/bin/php-config8.0
lrwxrwxrwx 1 root root  38 Aug  5 01:16 php-config.1.gz -> /usr/share/man/man1/php-config8.0.1.gz
lrwxrwxrwx 1 root root  24 Aug  5 01:16 php-fpm.sock -> /run/php/php8.0-fpm.sock
lrwxrwxrwx 1 root root  31 Aug  5 01:15 php.1.gz -> /usr/share/man/man1/php8.0.1.gz
lrwxrwxrwx 1 root root  18 Aug  5 01:16 phpize -> /usr/bin/phpize8.0
lrwxrwxrwx 1 root root  34 Aug  5 01:16 phpize.1.gz -> /usr/share/man/man1/phpize8.0.1.gz

Migrating this back to my original post about reload of php-fmp.

1 Like