(Full disclosure, I’m employed by Automattic, but I wasn’t paid to write this post).
If you’re looking for a reliable and powerful WordPress hosting solution, one option is Pressable – a managed hosting platform created by Automattic which provides:
- A managed WordPress installation (core updates and security).
- SSL certificate provisioning.
- Automated Content Delivery Network for assets.
- Page Caching.
A problem with Pressable
Pressable is great in many ways (indeed I use it for this site), but one of the major downsides of the platform is that – as of the time of writing – it does not provide SSH access.
For a developer like me this is a significant barrier, principally because it stops me from using my favourite command line based tools (Deployer, rsync
…etc), for deployments.
When I work on a website, however small, I want to be able to run a single command and have my website reliably deployed to my remote host.
Ideally I would also like to be able to:
- deploy changed files only to minimise deployment time.
- run build commands – typically
npm
orcomposer
– to perform post-deploy tasks on the remote destination. - have full Atomic deployments with “rollback” capabilities, usually via symlinked
release
directories.
Regrettably due to Pressable’s lack of SSH support and strict directory structure requirements, little of the above is easily achievable.
This makes Pressable feel outdated and behind the curve when it comes to modern devops tooling.
Pressable and SFTP
Thankfully, despite its limitations on server access, Pressable does provide SFTP access to allow you to upload your files to its servers.
Typically I avoid FTP at all costs. I associate it with the novice deployment practices of my youth, which typically centered around drag and dropping files using GUI interfaces such as Filezilla or Cyberduck.
In my experience trying to handle deployments like this is no fun at all. Humans are simply not good at remembering which files have changed which leads to confusion, missing files and hard to debug deployment errors.
Thankfully there are other ways available to us.
Simple command line deployments to Pressable with rclone
What we need is a command line tool which can automatically detect our latest changes and deploy them to a remote host using SFTP. Whilst it is possible to us SFTP via the command line there are better alternatives. One such is Rclone.
Rclone bills itself as a an “rsync-like” command line program to sync files and directories to and from remote storage locations. Rclone provides a wealth of storage “backends”, one of which is SFTP storage.
Deploying a local WordPress installation to Pressable
For the remainder of this post, I’ll assume you have a local WordPress installation at ~/Sites/yoursite/
with a single Theme and some Plugins which you wish to deploy to Pressable.
Configure Rclone
To get started, install Rclone and configure it using the SFTP “backend” providing your Pressable SFTP credentials.
Note that I named the Rclone remote “pressableremote” but you can name it however you wish so long as you amend the commands below as required.
With Rclone configured, we can now start to deploy our local files to Pressable. Before we begin however, it’s worth recalling some information about Pressable’s servers and filesystem.
Pressable fully manages all WordPress core files (which appear as __wp__
on the server), with only the /wp-content/
directory available to upload user facing content (eg: Themes, Plugins, Uploads…etc).
Therefore for a given site we will typically only need to upload the /themes
and /plugins
directories to their respective locations on the Pressable server.
With this in mind, we’ll begin with deploying our Theme.
Deploying our Theme
To deploy a Theme residing at /wp-content/themes/sometheme
we can use rclone sync
which makes files on source and dest identical, modifying destination only.
It has a signature of:
rclone sync localfilepath pressableremote:remotefilepath
In our case this translates into the following command:
rclone sync ~/Sites/yoursite/wp-content/themes/sometheme pressableremote:/htdocs/wp-content/themes/sometheme
Before we run this blindly however, let’s consider whether there are any files which we don’t want to sync, for example:
- OS files (eg:
.DS_Store
and friends!). node_modules
directories.- Git directories.
- any unbuilt
src
files – typically these are assets such as.scss
or uncompiled.js
.
Luckily Rclone has a --exclude
global flag that can be used to exclude files from (almost) any command. Applying these to our example we get:
rclone sync ~/Sites/yoursite/wp-content/themes/sometheme pressableremote:/htdocs/wp-content/themes/sometheme
--exclude "**/node_modules/**"
--exclude="**/.git/**"
--exclude="assets/src/**"
--exclude ".DS_Store"
--progress
Note: we’ve also tagged on the --progress
flag to give us some visual feedback during the sync process.
Now run this from your local machine and you should see your files transferred to your Pressable server. This may take some time initially as FTP is fairly slow
You can now make changes locally and rerun the command to have the latest files deployed. Best of all, if you remove files locally, then these will also be removed from the corresponding remote location on sync.
Next up, let’s deploy some Plugins.
Deploying our Plugins
Deploying our /plugins
directory is largely similar to our Themes.
Running the following command will sync all files with the Plugins directory to the corresponding directory on Pressable:
rclone sync ~/Sites/yoursite/wp-content/plugins/ pressableremote:/htdocs/wp-content/plugins/
--exclude "**/node_modules/**"
--exclude="*/.git/**"
--exclude="~/Sites/yoursite/wp-content/plugins/akismet/**"
--exclude "~/Sites/yoursite/wp-content/plugins/jetpack/**"
--progress
With this in place we can now install Plugins locally and sync them to Pressable with a single command.
Handling Akismet and Jetpack
You may have noticed the --exclude
rules for akismet
and jetpack
. This is because Pressable includes both Plugins on its platform by default and it is not possible to remove them from the filesystem.
If, like me you have neither Plugin installed locally then the rclone sync
command will attempt to delete them from the remote. The resulting error will cause rclone sync
to abort any further deletions which may leave unwanted files sitting on the remote file system.
This is explained in the Rclone docs:
Note that files in the destination won’t be deleted if there were any errors at any point.
https://rclone.org/commands/rclone_sync/
Therefore (in theory at least) by adding exclude rules to cover Jetpack and Akismet Rclone should ignore these files during the sync thereby avoiding unwanted errors.
Unfortunately however, the above does not seem to work and Rclone still seems to attempt to deploy both Akismet and Jetpack plugins.
I’m currently still trying to find a solution for this. If you are reading this and come up with a fix, please do let me know in the comments.
Putting it all together
Will the above commands you should now be able to deploy your Themes and Plugins to Pressable via the command line. Granted, it’s some way short of being a perfect deployment system but it’s far more robust than drag and drop via Cyberduck!
If you want to take this further and fully automated things, why not create a custom bash script which runs the Rclone commands sequentially. Then you need only run a single command to have all your files deployed – perfect!
I hope in the future Pressable find a way to add SSH support as this would open the door to far better deployment tools. But for now, I hope this helps someone looking to achieve more reliable deployments to Pressable. If that’s you, let me know in the comments.
Clever!
Cyberduck brings back many memories of my start as a web developer 🙂 In the past with hosts who have limited or no SSH support, I remember using services like DeployHQ to do `git` -> FTP deployments.
I had never heard of Rclone. This seems like a great way to bypass the third-party service and have more fun on the command line. Thanks for the nice write-up!
It’s odd to see a hosting solution that doesn’t allow SSH these days. That said this seems like a nice way of getting around that limitation. I have also used third-party services in the past to deploy over SFTP, but this seems like a much cleaner strategy.
I agree with the custom bash script that should work nicely. You could even store the config in a YAML file or similar within your git repo.
Maybe Automattic will develop a tool to help devs deploy via the CLI or add SSH access in the future!