Roots Discourse

Wordpress Installed? failing on wp 5.6 missing web/wp/wp- includes/class-wp-application-passwords.php

Just updated WP to 5.6.2 with composer and locally, I have web/wp/wp- includes/class-wp-application-passwords.php, but when I deploy, it’s not there:

-rw-r--r--  1 web www-data   2299 Feb 25 05:11 class-walker-page-dropdown.php
-rw-r--r--  1 web www-data   7043 Feb 25 05:11 class-walker-page.php
-rw-r--r--  1 web www-data  16993 Feb 25 05:11 class-wp-admin-bar.php
-rw-r--r--  1 web www-data   5240 Feb 25 05:11 class-wp-ajax-response.php
-rw-r--r--  1 web www-data   4473 Feb 25 05:11 class-wp-block-list.php
-rw-r--r--  1 web www-data  15215 Feb 25 05:11 class-wp-block-parser.php

So the Wordpress Installed? task fails:

"Fatal error: require(): Failed opening required \ 
'/srv/www/example.com/releases/20210225053455/web/wp/wp-includes/class-wp-application-passwords.php' \
(include_path='.:/usr/share/php') in /srv/www/example.com/releases/20210225053455/web/wp/wp-settings.php on line \
239", "Error: There has been a critical error on this website.Learn more about debugging in WordPress. There has been a critical error on this website."], \ 
"stdout": "", "stdout_lines": []}

All prior tasks succeeded, so I’m quite confounded.

I can downgrade to lower than wp v5.6.0, where that file doesn’t exist, and the deploy succeeds.

And idea what’s going on?

Remote server was running Composer v1 and locally running v2.

Updating Composer on the remote (composer self-update --2) solved the problem.

Hmmm. Now, migrating to the production server I’m getting a new “missing” file fatal error:

PHP Fatal error:  require_once(): Failed opening required
'/srv/www/example.com/releases/20210227004748/web/wp/wp-
includes/cache-compat.php' (include_path='.:/usr/share/php') in
/srv/www/example.com/releases/20210227004748/web/wp/wp-
includes/load.php on line 673

That file exists on previous (recent) releases as well as locally, but not on the “current” (not) release.

wp core is-installed --skip-plugins --skip-themes, of course, fails within the most recent (non-current) release directory.

What is going on here? How is the wp codebase getting to the server, via Composer, right?

Within latest release, composer.json: "roots/wordpress": "5.6.2".

I ran composer update as well as composer install within the same directory, but still (on the production server) getting fatal php error on:

wp core is-installed --skip-plugins --skip-themes

I hope someone can help me see what’s going on here.

Is it reasonable to rebuild production (after taking a backup of the database and uploads) and simply reprovisioning and redeploying it?

It would involve some downtime for the site, but only 10ish minutes if you do it right.

You mean on the same droplet or an a brand new one? Does it look like significant corruption has occurred?

Thanks.

No, but I’ve had a few cases where the transition from Composer 1 to Composer 2 was just so janky that it was easier to rebuild and redeploy than to try to troubleshoot.

Wouldn’t it be easiest to just build it from scratch on a new droplet and change the IP?

Sure, you IMHO should even strive for being able to redeploy a fresh container whenever you need/want:

2 Likes

That’s a great article, man. Thanks.

So, I’m getting the same error (above) about the missing /site/web/wp/wp-includes/cache -compat.php file on a freshly provisioned server. It’s here locally.

Running Composer v2.0.11 both locally and remotely.

"require": {
    "php": ">=7.1",
    "composer/installers": "^1.8",
    "roots/wordpress": "5.6.2",
    "roots/wp-config": "1.0.0",
    "roots/wp-password-bcrypt": "1.0.0",
    "vlucas/phpdotenv": "^4.1.8",
    "oscarotero/env": "^2.1",
  },

Ubuntu v20, though don’t know if that would be relevant.

Ansible 2.9.13; Darwin

Removed all of my plugins, including the additional prs4 autoload from composer file and now getting this:

non-zero return code
PHP Fatal error:  Uncaught Error: Interface
'Dotenv\Repository\Adapter\AdapterInterface' not found in /srv/www/ellipticas
tudios.com/releases/20210228022415/vendor/vlucas/phpdotenv/src/Repository/Ada
pter/ServerConstAdapter.php:10
Stack trace: etc... 

On the server: PHP 7.4.15

Locally using this version of php:

../Cellar/valet-php@7.2/7.2.34_3/bin/php

Just tried to install php v7.4 locally with brew, and it installed v8.0.2.

Could it help to update the composer.json with the latest one?

Nope. I’m going to see what happens with a fresh trellis init, fresh droplet latest composer.json.

My system trellis, composer, php are happy with a fresh trellis new installation, however in this repo, on a fresh vagrant up, with just native (current) Bedrock composer settings, I’m getting Error: Error establishing a database connection.

Ssh in, I can access the DB with DB_USER, DB_PASSWORD defined in site/.env and group_vars/development/vault.yml, but wp-cli gives the same error.

Wondering if this could be an error with one of the following two deps:

    "vlucas/phpdotenv": "^5.3",
    "oscarotero/env": "^2.1",

I have (cleared out vendor, delete composer.lock, etc repeatedly) reinstalled all recently and am using php v7.4 fairly up-to-date Trellis codebase.

What is the next step in debugging this? Do I write a php script utilizing getenv to figure out if it’s finding the env configs? Could my site/config have broken? I recently made some small modifications to it (just with WP constants).

Yes, you should first rule out that the site uses wrong/default credentials.
Then you should find out what the exact reason for the connection error is: IP not allowed? Connection timeout? Unexisting database? Incorrect username/password?

Is there any place other than in site/.env that they would be being pulled from?

config/environment([environment].php also allows to set variables/environment vaiables.

Finally narrowing it down and I think that my psr4 is (probably wrong, somehow and) conflicting with vlucas/phpdotenv:

  "autoload": {
    "psr-4": {
        "My_Plugin_Namespace\\Backend\\": "web/app/plugins/my-plugin-directory/backend",
        "My_Plugin_Namespace\\Frontend\\": "web/app/plugins/my-plugin-directory/frontend",
        "My_Plugin_Namespace\\Ajax\\": "web/app/plugins/my-plugin-directory/ajax"
    }
},

Because when it’s in the composer.json I’m getting, first this error:

'Dotenv\Repository\Adapter\AdapterInterface' not found

Then I run trellis up again and get this one:

Error: Error establishing a database connection..,

When it’s not there it provisions/deploys (locally) correctly.

So it’s not really a Bedrock issue, but your insight would be much appreciated.

Actually it doesn’t seem to be related to my psr4 config.

Some of the files from vlucas/phpdotenv are missing on the remote server!

It only has:

...vlucas/phpdotenv/src/Repository/Adapter/$ ls
ApacheAdapter.php  
ArrayAdapter.php  
EnvConstAdapter.php  
PutenvAdapter.php  
ReaderInterface.php  
ServerConstAdapter.php  
WriterInterface.php

Locally they’re all here:

AdapterInterface.php    EnvConstAdapter.php     MultiReader.php         ReaderInterface.php     WriterInterface.php
ApacheAdapter.php       GuardedWriter.php       MultiWriter.php         ReplacingWriter.php
ArrayAdapter.php        ImmutableWriter.php     PutenvAdapter.php       ServerConstAdapter.php

Additionally, in the output of TASK [deploy : Install Composer dependencies] TASK [deploy : Install Composer dependencies] changed: [104.131.179.125] => {"changed": true..., verbose, vlucas nor dotenv are present.

When I ran composer update on the server, it prompted me to generate a github token, then properly installed all the the dependencies (all of the Dotenv files present).

On a brand new droplet, freshly provisioned.

(“NEW” Premium Intel with NVMe SSD would make a difference)

Run composer diagnose for both web and admin get:

Checking pubkeys: FAIL
Missing pubkey for tags verification
Missing pubkey for dev verification
Run composer self-update --update-keys to set them up

Run the Self Update and same error.

Replace entire site content with vanilla bedrock master from git.

Still same error.

What on earth is going on here?

You probably have already tried this, but just in case…
Have you also tried to invoke
composer self-update --update-keys
(with --update-keys)?

But is this composer error the underlying issue for the missing dependencies?

1 Like