Do you frequently update WordPress themes? It's kind of a pain in the ass, right? Typically has to be done manually through FTP or uploading a new zip through the backend.
Well, today I'm going to show you how to update your site with just:
$ git push live
Sounds to good to be true? It's not. Check it out:
Prerequisites
1) SSH Access to your web server
2) Git installed on your local machine and on your web server
This setup works best for one off customs themes (like the one on HarnerDesigns.com) and not for themes produced to be distributed.
Create Your Repo Locally
First things first, create a folder for your project and enter it:
$ mkdir git-test && cd git-test
then initialize the repo:
$ git init
Alternatively, you can just clone my Blank2 - Blank WordPress Theme repo to get started:
$ git clone https://github.com/harnerdesigns/blank2.git git-test
Create A Bare Repo On The Remote Server
A bare repo is a directory containing the working tree of your git project, just without storing all the files. It's essentially just a directory of all the files noramlly in your .git directory.
SSH into your server:
$ ssh <user>@<server>:<sshPort>
Create a folder for the bare repo and enter it:
<user>@<server> $ mkdir git-test.git && cd git-test.git
Remember where on the server you created this directory, you'll need that later (Doing it in your home directory works perfectly fine).
Initialize the bare repo:
<user>@<server> $ git init --bare
Hook It Up
Your shiny new bare git repo has a directory hooks and in it are a bunch of .sample files. We want to do something after the repo receives new data, so create a new file called post-receive (no extension) and add the following to it:
#!/bin/bash
GIT_WORK_TREE=<pathToWordPressInstall>/wp-content/themes/git-test git checkout -f
What this will do is, any time you push to this git repo, set the working tree for the repo to the theme folder in your WordPress install and then force checkout the files.
Back Down From The "Cloud"
Now logout of your remote server. It's time to add the new repo as a remote for your local one.
Make sure you're in your project's folder:
$ git remote add live ssh://<server>/home/<user>/git-test.git
and that's it! All you need to do to update your live theme now is add some files, commit them like normal and then run:
$ git push live
Being able to Update WordPress sites quickly allows for quicker bug fixes and less time spent wrangling files. Combine this idea with a taskrunner like Gulp and you'll be flying through updates.
Let me know if you use this method or if you have any other ways to manage WordPress Themes!
Top comments (11)
Great article! I use similar setup for all web projects (not only WP themes) I have. It is somehow annoying that there are so many great dev tools to automate our workflows yet Wordpress devs usually push their code via FTP. At least that's just my experience at places I worked for.
For the longest time I was in the boat of "just zip it and upload it through the Admin Panel" until I started working with the customizer. Since those options are theme specific and when you upload a new zip it treats it as a whole new theme. All of the customizer options would be lost. This way's so much more efficient.
I had a similar approach and it wasn't great. I really wish there were better (easier) and more standarized tools to develop for Wordpress and Wordpress plugins.
I've definitely started looking in to using Docker for WordPress. It saves a lot of time in the initial install and running of the sites.
Interesting. I didn't think of Docker so thanks for the tip. I will give it a try!
Thanks for sharing! My work uses WPEngine for our hosting and their service includes a git functionality. We set up a TravisCI script that runs when new code is merged into our
masterbranch that then deploys our theme files to the staging version of our site so we can review it before we deploy our staging site to production. It's so much better than dealing with the hassle of FTP.How are you handling dependencies in such a scenario, and what about test, staging, production pipeline? Are you only currently hosting on single-vps or shared hosting?
Dependencies on the stuff that I've worked on so far are pretty limited. At most it's things like jQuery and maybe a slider, but then I just add those js files to the theme and use Gulp to concat/minify.
As far as test/staging/production it's mostly been:
I have started looking into using docker and WordMove as a way to have multiple copies of the same full wordpress install on multiple machines, but haven't fully implemented it into my workflow yet.
Currently, this has all been personal projects and a few freelance clients, but most of my sites are running of DigitalOcen droplets.
Obviously there are some steps I'd need to add to my workflow for any kind of enterprise work, so I'm open to suggestions if you have them.
Hey Jack,
I suppose it's best to start from, how are clients approving changes if it goes from local-dev to live?
I've worked in the way you've described before, so I know the stress and pain it can cause for me, and for clients.
I wouldn't call backups or deploys an enterprise pattern as much as a recognition of value.
You could start by enabling droplet backups, learning wp-cli for exporting the database, plugin & theme installs, experimenting in VM's.
I'm not seeing lots of use-case for WordPress in Docker containers outside of testing. It was different in the initial PHP7 launch, but it is the only actively supported release now (php.net/supported-versions.php), but certainly having a repeatable Vagrant VM can be of use locally to experiment with adding caching or shared state (multi-server or caching or both).
Once that is done you could experiment with child-themes, and multi-site. That can provide a single login which lets you have mutliple sites with mostly shared features, the option to diverge in a branching pattern, and the ability to interact with and gain client approval on changes.
Small things like storing nginx configs as code in repo's can help repeat-ability and consistency.
To upload themes you can ensure the branch name is included so {branch}-{theme}.zip see git-scm.com/docs/git-archive for an example of using git tag stackoverflow.com/questions/624557... shows how to get active git branch instead.
You could maintain branches for staging or use feature branches to facilitate, run webpack or gulp before creating an archive, push that to the right place using a tool like scp (digitalocean supports scp & ssh) and wp-cli install theme from zip developer.wordpress.org/cli/comman...
There is a whole lot of room to improve. Hopefully this helps some.
Super awesome Jack! Its fun to read this post and I will surely try it up soon!
Thanks for sharing! I'm quite new in Git so it is helpful info.