Should you use version control when you’re working on a WordPress website or not? It depends on what you’re going to do. Are you creating a custom theme or plugins? Or are you just using some plugins from the WordPress theme directory with a free or premium theme from Themeforest?
When you’re not using version control
You’ve downloaded the WordPress archive, extracted it, uploaded it to your hosting environment, ran the installation, installed some useful plugins and put your purchased theme from Themeforest in the “/wp-content/themes” directory. Congrats you’ve installed WordPress! You can update Wordpress and it’s plugins easily through the backend and critical WordPress updates are even installed automatically. To update your premium theme from the backend you could use the Envato WordPress Toolkit so you don’t have to do this manually. Fantastic, what a great system! No I’m not joking, it really is! How simple can it be?
Version control your custom theme or plugin
But what if you’re creating your own theme (for example with Sage) or plugin? You could just upload it every time you’ve changed something but how do you keep track of your changes? What if you’ve to undo your latest change or working on it with a team? That’s where version control systems like GIT can be handy! Put your custom theme or plugin in version control, work on it by committing your changes so you can do a rollback later if needed and work easily together with your team by using online services like Github or BitBucket. On your server you “cd” into the correct directory and “clone” your GIT repository with your theme or plugin. Great! Problem solved.
Version control everything
But what if you’ve multiple custom themes or plugins? Then you’ve to “cd” into all those directories and “pull” the latest versions, why don’t you just put everything (WordPress and all plugins and themes you’re using) in version control? No problem, fixed in no-time! Init GIT, add all the files and do a initial commit.
WordPress auto updates
But why is the auto updater not working anymore? Because WordPress checks if it’s under version control because files should not automatically change when they’re under version control. As you can see there in the code we can override this by defining a “automatic_updates_is_vcs_checkout” filter to ignore this check. But is that really what you want? Then we’ve uncommitted changed files after a update, so don’t! When you’ve WordPress under version control you should take care of all types of updates by yourself. Update WordPress on your local environment, “commit” the changes and “pull” them on the production environment.
Installations and updates from the backend
WordPress doesn’t auto update anymore because it’s under version control, but we still can update WordPress by clicking the update button. Also we (or your end user / customer if they’ve a admin account) can install plugins and update everything else (plugins, themes and translations) from the backend. When we do one of these things we’ve again uncommitted changed files, so it’s advised to disallow these things by defining the “DISALLOW_FILE_MODS” constant. Now it’s “impossible” to get changed files on your production environment. So a “git status” shouldn’t return any changes, if it is returning files changes something (like a plugin or theme) isn’t following the WordPress standards or you’ve got hacked. I don’t wanna scare you, but when you’ve got hacked your happy with version control because you can see what files are changed and with a “git checkout .” all the changed files by the hacker are undone.
You’ve got all your WordPress websites under version control. But think about it, isn’t their much duplication? WordPress itself is in all those GIT repositories and probably on every WordPress website you’re using almost the same plugins. When there is a WordPress, theme or plugin update you’ve to open all those sites locally and update, commit, push and pull. Can this be done cleaner with less duplication in repositories and less work when there is an update? Absolutely! Use Bedrock!
What is Bedrock?
Bedrock is a boilerplate for WordPress which is using a better folder structure, handles dependency management with Composer and makes it very easy to configure with Dotenv and environment specific configuration files. With Bedrock you’ve a very solid base when you’d like to put your WordPress site under version control.
How is Bedrock making it easier?
All your dependencies like WordPress itself and mostly plugins are defined in your “composer.json” file, just one line with the name and the version number you’d like. After running “composer install” (or “composer update” in case you’ve changed something in the “composer.json” file) all the dependencies will be downloaded (or grabbed from the Composer cache in case the dependency is already downloaded before) but ignored for version control so they aren’t in your GIT repository. So if you want to update WordPress or something else, change the version number in the “composer.json” file, run “composer update” and commit the two changed files (the composer.json and composer.lock file). On your production environment you just have to do a “git pull” and a “composer install” and your update is live. How clean can your GIT repository be?
Dotenv and environment specific configurations
One of the other great things about bedrock is the build-in configuration which is using Dotenv. The configuration files take care of defining constants per environment, like the earlier mentioned “DISALLOW_FILE_MODS” constant and Dotenv takes care or environment specific configuration settings. Just one simple “.env” file which contains all the configuration options.
What are the downsites of using Bedrock?
All translations needs to be committed in your GIT repository by default which causes “duplication” again, you’ve to do some additional stuff go get multisite working and not really a “Bedrock problem” but relevant if you’ve bought some premium stuff from Themeforest: it’s to devious to install premium stuff with Composer.
What do you use?
For “simple” WordPress websites without custom code I don’t use version control, I think it’s a little bit overkill and I like the auto update feature in that case. But for projects with a custom theme or plugin I’m using Bedrock and I’ve my theme or plugin in the same repository because most of the time it’s specific for that website. What do you do in which scenario and why?