Using Git to version control the entire wp-content directory

When building websites, I often use a combination of a custom theme, several custom plugins, and various third party plugins. I didn’t always do it this way but in doing so, I now think of a WordPress powered site relative to the entire installation and approach it as a system — WordPress gives us an entire plugin system so why not use it.

Why use custom plugins when building websites?

My approach has evolved significantly since I started way back in 2006 and there was a long period of time where I would bake everything into a custom theme. Whilst this can feel like a neat and organised approach, it can be problematic for a few reasons:

  1. If that website ever needs to go through a redesign, I’ll have to pick through all the existing logic and make sure it is moved to the new theme.
  2. If I ever need to reuse functionality in other work, I’ll have to dig it out and try to remember where all related code is.

These days, I like to leave the theme to do what it is intended to do — handle the style of the website. Any logic that would need to survive a theme change such as post types & taxonomies gets handled in a custom plugin. Additionally, if I’m making modifications through hooks & filters for third party plugins and these modifications need to survive a theme change, I’ll add those to purpose-built plugins as well.

The result here is that I end up with one or more (sometimes many) custom plugins that have a focused intent & responsibility. I also then know that everything within the theme is about style and display.

Version controlling the wp-content directory

When working with a project in this way, we end up hitting the question of how to version control this structure — we have a number of third-party plugins that we don’t control and will usually upgrade from within the WordPress dashboard, we have a number of custom plugins and a theme that we want to version control, and we have other extraneous aspects within the wp-content directory that we don’t want to version control such as media files, cache directories, generated drop-in plugins, etc.

We can, of course, version control the theme and custom plugins individually. I prefer not to do this as I find it adds to the work and the mental overhead of managing the project. Instead, I track the entire wp-content directory and just ignore anything we don’t want. To facilitate this, I tend to prefix all custom plugins with the same prefix- so that they are easy to track as it means I don’t have to keep adding rules to track them in the .gitignore file.

A .gitignore boilerplate to get you started

It took me some trial and error to determine a decent boilerplate for tracking the entire wp-content directory so I’d like to share it here in case it if of use to others. Modify as you need, of course:

.DS_Store
.sass-cache
node_modules
/upgrade
/cache
/uploads
/advanced-cache.php
/debug.log
/languages
/db.php
/wflogs
# Ignore anything within themes, except the theme we are building.
/themes/*
!/myproject-theme
# Ignore anything within plugins. Exceptions to this to follow.
/plugins/*
# Track any plugins prefixed with myproject-
!/plugins/myproject-*
# Track any other plugins we control
!/plugins/some-custom-plugin
!/plugins/some-modified-third-party-plugin
view raw .gitignore hosted with ❤ by GitHub

About the author

Phil Kurth is a web developer living in Melbourne, Australia. Phil has a long history of WordPress development and enjoys building tools to empower others in their web design/development practice.

When not working with the web, Phil is usually spending time with his two young sons or is out hiking through the Australian bush.

Posted by in WordPress Tutorials tagged

Good dev stuff, delivered.

Product news, tips, and other cool things we make.

We never share your data. Read our Privacy Policy

© 2016 – 2022 Hookturn Digital. All rights reserved.