Deployment error: Wordpress Installed?


I’ve been pulling my hairs out trying to set up a staging environment, and I keep getting stuck on this error when running the deploy command:

TASK [deploy : WordPress Installed?] ******************************************* fatal: [XXX.XXX.XX.XX]: FAILED! => {"changed": false, "cmd": ["wp", "core", "is-installed"], "delta": "0:00:00.111484", "end": "2016-03-24 21:40:14.305099", "failed": true, "failed_when_result": true, "rc": 1, "start": "2016-03-24 21:40:14.193615", "stderr": "Error: Error establishing a database connection", "stdout": "", "stdout_lines": [], "warnings": []}

I’m currently running the latest version of WP-CLI (0.23.0) on my server. I’m running a DO droplet with Ubuntu 14.04.4.

Provisioning the server worked successfully, but deploying doesn’t. I’ve read that ‘deploying’ shouldn’t error because Wordpress isn’t installed.

Do I need to install Wordpress on my server for me to deploy successfully the first time? If so, where would I need to install it? Assuming I am running a LEMP stack on my DO droplet.

This task is failing for another reason: Error establishing a database connection

Meaning WP-CLI can’t even check if WP is installed or not because it can’t connect to the DB.

The provisioning process went fine without errors? You can do some manual debugging to make sure MariaDB is running, you can connect and that the WP user exists and matches up with your config:

I agree with @swalkinshaw – the tipoff is Error establishing a database connection

@dangofett I can reproduce this error if I set mysql_remote_database: true in group_vars/all/database.yml. Unless you’re planning to set up a separate server for your DB I’m guessing you will want the default of false, which will host the DB on the same server as your web files.

If that sounds right, try setting mysql_remote_database: false, then run

ansible-playbook server.yml -e env=staging --tags mariadb,wordpress

Then try your deploy again.

Thanks for your responses!

@fullyint My setting for mysql_remote_database was actually set to false. I ran the command line successfully, but still getting the same deploy issue. I’m not sure where I’ve gone wrong, as I have followed the trellis guideline pretty strictly - and even set up the DO droplet as required.

ansible-playbook server.yml -e env=staging still runs successfully.

@swalkinshaw any advice or directions on how I go about debugging or testing the connection to MariaDB manually? I’m fairly new to ansible.

Oh I didn’t mean debug via Ansible. Just manually via SSH.

  1. SSH into server
  2. Run mysql -u root -p and type in the root MySQL you have set
  3. See what databases exist
  4. See what users exist
  5. Try connecting as the WP site user: mysql -u example_dbuser -p example_prod

Hopefully some of this should provide some clues as to what’s not working.

You’ll also need to verify that your .env file looks okay. It’s located at /srv/www/sitename/current/.env

That’s where the database credentials are located that WP uses to connect.

1 Like

Thanks again for the help.

I’ve run through the commands and I get the following information:

  • staging database exists
  • the database admin I created exists in users along with a bunch of root users
  • I can connect to the staging db with the staging user using the command line mentioned in 5.

I’ve also checked the .env file, and the file looks okay and matches the values I set in the group_vars for staging.

From the looks of it… it should theoretically work.

after digging further into my staging database, show tables; is returning an empty set. Could this be the main culprit as to why I can’t establish a connection with the database?

That’s actually expected if you haven’t installed WP yet (ie: your first deploy). You should still be able to connect to a database without tables.

If this is a staging server that isn’t fully working yet, can’t you just reset/re-create the droplet and start again with a fresh provision.

1 Like

I’ve actually recreated the droplet, prior to opening this thread and still came across the same error.
Another thing that I might note is that I don’t have a actual domain name, so I am just using the ip address of the droplet in place of the site name and IP.

Would this have any effect on the connection?

Sorry, I’m plucking at straws at the moment because I really don’t know what else I might of done differently than to what is in the example server.

I appreciate your help nevertheless.

I don’t think that would affect MySQL since it’s just using localhost. However it might have other side effects.

Did you previously create a development Vagrant server before this? Was it all working?

Yup, the Vagrant server works fine and never had a problem setting it up.

I might suggest updating to latest Trellis. I just did a lot of improvements to make the configs simpler. I don’t really know if this will fix your problem but it should reduce the chances of a config issue since I’ve eliminated/automated a lot of the options.

Beyond that all I can say is that the information to debug/fix this problem is on the server itself. It may be some bug in Trellis but without any confirmation as to what actually went wrong and how to fix it, there’s only so much I can do.

1 Like

I’ve been struggling with this same basic issue for about a day now myself. Something is def conflicting.

I’m using a remote database server, which I have been using without an issue with trellis and bedrock for awhile now. So this means the issue is happening on local sql and remote sql setups. I have tried deploying to an existing known good production server which has MariaDB installed via trellis just is not in use all the sites use the external db server. Also I took the current master branch of trellis and setup another server which from the first provisioning I set the remote db variable so the second server I have been debugging on is using the current master from trellis and bedrock with no MariaDB ever installed. Both get the same error.

I’m pretty sure it’s an issue with a dependency maybe wp-cli, phpdotenv, or the composer autoloader not trellis because when I SSH into the server and run wp db (any command) it wants to act like db_host is set to localhost no matter what. I have tried hard coding all the db settings in application.php with the settings from the external db server. Still acts like it’s set to localhost (this is when I really started questioning if I was actually asleep and dreaming this problem). Then I thought maybe because you set the env variable defaults in the new trellis in group_vars/all/main.yml maybe somehow this was overriding things. So I removed those and still same situation. I thought maybe the simlinks were getting confused so I mv the actual release folder into the site root and renamed it current after removing the simlink. Still same issue.

Here is the --debug from the manual wp cli commands I was running to try and get it to recognize the external db server.

Debug: No readable global config found (0.005s)
Debug: Using project config: /srv/www/ (0.006s)
Debug: No package autoload found to load. (0.008s)
Debug: ABSPATH defined: /srv/www/ (0.008s)
Debug: Running command: db create (0.01s)
sh: 1: mysql: not found

This is with the db_host physically hard coded into application.php bypassing the env() altogether and putting in the IP of the database server (which I have done hundreds of times successfully), yet it wants to create a DB on localhost where MariaDB is not installed. If I run the same manual wp-cli on my production server with the unused MariaDB it wants to create the database on localhost as well just errors out because the db_name and db_password don’t exist for that site. Then I tried hardcoding in the root user and original root pw setup it still won’t go. Only way it works is to replace wp-config.php with an actual completely hardcoded wp-config file bypassing everything and going old-school based off

All my existing sites deployed on the same exact server work completely fine so I’m thinking new dependency which got updated in my bedrock setup when I newly deploy and it runs composer install on the server so vlucas/phpdotenv, oscarotero/env, or something with composer autoloader.

Sorry for the rant haha, but I figure the more I say the more likely someone may figure out what isn’t playing nicely with the variables today.

1 Like

@RiFi2k not a rant, some good debugging information :slightly_smiling:

You mentioned this fails with any wp db command. I’m wondering if you just tried to hit the site in a browser as usual and if it worked?

If so, that would definitely point to a problem with WP-CLI. If not, then you’re right it could be something with Composer or the two Env packages.

I would get the good old Database Error white screen, so it was trying its heart out to work just was stuck with some bad variables

@swalkinshaw the update with Trellis seemed to fixed it. I can get through the deployment without DB errors now. Thank you so much for your support - looking forward to working with the roots tools from this point on.

@RiFi2k I hope the update solves your issue too. :slightly_smiling:

1 Like

Unfortunately I’m a freakball and I was working when they were making commits to trellis yesterday so I was real time merging them into my working setup so everything I explained was on the current commit as of yesterday.

I have my couple trellis set ups all running on a “ansible-controller” dedicated instance. So I remote into the instance with an IDE and use it to provision / rsync / make edits to all my other servers I have provisioned with the trellis installs so I’m running the playbooks from the same basic setup as the servers it provisions which cuts down on errors related to the environment your running trellis on. I’m pretty sure some dependency updated within the last few days and is messing with the variables related to the database / application.php / wp-config.php or maybe it messed with some of the variables relating to the paths were bedrock / trellis thinks the files should be… I’m just kind of throwing out ideas now.

Also there is a possibility I’m missing something really stupid and little that is causing all my problems, but I’ll know that is the case if nobody else reports the same issue over the next 2 days or so.