Previously I have spoken about my WordPress development and deployment setup using a service such as Deployhq, but lately I ran into a minor problem with this setup. The issue was the live site was being updated without the repo in Git being touched. Here is what I needed to do to solve the problem.
This has all come about since the brilliant auto-update feature of WordPress was introduced (I think in version 3.7). This means that your site will auto update itself for minor point releases (e.g. from 4.1 to 4.1.1 but not from 4.1 to 4.2). However, if like me you have the site under version control then you do not want this to happen as you need to manage the repository.
The WordPress team already thought of this as a problem and came up with a good solution. WordPress detects whether your site is using version control by looking for .git, .svn and other version control files in your site. If it finds these then of course the auto update is not set to run.
If you have a setup whereby you are pulling a Git repository to your server then those .git files will also exist on the server. However I use a different setup using a deployment service to deploy the files from the repository (usually on Github or Bitbucket) to the server. This means that those version control files (.git etc.) never get pushed to the server. Therefore the instance of WordPress on the live server (and staging for that matter) gets auto updated for point releases.
I needed to stop this happening or the live and staging sites would be ‘out of sync’ with the local sites developers are working on. Luckily there is a constant you can use in your wp-config.php file to prevent core from updating, period. Add the following to your wp-config.php file and it will prevent WordPress from auto-updating core.
define( 'WP_AUTO_UPDATE_CORE', false );
Now I am in control of when the updates are run and when WordPress gets updated to the latest and greatest version. Something which is important when you site is under version control.
Leave a Reply