VirtualBox. Trellis. Ansible. Bedrock All Set. Now what

So to confirm: you set up a brand new Trellis project locally and got it all working with a default site?

Now you want to get it working with a project another developer gave you?

Your steps are generally correct. Although if that developer didn’t use Trellis you’ll need to do a DB search and replace to update paths.
Yes. I did that already, forgot including in the steps.

Also if you update the name of a site, you’ll need to do vagrant reload to update synced folders. Or just destroy it and start over.
The name of the site, as in, the domain? I’ll probably destroy it anyway.

For Sequel Pro, did you follow
Yes. I did. Actually, I just successfully connected to the database! My misunderstanding was the username “example_com”. Since the username isn’t defined in vault.yml, I was using “root” as username as number of tutorials on other websites suggested. Anyway, thank you for reminding me the page. I’ve spend 3 hours on this… a stupid mistake…

This is a huge leap from the regular WP development but I am slowly getting it…


After bunch of trials and errors, I was able to run the site… with some errors (class-wp-hook.php related) I believe they are caused by the PHP version. It needs to be PHP 5.6 (not PHP 7). How do I downgrade the PHP version in Virtualbox? I found this:

You’d have to search the Trellis codebase for php7.1 and replace with a suitable 5.6 package. Honestly I’d assume it’s easier to make the code work with PHP 7.

1 Like

You are right. I decided to go that route. I did some digging after that. It seemed like something to do with a custom theme the developer created. After I disabled some add_filter function on the theme, everything works fine.

Now I am onto the fun part, deploying.

Remember that deploy doesn’t include your uploads or database; you’ll need to do those yourself or employ additional deployment tools. I usually do the following:

  1. vagrant ssh to my development VM, cd /srv/www/ and wp db export

  2. (s)ftp the dump file (which is now in your site directory) and my uploads to current and shared respectively on my deployed server, ssh the server(cd to current) and do a wp db import file name.sql

It’s not the world’s most efficient method but it’s deliberate and I know I didn’t miss anything if I use these steps.

1 Like

Thanks Delaney!

I used the domain “” locally. I have my test domain(say, pointing to one of servers in Here is my guess:

  1. vagrant ssh to my Virtualbox and export db.
  2. The db has references to Search and replace them all with
  3. Make necessary changes on files under ansible/group_vars/staging/
  4. Put on ansible/hosts/staging file as a server hostname.
  5. Push my files to git repo.
  6. Deploy my staging files to a server.
  7. SFTP the SQL dump file/upload folder to current folder (and shared?) and do the import.

After this, I can open and my site is up and running beautifully! (in theory)

Am I missing anything?

Here is my update.

I published them all to a live server. When I accessed to the site, the site said usual “Welcome to Wordpress!” and the rest of form fields including site name and password. I did not complete that.

Instead, I started importing db. When I finished the import & I was thinking the site is up and running, I was wrong - the white page with nothing. No error.

Should I complete the Welcome to Wordpress AND THEN replace the db? Or… Am I doing something wrong?

to be continued…

Make sure you do a wp search-replace devurl liveurl after importing.

1 Like

I did that before I imported the sql.

Despite the blank page, I was able to access to admin dashboard URL. When I got there, There was a message “Database Update Required” . So I hit YES. Then I was able to get into the admin dashboard directly. At that point, I realized there was no plugin installed - including advanced-custom-fields. That explains why the homepage was completely blank. Is the database update something to do with this?

I feel this is getting really really close!

Very nice tool for transferring database + uploaded files (the actual data) - it will also update the URLs: Leveraging WP-CLI Aliases in Your WordPress Development Workflow


You should complete and log in with production user-pass at first. After you do push db, then you need your dev user-pass if they are different.

1 Like

I run this WP CLI command to finish the setup, it is idempotent,
which means that it doesn’t change an existing finished WordPress setup.

wp @production core install --url=<the-url> --title="<the-title>" --admin_user=<the-user> --admin_password="<the-password>" --admin_email=<the-email>

Edit: WP CLI can also be used for activating plugins + theme, installling languages packs and updating them - ideal as install hook.

Edit: Related thread: Install & update WordPress languages with WP-CLI

After I uploaded all plugins through sFTP, everything is working fine now. Thanks for the advices, everyone! I sense there is a better way to upload plugins but I’ll learn little by little.

Are you managing your plugins with composer? If so they should download automatically in the deploy process.

1 Like

No. And I knew that’s part of process that I needed to take. I cheated it. That’s what I am going to do next. One of the mistery is that…how about premium plugins and homegrown plugins?

You can add them to your composer.json in several ways, e.g.:

1 Like

This is the method I use. I keep a private github repo for each of my custom and premium plugins so that I can use them across projects. Which is mostly wishful thinking but hey, you never know.

Updating premium plugins becomes a chore (I have to download the update, then commit it to my repo for that plugin, then composer update each project that uses it) but it’s still “cleaner” than other options.

If you use ACF, there’s an even better way outlined here. Sadly it only works for ACF right now.

1 Like

Closing this thread as its served its purpose. We don’t like to encourage these ongoing threads since they make it harder to find solutions in.

1 Like