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:
- 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.
- 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:
