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.
