If your final live environment is going to be cpanel (I’m in this boat 90% of the time), I tend to just have a vagrant machine I’ve generated using http://puphpet.com which closely matches the specs of my server (I’m on Sitegrounds cloud accounts quite often these days and if you pester their staff you can get them to tell you which apache and php modules they’re running… it even lets me change PHP version on a per directory basis which is pretty cool).
For this I decided against Trellis as its just a bit too different to the live environment for my liking.
A couple of valuable tips I’ve learn in the couple of years since making this thread:
-
If you put your generated vagrant machine from puphpet itself into a git repo and agree a directory structure for your projects folder with your team, you can quickly make sure the rest of the team has the same Vagrant config, with the same vhosts and databases available.
-
You can set your vagrant sync directory as a directory ‘above’ the vagrant file e.g. something like:
synced_folder:
vflsf_qsxnmdmnxct2:
source: ../
target: /var/www
sync_type: nfs
This way I just tell my team to keep a /Projects directory, with sites in paths like: /Projects/examplesite.com/ and the vagrant machine in a path like /Projects/vagrant-001.
This lets me have a /Projects folder with all my sites and various vagrant machines.
To answer your question more specifically though @louisnovick, for database syncing when working with cPanel, I’ve found the simplest thing to do is to set up a mysql database through the cPanel gui, whitelist your IP in the ‘Remote mySQL’ section of cPanel.
Then in either wp-config.php or (.env if you’re using Bedrock), I have something like this going on in my local dev version:
# Dev:
#DB_NAME=vagrant_dbname
#DB_USER=vagrant_dbuser
#DB_PASSWORD=vagrant_dbpass
#DB_HOST=localhost
# Staging:
DB_NAME=cpanel_staging_dbname
DB_USER=cpanel_staging_dbuser
DB_PASSWORD=cpanel_staging_dbpass
DB_HOST=<IP of cPanel SERVER>
WP_ENV=development
WP_HOME=http://example.dev
WP_SITEURL=${WP_HOME}/wp
^^ Provided you’re developing with reliable internet the fact Bedrock overrides the WP_HOME and WP_SITEURL settings with your local domain name (‘example.dev’), means you’ll get a dev copy that’s pulling your database from your staging site, and running off your local files.
If you’re not using Bedrock you’ll need something like the following in your wp-config.php:
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/wordpress');
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);
define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/wp-content');
define('WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/wp-content');
I like this because it means I can let non-developers in my team start adding content via the wordpress admin on the staging domain whilst the site is still in development, effectively using the staging database (and uploads folder) as the ‘one true’ database.
I effectively do no database syncing, all I have to do is periodically download the contents of the /wp-content/uploads directory.
In most cases I don’t even need to do that since post attachments will use the staging URL.
I’ll happily elaborate on doing it this way if this explanation didn’t make sense, I’m kind of interested if anyone else does it this way.
Note: when I finally ‘go live’ and my client/team have finished adding content and uploads, I download the whole uploads directory, optimise all the images, and then re-upp them on the live site. I add the live database details to my .env or wp-config, and do a similar set up (so live DB becomes the ‘one true’ database).
As a final step I’ll run https://github.com/interconnectit/Search-Replace-DB on the database (from command line in vagrant since similar commands stay in my bash history), or just through its gui. This is to make sure ALL urls in the final database (WP_HOME, WP_SITEURL and all the post attachment links) are pointing to the live domain (e.g. http://example.com rather than ‘example.dev’ or ‘staging.example.com’ or anything else).
I still think Trellis is better, but I reserve that for when I have a client who’s willing to let me put them on a digital ocean droplet. I’ve found Trellis and cPanel to just not play too nice together.
(Even Bedrock requires some symlinking of your public_html folder to make it work with cPanel - cPanel won’t let you change the default webroot, so I point /public_html to /examplesite.com/web and install Bedrock to /examplesite.com/, there were threads on here about this I’m sure but I can’t seem to find them in search right now).
Convoluted answer but, thought I’d share as this is working well for me now.
Edit: One more ‘quirk’ that I got was that if you’re also using Sage, with Git, running Gulp locally, when you deploy from git to your staging and live environments, your /themes/sage/dist/ folder will be missing. I got round this by making my ‘staging’ and ‘production’ branches have a separate .gitignore where the /dist folder isn’t ignored. My git history ends up with a lot of switching to ‘staging’ branch, merge in latest changes from ‘dev’ branch, running ‘gulp’ or ‘gulp --production’, commiting the changes to the /dist folder, and then git push and pull, /dist directory included. This way I rarely have to touch FTP.
