Disable WordPress Auto Update on Production Server

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.

A WordPress Development Setup – Part 2

This is second post in a three part blog post series on setting up a WordPress development environment. The first part can be read here. Having got your local machine setup ready with your hosts etc. the next part is to actually create your WordPress site on the local machine under version control. The steps below you need to complete for each WordPress site you build.

I have done development differently quite a lot in the past. There is the debate of whether to have the entire site in version control or just the themes and plugins. Having tried both I prefer to keep the whole site under version control and therefore this is the method that I shall be outlining here.

The first part of getting a WordPress site setup is to create your repository to keep your code in version control. I use Git alongside Github and therefore I shall show this method here. To create your repository login to your Github account and click the Create button in the upper right corner of the screen.


Give your repository a suitable name (no spaces here is best) along with a description.Note that the name will give will form part of the local url of your site, although it could be changed if necessary. I always add a read me file to which indicate basic information about the repository.

Making sure you have Github app installed on your machine (either Windows or Mac ) on the repository page you are taken to on creation, click the “Clone in Desktop” button. This will open Github on your machine and ask you where you want to place the repository. Depending on which local “domain” you want to place it in, add it to the correct folder we setup in part 1.

The next stage in the process is to edit your wp-config.php file. We want to keep this under version control, however the connection to our database will be different whether we are working locally or working on the server of the live site. For these reasons we need to make some changes to the wp-config.php file. I follow the steps outlined by Mark Jaquith, which allows you to use a local-config.php file.

Once we have this setup we need to make sure that our local-config.php file is not under version control. For this we can use Gitignore, which happily the Github app allows you to control. From the Github App screen for the repository we created previously click on the “Settings” tab from the menu in the left.


In the ignored file box add local-config.php as well as the wp-content/uploads folder. We don’t want to have all of our media library under version control as this could be huge eventually. Once you have added these click Save Changes and these files will not be under version control.

Now you can install WordPress in the normal way locally (using MAMP) and work away developing your site. I would commit regularly using the Github app.

The final part of this tutorial will focus on getting your site using a staging server and a live server.

A Review of 2013

Wow, 2013 has been a memorable year for me in terms of my freelance career. I really feel that I have been able to take a step forward in terms of my knowledge and the sites that I have be privileged to work on. As is always the case I take the time to review the year and how things have gone. The highlights below are split up in no particular order, other than how they happened through the year.

Using Github

Although on my Github Profile (wpmark) it states I joined Github in July 2012 which is of course true, I did not really start to use it an awful lot until the start of this year. At the start of the year I put some of my Open Source code on there such as my User Switching from the Admin Bar addition to John Blackbourn’s User Switching plugin, which allows you to switch to a user from the Admin Bar and my WP CSS Widget Classes Plugin, which allows you to add a class to widgets.

Adding these smaller projects to Github got me used to the real basics of Github in terms of committing etc. It was not until the summer however that I started to use Github in a much better way.

Having worked with the fantastic team of WordPress developers at Code For The People for a few weeks over the summer, I was able to see how they used Github for projects. It worked really well when collaborating with members of a team when code was being edited and added to by a number of developers.

Having taken all this on board it was later in the year that I started to use Github with some other members of the Pixel Junction and Compass Design teams on some of the shared projects we worked on. This really changed things for me in terms of the development process of a site and made things a whole lot easier.

Less ‘Cowboy” Coding!

Having watched Mark Jaquith’s WordCamp San Francisco 2011 talk titled Coding, Scaling and Deploys – Oh My! I started to think this year long and hard about the process of development I went through for working on sites.

Mark’s key message in this presentation is to stop “Cowboy Coding” e.g. editing and uploading code on a live site and making sure that your code is in version control and also that you use deployment procedures to push your code live (no more FTP!).

After some bad experiences previously this message finally hit home. There is a difference however between the types of sites Mark is talking about in his talk and some of the sites I work on. I am not sure that the local Garage down the road would want to pay a premium of more than 50% the cost of their site just to have their code under version control and use a deployment service. It is a risk they are willing to take that their site is edited live with a maintenance page. Larger sites of course benefit from the methods that Mark discusses and it is these sites on which I have implemented these principles.

I have started to use Deploy HQ along with Github as Deploy HQ works well with code hosted on Github. Setting up both a Local, Staging and a Production (or live) environment as meant a much more professional approach the sites that need this. It has allowed clients to check concepts before pushing them live and means the process of running a site and evolving the code base is much more smooth. Combined with the fact that I had multiple contributors to the code this has completely changed the way I work, for the better and made me a much better WordPress developer.

WordPress for Building Web Apps

As part of working 2 days a week for a school building websites I was asked to construct a number of systems to help the senior management with tracking data, mainly for staff but also for students. I have seen a number of blog posts recently about using WordPress as the basis for building web apps rather than traditional websites and therefore I started researching. In the end I guess what I have created is a mix between a website and a web app but they do the job very well.

The first project was to build a system to store all the teaching staff’s Appraisals. This involved some backend changes to the WordPress admin in terms of a custom post type and some amends to make the dashboard easier to work around for line managers. The system allowed all line managers to appraise their appraiser’s logging their objectives and the actions to take in order to achieve them. It also allowed them to review and evaluate against these objectives at the end of the cycle when the set new objectives for the next cycle. Alongside this I build a number of query points for senior managers to use in order to be able to check if staff had similar objectives so that appropriate professional development could be arranged. I also integrated graphs to graph some of the data queried through WordPress.

The other large web application system I built using WordPress was a system to allow staff to log lesson observations of teachers. In the past this had all been done on paper and therefore tracking observations across department to see if trends occurred between teachers and departments was very tricky. Again much backend customisation was done in order to make adding Observations very easy for teachers. I am still working on the querying side of the project to allow managers to get an accurate picture on the level of teaching across the school but it is going well.

I always thought WordPress was a great system for building web apps and I now I know this is the case. With a built in user management system that is easily extendible combined with an easily customisable content management system in custom posts types WordPress makes a very good web application platform.

Responsive WordPress Sites

Responsive websites are the buzzword at the moment, and to a large extent that has to be accurate because of the massive increase in the amount of mobile traffic that websites across the world are receiving. Therefore it is essential that I grasped the concepts and skills needed to create responsive websites.

Although I understood the concepts for a while it was not really until this year that I actually got to grips with them on sites and produced some websites that were fully responsive.

Don’t get me wrong it can be a pain in the neck, but persevere and getting it right can be very rewarding. One site that I think went well in terms of responsive design was the work that I did for Pixel Junction on the Equal Adventure site.

WordPress for eCommerce

There are lots of plugin out there that enable you to turn your WordPress site into an eCommerce store, however I believe the really get a good eCommerce site, it should not just be an add-on but something that is designed and thought about from the start.

This year I started using WooCommerce and in fact I have built 3 or 4 sites using WooCommerce to power the shop part of the site. WooCommerce from Woo Themes is a very powerful and flexible tool that although I would not say is simple to get working as you want, it certainly is doable to any good developer.

With an eCommerce site it is a matter of experience in that the more you work with the site the more you learn this has a knock-on effect in that the more you learn the more you can learn.

These type of sites can be very frustrating but the more you work with them the better you are and more importably the more confident you will get with them. Therefore my advice for starting an eCommerce site would be to be brave, have a go and dive in with it. Perhaps not starting with a site for a client so that you can learn, but get a a plugin installed and practice with different scenarios.

So, to sum up 2013 has been a fantastic year for me personally. It has been a year of expansion, learning and producing a lot more sites and types of sites that I imagined at the start of the year. In fact is 2014 continues in the same way I am looking forward to the projects and sites that I will be able to tell you I have built this time next year.

Thanks to anyone that has helped me on Twitter or anywhere else for that matter. The WordPress community is what sets us apart from many others and roll on 2014…