Remote management of WordPress sites is important to me. I manage a number of WordPress sites. I find myself, often, in the same situations doing the same things. Naturally, I wrote scripts to automate this. I made a software package out of these scripts and put them up in GitLab (you’re not still using GitHub are you?).
Use these scripts as you feel appropriate. Also, this is very much an alpha release of an idea. These scripts work for me because I do things in the sites I manage in a pretty consistent way. If you have suggestions for improvements please tell me!
You can either clone the repository
git clone https://gitlab.com/mck7/wordpress-scripts.git
Or you can just download the zip file
wget https://gitlab.com/mck7/wordpress-scripts/-/archive/master/wordpress-scripts-master.zip
Or, if you don’t want to use any of those commands, here’s a pretty button to download it:
There is a ton of information in the README.md file of the repository. I’m copying it here for ease of the reader.
Assumptions
Remote Assumptions
This project assumes you have configured a remote connection to your server via ssh. There are a number of tutorials in how to do so if you haven’t already. The variables that are pertinent to this are here:
REMOTE_HOST=example.com REMOTE_HOME=/home/username REMOTE_DOCROOT=/var/www/html
It is also assumed that the remote file system uses www and dev as prefixes to the site name in the folder structure. Here’s an example:
/var/www/html/dev.example.com /var/www/html/www.example.com
Finally, all of the scripts here accept only 1 argument on the command line. That argument is the short version of the environment where the action is required on.
Examples include:
./bin/deploy-wordpress-theme-updates.sh # defaults to the dev environment ./bin/deploy-wordpress-core-updates.sh www # acts on the www (production) environment ./bin/remote-deploy-repository-to-environment.sh www # Remotely deploy production
Project Directory Assumptions.
It is assumed that your project is in the following folder structure
- example.com
- bin
- src
- wp-content
- wp-admin
- wp-includes
- wp-config.php
Database Assumptions
It’s also assumed that the same user has access to both versions of the database for production and staging/development environments. It’s assumed that the names of the databases are example and dev_example to correspond with the database. It is assumed that the local database name is the same as the remote production database name
Another key assumption is that a local .my.cnf file is configured to allow prompt-less MySQL connections. This is a key point. It’s better to not have passwords being sent in command line. It’s also greatly useful to not have to enter them in as often.
Usage
Deploy Production to Development.
This script serves to synchronize the remote production environment to the remote development environment. The script also backs up the production database and sources it into the remote development environment. Provided the env file has the right settings, usage of the script requires no arguments. It must be called in the remote server.
./bin/deploy-production-to-development.sh
Deploy Repository to Environment
This script serves to deploy versioned code to an environment. This will stash any local changes on the site, clean un-versioned code off of the site, checkout the existing branch on the site, and re-pull that branch from it’s origin.
./bin/deploy-repository-to-environment.sh
Deploy WordPress Core Updates
This script assumes the wp-cli package is installed. Using it, this script will call wp --allow-root core update && wp --allow-root core update-db
Deploy WordPress Plugin Updates
This script assumes the wp-cli package is installed. Using it, this script will call wp --allow-root plugins update --all
Deploy WordPress Theme Updates
This script assumes the wp-cli package is installed. Using it, this script will call wp --allow-root theme update --all
Local Deploy Production To Repository
This script is a result of the reality of managing WordPress sites that clients update on their own, often without the developer’s knowledge. This allows for pulling remote content to a local environment. This includes database and files.
Any not commited local code will be lost if this script is called before committing it. So, commit your local changes before calling this. A release tag will be created using YYYY.mm.dd as a format. I realize this isn’t semantic versioning, but it’s been my experience that in these types of sites, semantic versioning really doesn’t work.
Local Sync Database
This script backs up the the remote production database, pulls it down locally, sources that database into the local database, then cleans up the remote backup, as well as the local copy of it.
Local Sync Filesystem
Performs an rsync command from the given environment (i.e. dev or www), and overwrites local files here. A --delete flag is also set. Therefore, any files and directories that don’t exist in production will be removed from your local environment. Commit your code before running this.
Remote Deploy Production To Development
A utility script that calls the deploy-production-to-development.sh over ssh
Remote Deploy Repository To Environment
A utility script that calls the deploy-repository-to-environment.sh over ssh
Remote Deploy WordPress Core Updates
A utility script that calls wp --allow-root core update && wp --allow-root core update-db
over ssh
Remote Deploy WordPress Plugin Updates
A utility script that calls wp --allow-root plugin update --all over ssh
Remote Deploy WordPress Theme Updates
A utility script that calls wp --allow-root theme update --all over ssh
