DEV Community

Discussion on: Pushing WordPress Theme Updates With Git

lewiscowles1986 profile image
Lewis Cowles

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?

jackharner profile image
Jack Harner πŸš€ Author

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:

  • test locally
  • push it up
  • fix bugs
  • repeat

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.

lewiscowles1986 profile image
Lewis Cowles

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 (, 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 for an example of using git tag 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

There is a whole lot of room to improve. Hopefully this helps some.