So to confirm: you set up a brand new Trellis project locally and got it all working with a default site?
Yes
Now you want to get it working with a project another developer gave you?
Yes
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 https://roots.io/trellis/docs/database-access/1?
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.
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.
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:
vagrant ssh to my development VM, cd /srv/www/example.com/current and wp db export
(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.
I used the domain “example.dev” locally. I have my test domain(say, staging1.example.com) pointing to one of servers in DigitalOcean.com. Here is my guess:
vagrant ssh to my Virtualbox and export db.
The db has references to example.dev. Search and replace them all with staging1.example.com
Make necessary changes on files under ansible/group_vars/staging/
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?
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?
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.
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?
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.