Error on "deploy | WordPress Installed?" task

I’m trying to deploy my multisite installation and I’m hitting a bit of a wall. Here’s the error:

< TASK: deploy | WordPress Installed? >
 -------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||


failed: [45.55.243.118] => {"changed": false, "cmd": ["wp", "core", "is-installed"], "delta": "0:00:00.679521", "end": "2015-10-24 21:26:38.564000", "failed": true, "failed_when_result": true, "rc": 1, "st
art": "2015-10-24 21:26:37.884479", "stdout_lines": [], "warnings": []}
stderr: WordPress database error Table 'staging_db.wp_blogs' doesn't exist for query SELECT * FROM wp_blogs WHERE domain = '' AND path = '/' made by include('phar:///usr/bin/wp/php/boot-phar.php'), incl
ude('phar:///usr/bin/wp/php/wp-cli.php'), require('phar:///usr/bin/wp/php/wp-settings-cli.php'), require('wp-includes/ms-settings.php'), get_site_by_path
WordPress database error Table 'staging_db.wp_sitemeta' doesn't exist for query SELECT meta_value FROM wp_sitemeta WHERE meta_key = 'site_name' AND site_id = 1 made by include('phar:///usr/bin/wp/php/boot-phar.php'), include('phar:///usr/bin/wp/php/wp-cli.php'), require('phar:///usr/bin/wp/php/wp-settings-cli.php'), require('wp-includes/ms-settings.php'), get_site_option
WordPress database error Table 'staging_db.wp_sitemeta' doesn't exist for query SELECT meta_value FROM wp_sitemeta WHERE meta_key = 'siteurl' AND site_id = 1 made by include('phar:///usr/bin/wp/php/boo$-phar.php'), include('phar:///usr/bin/wp/php/wp-cli.php'), require('phar:///usr/bin/wp/php/wp-settings-cli.php'), wp_cookie_constants, get_site_option

I’ve looked at these similar issues: 5087, 4107 but can’t solve this. Here is my group_vars/staging/wordpress_sites.yml if that helps:

wordpress_sites:
  example.com:
    site_hosts:
      - stage.example.com
    local_path: ../example.com 
    repo: git@bitbucket.org:conrman/example.com.git
    branch: stage
    multisite:
      enabled: true
      subdomains: false
    ssl:
      enabled: false
    cache:
      enabled: false
      duration: 30s
    system_cron: true
    env:
      domain_current_site: stage.example.com
      wp_home: http://stage.example.com
      wp_siteurl: http://stage.example.com/wp
      wp_env: staging
      db_name: staging_db
      db_user: stage_dbuser
      db_password: my_db_password
      ...

This seems like a weird error to me because I know Ansible tries to install WordPress for me. I went ahead and ssh’d into the staging server and completed the wp core install with the proper parameters.

This actually fixes my issue I mentioned above, but now it spits out a new error for the very following task:

< TASK: deploy | Update WP theme paths >
 --------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||


failed: [45.55.243.118] => {"changed": true, "cmd": ["wp", "eval", "wp_clean_themes_cache(); switch_theme(get_stylesheet());"], "delta": "0:00:00.074997", "end": "2015-10-24 22:39:03.425461", "rc": 1, "start": "2015-10-24 22:39:03.350464", "warnings": []}
stderr: Error: Site  not found.

I don’t want to dig myself into a hole here. I know installing the WP core by hand isn’t part of the workflow. I’ve provisioned the staging server and I don’t know what else to do. Any help is appreciated.

Actually Trellis doesn’t install WP on remote servers. In development everything is done automatically but the workflow is different. Since you need to run real deploys on staging/production it’s up to you to install WP.

As far as the next error you got, it looks like it’s a bug with Trellis. Here’s the command it’s failing on: https://github.com/roots/trellis/blob/1ccb789fbce617b7497bfaff14f7ecd434f94baa/roles/deploy/hooks/finalize-after.yml#L10-L14

I think we might need to add the --url option to those WP CLI commands.

/cc @fullyint since he knows more about this.

I had similar thoughts. When multisite is enabled, Trellis may need to conditionally include --url for the wp core is-installed command and the two “Update WP theme paths” commands.

On a multisite installation, you need to pass a --url parameter, so that WP-CLI knows which site it’s supposed to be operating on.
wp-cli docs

I’m afraid I don’t know much about multisite, so I’m not able to be very helpful. However, I see that you have subdomains: false. I’d guess that most people who have multisite working on Trellis are using subdomains: true. I also have a vague recollection of someone suggesting to deploy a regular wp install first, then switch it to multisite, but don’t quote me on that one.

The two tasks in question in this thread only need to run after your very first deployment. So, for the sake of debugging and being able to move on with your multisite life, I’d recommend commenting out those two tasks, and resolving other more important issues that may arise in getting your multisite working. You can get around ever needing to uncomment those tasks if you are willing to navigate to the wp-admin of your site after each deploy (see details in roots/trellis#275).

As a side note, you also have flexibility in your commitment to cows.

2 Likes

Oh wow. I guess I just assumed Trellis installed WP on every environment because it does on development. Good to know. wp core multisite-install did the trick to fix the first issue I mentioned.

@fullyint Since I installed WP by hand I only had to comment out the 2nd task (“Update WP theme paths”) and that enabled me to get through the rest of the deploy process. Thank you.

I am wondering though, is this effecting the ability to run the post install build commands (npm/bower/gulp)? I am not seeing node_modules,bower_components, or dist on the stage server. Or is this another thing that Trellis only does for the development environment.

By default Trellis only runs composer install on deployments. We can’t really make any assumptions about a theme’s asset workflow so we don’t.

https://github.com/roots/roots-example-project.com contains the necessary configuration to get Trellis working with Sage as an example. We suggest running those commands locally and then copying the files.

Currently that repo is outdated :frowning: but see here for working new code: Deployment with the new Trellis hooks

2 Likes

@swalkinshaw Thank you for clearing that up, 5016 helps tremendously. I used to use bedrock-ansible back when Ansible was 1.9.1 and I was able to get away some silly stuff: Ansible playbook gulp dist/production assets not moving to staging environment

Thanks for helping me work out the kinks/misunderstandings as I migrate to the latest Trellis build.

I’m not very familiar with ansible, I’m having trouble successfully implementing what is discussed in the 5016 thread.

I created a new folder for my custom deploy hooks and added a yml file with some new tasks to run NPM, Bower, and Gulp.


deploy.yml:

---
- name: Deploy WP site
  hosts: web
  remote_user: "{{ web_user }}"

  vars:
    deploy_build_before: "{{ playbook_dir }}/custom-hooks/finalize-build.yml"
    deploy_build_after: "{{ playbook_dir }}/roles/deploy/hooks/build-after.yml"
    deploy_finalize_after: "{{ playbook_dir }}/roles/deploy/hooks/finalize-after.yml"
    project: "{{ wordpress_sites[site] }}"
    project_root: "{{ www_root }}/{{ site }}"

  roles:
    - deploy

finalize-build.yml:

---
- name: Run npm install
  command: npm install
  connection: local
  args:
    chdir: "{{ project.local_path }}/web/app/themes/my_theme"
- name: Run bower install
  command: bower install
  connection: local
  args:
    chdir: "{{ project.local_path }}/web/app/themes/my_theme"
- name: Run gulp
  command: gulp --production
  connection: local
  args:
    chdir: "{{ project.local_path }}/web/app/themes/my_theme"
- name: Copy project local files
  synchronize: src="{{ item.src }}"
               dest="{{ deploy_helper.new_release_path }}/{{ item.dest }}"
               group=no
               owner=no
               rsync_opts=--chmod=Du=rwx,--chmod=Dg=rx,--chmod=Do=rx,--chmod=Fu=rw,--chmod=Fg=r,--chmod=Fo=r
  with_items:
  - src: "{{ project.local_path }}/web/app/themes/my_theme/dist"
    dest: web/app/themes/sage

And the error I’m receiving:

failed: [104.131.113.87] => {"failed": true, "rc": 258}
msg: cannot change to directory '/srv/www/example.com/current/web/app/themes/my_theme': path does not exist

I’m assuming I see that error because the current directory doesn’t actually get symlinked until the deploy_finalize_after task is complete.

So when I change deploy_build_before to deploy_finalize_after in the deploy.yml I get no errors, but unfortunately I still have no compiled dist directory either :frowning:

@connormfreeman Could you point out which task is getting that error message? Is it the “Run npm install” task?

Could you double-check that your local_path variable in wordpress_sites indeed points to your bedrock project directory? If you have the project structure and directory names below:

example.com/    - Primary folder for the project
├── trellis/    - Your clone of repository
└── site/       - A Bedrock-based site (suggested to name this the generic `site` since your project name is already at the top level)

then your wordpress_sites should have

local_path: ../site # path targeting local Bedrock site directory (relative to Ansible root)

instead of local_path: ../example.com as it appears in your original post. But maybe your bedrock directory is named example.com (like in the past).

@fullyint Yes this is failing on the “Run npm install” task. My local_path is correct, I’m going against the convention by having a singular Trellis install with multiple WordPress installations. So for me it’s dev/trellis and dev/example.com

I made a mistake in the output path in the previous error message (7). Using the {{ project.local_path }}in my finilize-build.yml file I was actually getting the following error:

failed: [104.131.113.87] => {"failed": true, "rc": 258}
msg: cannot change to directory '/Users/connor/dev/example.com/web/app/themes/my_theme': path does not exist

I accidentally mis-copied the error message from when I had tried what OP was trying in 5016 and using {{ deploy_helper.current_path }} in the deploy.yml file.


So just to clarify, I am getting a completed deployment to my DO staging server with deploy_finalize_after: "{{ playbook_dir }}/custom-hooks/finalize-build.yml" in my deploy.yml

This could stem from my inexperience with ansible so I’m going to do some reading before I keep pressing for answers. In the mean time I think I can manage with just running the final build commands on the staging environment.

My best recommendation would be to follow the example in roots/trellis#397. Note that the example uses a new directory deploy-hooks, vs. your custom-hooks. Your theme directory may already have a fresh npm and bower install, so you could leave the two install tasks commented out.

As a little detour, note the strict correspondence between hook names and file names in the example:

deploy_build_before: "{{ playbook_dir }}/deploy-hooks/build-before.yml"
deploy_build_after: "{{ playbook_dir }}/roles/deploy/hooks/build-after.yml"
deploy_finalize_after: "{{ playbook_dir }}/roles/deploy/hooks/finalize-after.yml"

I think it will serve your project’s conceptual clarity to switch your filename from finalize-build.yml to build-before.yml. Of course, that assumes you also switch back to hooking that file into the deploy_build_before hook so that hook name and filename correspond (and so that your fork doesn’t unnecessarily deviate from the roots upstream). I realize that means you could run into the error you mentioned earlier. Perhaps you’ll avoid the error by copying the example in roots/trellis#397, but if the error persists, see the thoughts below.

I think Ansible runs a non-interactive shell session on your local machine and its first step with the “Run npm install” task is to cd into the directory /Users/connor/dev/example.com/web/app/themes/my_theme. Any ideas why why that cd is failing? Does that exact directory exist on your local machine? Anything unusual with that directory (permissions, symlinks, etc.)? Maybe there is some multisite phenomenon I’m not anticipating.

You can certainly compile assets on the remote server but the general recommendation is to compile locally then sync your theme’s dist directory to your remote server. It all really depends on your context. More notes in @austin’s http://austinpray.com/ops/2015/01/15/build-steps-and-deployment.html

In a simple context, you’ve already been developing locally so your npm and bower are in place and you can just run gulp --production in your theme directory, then run something like:

rsync -az /Users/connor/dev/example.com/web/app/themes/my_theme/dist web@example.com:/srv/www/example.com/current/web/app/themes/my_theme

Of course, hopefully you’ll manage to automate those commands above by hooking the build-before.yml into your Trellis deploy.

1 Like

Just to clarify one thing in this thread:

{{ deploy_helper.new_release_path }} vs {{ deploy_helper.current_path }}

new_release_path can be used before the symlinking happens because it will point to a path like releases/201510200532. current_path will always be the current/ path.

You want to do all your asset compilation stuff during the build stage and not finalize ideally.

@connormfreeman @swalkinshaw @fullyint
Just wanted to say thanks for to multisite workaround above. Worked a treat!

1 Like

I was using and deploying to production for a while until this error showed up to me, for me, the solution was to add the following in the composer.json

{
  ...
  "config": {
  ...
    "allow-plugins": {
      "composer/installers": true,
      "roots/wordpress-core-installer": true
    }
  }
}