How To Solve WP-Cron Job Errors Caused By WordPress Hosting

Want to know how to solve WP Cron Job errors caused by WordPress hosting? It’s actually easier to spot and fix than you might think. And just five minutes resolving the issue can make a big difference to the performance of your WordPress website, usability and search engine optimisation.

Whether you need to change your wp-cron.php settings will depend on your internet host. Some hosts will disable it from running due to resource usage and legitimate security concerns. For example, Heart Internet. Others I know that encourage manual cron jobs include InMotion, Hostgator and many more.


What Are WP-Cron Job Errors:

You can spot if you have any WP Cron Job errors fairly quickly. If you look at your website, or the list of pages visited in your analytics software, do you ever see urls with ?doing_wp_cron= followed by a string of numbers?

So for example

If so, that indicates that you currently have an issue. Especially as those urls will be duplicates of existing articles.


What is a WP-Cron Job And Why Does It Fail:

WordPress uses a file named wp-cron.php as the way to scheduled automated tasks. For instance checking for updates, sending emails and automated tasks like backing up. It’s a virtual cron job which is triggered whenever a scheduled task is due to run, which can be either due to someone visiting and generating an automatic email, or having your back-up set to run on a regular basis.

So when someone lands on any page on your WordPress site, the wp-cron.php file could fire up and check whether it needs to send anything

On many WordPress hosts, this will run as intended. But some disable this functionality from running because it means that large visitor numbers can fire the virtual cron jobs a lot of times, using up the resources on your server. It’s also a potential security vulnerability.

For example, this site is hosted by Heart Internet, and their default setting is to have wp-cron.php disabled.


What Problems Do WP-Cron Errors Cause?:

There are two issues which can be created by wp-cron.php not working as intended. The first is that plugins and functionality which relies on cron jobs may not work properly, or might generate errors. So that includes things like scheduled posts, but also a lot of plug-in functionality for tasks like automated back-ups, auto-generated emails etc.

The other issue is potentially worse, as you may not spot it until you go looking. By creating a duplicate of your article with the same url gaining ?doing_wp_cron on the end, essentially you end up with at least two versions of every WordPress post you create.

That obviously has big implications for SEO, as search engines definitely do not like large-scale duplicate content. Even more annoying is the fact that the redirects and canonicalisation it causes will point to the duplicate version, rather than the original. So you’ll generally find your pages will be dismissed from search engine listings, and you’ll have a large number of 404 and soft 404 errors listed in Google Search Console or Bing Webmaster Tools.

Essentially it makes your legitimate site look like an effort to spam search engines. As well as potentially causing people to link to your duplicate version, minimising the benefit of getting an external website link.

So basically, it’s not good. Fortunately the fix is relatively quick and painless.


How to Solve WP-Cron Job Errors Caused By WordPress Hosting

To fix the problem, you just need to follow 3 simple steps.

  1. Disable the wp-cron.php from firing when someone visits your website.
  2. Set up a manual cron job to run on a set schedule. If you run multiple sites on one server, then stagger the times to avoid firing everything at once.
  3. Redirect the incorrect urls so that they point to the article addresses you actually want to rank, and stop confusing search engines.


1. How To Disable wp-cron.php

So first we need to stop that pesky wp-cron.php from causing any more problems. This is relatively simple once you’ve accessed the wp-cron.php file which is part of your WordPress software.

You can get to the files in your WordPress install via your hosts CPanel controls, although I prefer to use an FTP client to log into the server. With most hosts, you’ll need to log into the CPanel to unlock ftp access before using the details they supply in whatever FTP software you prefer. Personally, I’ve used Filezilla for years with no issues as it’s free, open source and frequently updated.

When you connect with Filezilla, you’ll generally see a default WordPress install puts all your files into a folder named Public.html. Open that and within the list you should find your wp.config.php file. This controls specific functions of your website, including cron jobs.

Click to view and edit. And before you do anything else, save a copy in notepad or similar just in case anything goes wrong. If you forget, you’ll either need to find the example listed on or reinstall WordPress.

You should see some text relating to your specific installation, and then:

/** Database Charset to use in creating database tables. */ define(‘DB_CHARSET’, ‘utf8’);
/** The Database Collate type. Don’t change this if in doubt. */ define(‘DB_COLLATE’, ”);

Underneath that text, simple add the following line:

define( ‘DISABLE_WP_CRON’, true );

You may seem some advice suggesting using define( ‘ALTERNATE_WP_CRON’, true ); as a solution, but every describes it as ‘a bit iffy’, and I’ve never found it to work yet. And the extra time for replacing the disabled version is only a couple of minutes more…

2. Set Up Your Manual Cron Job

For this step, you need to set up a manual cron job to run via your hosting company cPanel rather than relying on WordPress. This may be located in different places depending on your host – for example, Heart Internet list Scheduled Tasks under Web Tools. Wheras for InMotion you can find it listed as Cron Jobs under Advanced.

You then need to enter the script to run. For Heart Internet use:
/usr/bin/php5 /home/sites/yourdomainnamehere/public_html/wp-cron.php

And the space between php5 and /home is intentional! You’ll need to use the version of PHP your site is running on for it to run. For example, if you’re using php7, then you’ll need:

/usr/bin/php7 /home/sites/yourdomainnamehere/public_html/wp-cron.php

You should then be able to test it and if it’s correct, you’ll see the following pop up:

Solve WP-Cron Job Errors Caused By WordPress Hosting

‘The page at says
Your script returned the following:
X-Powered-By: PHP/5.2.17
Content-type: text/html’

InMotion, for example, recommend using the following, and replacing userna5 with your cPanel user name.

cd /home/userna5/public_html; php -q wp-cron.php

If there’s a problem, the first thing to check is the PHP version you’re using.

The only other thing to set is how often you want the manual cron job to run. Generally, you could run it every 6 hours for a low traffic site, or every hour if you have a more popular site. Either way, it’s going to actually work, and you can adjust the frequency if your hosting company alerts you to increased server usage (or you can check the server logs to preempt any warnings…)

So now we have the cron job issue fixed, as per existing advice and guides online.

But actually there’s still a big problem. We still have potentially thousands of duplicate pages floating around, and the confusion for search engines trying to find the right ones to list in search results.

For one site I left to test, the number of incorrect pages being visited had jumped over the last couple of months to be almost 50% of the total pages viewed on the site! Definitely not good.

Fixing WordPress Cron Usability and SEO Issues:

So to reconcile the right urls for users and search engines, we need to direct them to the right pages.

We could do that manually by individually redirecting each error. For instance, you could use a plugin like Redirection and go through everything listed in Google Analytics (or at least anything getting a reasonable amount of traffic).

That’s not the best use of your time though, and there’s a far better way.

Fire up your FTP client again, and this time you’re looking for your .htaccess file in your public.html folder.

When you select view and edit, you should see something like:

# Switch rewrite engine off in case this was installed under HostPay.
RewriteEngine Off


DirectoryIndex index.php

 BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

All we need to do to redirect every example of ?wp_doing _cron is add a rewrite for it. I’m no expert in creating rewrite conditions, so cheers to Rob Hughes from for his assistance with this…

You just need to add:

RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron=[0-9]+.[0-9]+(&|$) [NC]
RewriteRule ^ %{REQUEST_URI}? [R=301,L]

For example:

# Switch rewrite engine off in case this was installed under HostPay.
RewriteEngine Off


DirectoryIndex index.php

#Rewrite Wp Cron Errors:
RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron=[0-9]+.[0-9]+(&|$) [NC]
RewriteRule ^ %{REQUEST_URI}? [R=301,L]

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

The # indicates something which is there for your notes, rather than something which is part of any condition. So #Rewrite Wp Cron Errors: is a useful reminder of what that bit was added to do, particularly if I want to go back and remove it after switching WordPress hosting, or need to find it to copy across for another site if this post and my notes all mysteriously vanish.

Now you should see that when you visit one of the old urls with ?wp_doing_cron, it should automatically 301 Redirect you to the correct url. You may find that analytics/search console add your website name again after the first / in a url, so just remove that before testing as it’s a slight glitch in logging the data, rather than yet another alternate.

Not only does this mean that your users will now end up at the right place should they visit the old duplicate url. It also makes it clear to every search engine which one is the correct url, and which one is a load of old rubbish they should ignore. And by using a 301 redirect, if someone has linked to the duplicate url from their website, you pass approximately 70% or so of the value of that link to the right place, rather than losing it all.

OK, so that quick and simple solution has now resulted in 1,700 words. So here’s the quick version:

Troubleshooting WP Cron Errors:

When this hasn’t worked, there are generally a few reasons I’ve discovered:

  • Using the wrong PHP version in the code for the manual cron job
  • Reinstalling or using a .htaccess file which has ( ‘ALTERNATE_WP_CRON’, true ); in it. This has to be removed from your .htaccess file. Otherwise it can mean the final redirect doesn’t work, and you geta  500 server error every time you try and visit your website.


The TL:DR WP Cron Fix Summary:

  1. Turn off any existing wp-cron.php tasks by adding define(‘DISABLE_WP_CRON’, ‘true’); to your wp.config.php.
  2. Set up a manual cron job via the cPanel control for your host. E.G /usr/bin/php5 /home/sites/yourdomainname/public_html/wp-cron.php in Heart Internet’s Scheduled Tasks section.
  3. Redirect all the duplicate rubbish urls to the right ones by adding
    #Rewrite Wp Cron Errors:
    RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron=[0-9]+.[0-9]+(&|$) [NC]
    RewriteRule ^ %{REQUEST_URI}? [R=301,L]
    into your .htaccess file.
  4. Use one of the old duplicate ?wp_doing_cron urls to check it is now redirecting correctly.
  5. Repeat for all WordPress installs that might be affected on that host.
  6. Feel smug you can now solve WP-Cron Job Errors Caused By WordPress Hosting


WordPress Update Error: Download failed.: Failed to write request to temporary file

We currently manage around 35 WordPress installations and websites for a variety of clients and my own projects. I originally started using WordPress for my own websites around 10 years ago, and over time I’ve arranged a range of hosting, themes and plugins that I know I can trust.

When I recently updated to the latest version of WordPress, I received the following error message: WordPress Update Error: Download failed.: Failed to write request to temporary file.

Strangely it only occurred on one of my sites from the 35 I updated, and it’s a site which has run without issue for several years. It’s an error message I couldn’t remember seeing before, so it was time to do some investigating. And it’s why I’ve written this post as a reminder if it occurs again.



WordPress Update Error: Download failed.: Failed to write request to temporary file

The error message appears when you attempt to automatically the core WordPress files, plugins or themes on the affected website. There’s no other information to accompany the message, and it appears there are various ideas as to what may cause it. The most common reason given is that the WordPress update will place temporary files in a directory on your server which isn’t specific to WordPress. That’s normally limited in terms of space by your website host, and it appears that a full temporary file may trigger the error.

Generally old files should be cleared out of the folder automatically, but that doesn’t always happen. So over the course of time, it can become full.

However there are some questions about this – contacting my website host for that particular site via support indicated that the temporary folder was only 5% full. That may have been because I’d completed the required updates via a workaround (details below), but it may indicate there’s another issue.

The other suggestion is a server configuration issue which means it’s not set up to properly use a temporary folder, which also makes sense. It could occur on an existing site if something has been changed by your website hosting provider for that particular server.


Fixing Failed to write request to temporary file:

So there are several things you can try:

  • Check whether there is any issue with space on your server or via your cPanel account.
  • Clear out the temporary directory of any files you know are no longer required.
  • Check and alter the user permissions for the WP-Content folder via your cPanel to have chmod 755
  • Edit the wp-config file to add a new line of code.

It was editing the wp-config file that immediately solved my own issue.
Two important things to note:

  • Before you make any changes or delete anything, it’s best to back things up. Some of the files in your temporary directory may relate to website stats software or have other uses which means you’ll need to keep them.
  • If you’re adjusting user permissions or editing your wp-config file, it can be a security risk, so make sure you switch them back afterwards.


Server Space and Set-Up:

Even if you can access your temporary folder (e.g. /tmp) via ftp, you may not be able to actually edit or delete anything. Particularly if you’re on shared servers (the most common set-up for lower priced hosting, including for most blogs etc). So you’ll need to contact your website hosting provider or raise a support ticket.

I pick my hosting based on the speed and quality of their product and their customer support, so I had a reply within an hour on a Sunday morning. But as the WordPress update was security based (and I tend to be a curious fellow), I didn’t want to wait while they responded, so I moved onto the next step.


WP-Content chmod 755:

The chmod setting controls who can Read, Write (delete and add folders) and Execute (run scripts) to folders on your website. Generally by default you want to have access to change things without letting anyone else make edits. Which is why generally your WP-Content folder should be set to chmod 755

To check, log into your website hosting provider, and navigate to your File Manager. Generally you’ll be able to see your chmod settings there and change them if necessary. One suggested solution is to temporarily change the WP-Content folder to chmod 777 which allows anyone to upload to it – obviously this is a massive security risk, so if you try this, change it back afterwards immediately!


Edit WP-Config:

So, first you need to open up your File Manager in your web host cPanel, or get into your site via ftp.

Locate your wp-config.php file.


It should look something like the following, with the name of your Database in it:

* @package WordPress

// ** MySQL settings – You can get this info from your web host ** //
/** The name of the database for WordPress */ define( ‘DB_NAME’, ‘database_name_here’ );

/** MySQL database username */ define( ‘DB_USER’, ‘username_here’ );
/** MySQL database password */ define( ‘DB_PASSWORD’, ‘password_here’ );

/** MySQL hostname *
/ define( ‘DB_HOST’, ‘localhost’ );


All you then need to do is add the following, before the MySQL details:

define(‘WP_TEMP_DIR’, ABSPATH . ‘wp-content/’);


So it will look something like:

* @package WordPress
define(‘WP_TEMP_DIR’, ABSPATH . ‘wp-content/’);

// ** MySQL settings – You can get this info from your web host ** //
/** The name of the database for WordPress */ define( ‘DB_NAME’, ‘database_name_here’ );

/** MySQL database username */ define( ‘DB_USER’, ‘username_here’ );
/** MySQL database password */ define( ‘DB_PASSWORD’, ‘password_here’ );

/** MySQL hostname *
/ define( ‘DB_HOST’, ‘localhost’ );

Then just save, close, and try to run your updates again.


When it’s all fixed:

When all the required updates have run, make sure you reset any changes to your chmod permissions, and also remove the line of code from WP-Config.

Even if you’ve managed to solve the problem via those workarounds, it’s worth contacting your website hosting provider to see whether the /tmp file needs clearing, or if there’s a server configuration problem. Otherwise you’ll need to go through making the changes for every update in the future, and it’s very easy to accidentally leave your modified wp-config file live after the umpteenth update.


Security Update for Jetpack WordPress Plugin

Joining the news of the Heartbleed vulnerability that affects much of the internet, and a security update for WordPress itself, now comes the news that there is a critical security update for the Jetpack WordPress plugin.

Jetpack 2.9.3 contains a fix for a bug which allows an attacker to bypass access controls and publish posts, which could be combined with other attacks to escalate access. It’s existed since the release of Jetpack 1.9 in October 2012, and as yet there is no evidence of it being used in the wild.


However, now it has been made public, you need to make sure your site is updated asap – the team behind Jetpack have been working with hosting and network providers to reduce the problem, and have made updated releases for all 11 vulnerable versions of Jetpack from 1.94 through to 2.9.3.

So if you’re running Jetpack on one or more of your sites, make sure you’re either updating it now through your WordPress dashboard, or visit the Jetpack site to manually grab the updated releases and install the appropriate one for your website.

WordPress Automatic Updates – Good or Bad?

Automatic updates were introduced to WordPress with the 3.7 Basie release, but the debate about them has been re-ignited as they recently came into effect for a large number of users who found their websites moved from 3.8 to 3.8.1 without any prior notification.

As much as I like and respect his WP knowledge, I’m forced to disagree somewhat with Rhys Whynne’s article, which says they’re an unqualified good thing, and side with the view he references from Marj Wyatt. The way that automatic upgrades have been implemented without any easy controls for website owners means that many people will need to either install an extra plugin or add code manually to stop their sites from being changed without their knowledge.



WordPress Auto Updates: The Benefits

There are several positives to having automatic upgrades for security reasons and minor releases. The first is that many, many people around the world are using outdated versions of WordPress and associated plugins which is a major security risk for them. Outdated software is a great way to invite hackers to easily get into your site, particularly if it allows them to use widely accessible and known vulnerabilities which can be hit in bulk.

And having worked with the large number of sites we develop, host and manage for clients, I can say that most are updated infrequently at best.

It also means that users aren’t paralysed by fear when given the option to upgrade. It also saves the cost of paying for anyone to simply have the confidence to perform a site back up and click yes to upgrade (Which is why we’ve always installed auto-backup tools for clients).

In terms of connectivity, even if the WordPress server has issues during the upgrade process, it won’t affect your site. If it fails, the site falls back to the normal state anyway.

And although I personally like to have as much control over any software updates and upgrades, in terms of trusting the intentions of WordPress, I’m more comfortable with an open source and fairly open organisation having the right aims than many of the other software platforms and products we all use on a daily basis.


WordPress Auto Updates: The Problems

So why wouldn’t I just recommend everyone lets Automatic Updates do their job?

Firstly, there is an ownership issue. Although I accept Rhys’s point that auto updates will reduce security issues for which WordPress could incorrectly be blamed, the fact is that the websites being updated are not the property of WordPress, are not on WordPress owned servers, and aren’t the responsibility of WordPress. Unless they’re also intending to come and help if I make a mistake while I’m tweaking some CSS as well?

But more importantly from a day-to-day practice is that minor updates can have major consequences. Although plugins and extensions should be designed and built in a way which means minor updates don’t affect them, that’s asking third party developers to predict the future. And the further you extend WordPress, the more risky it is.

Plus the time, resource and financial cost of ensuring everything is working can be problematic. It requires every third party supplier to be ready for every beta test and notification of an impending update, and to be able to test every single product they list prior to the update occurring.

Having worked with plugins like Jigoshop, that means not only the Jigoshop core plugin, but potentially checking tens of themes and hundreds of extensions, which have been created by a large number of suppliers.

The majority of people involved in that project, and many others, are making that effort, but it takes time and co-ordination – with an almost infinite combination of hosting, server setup, conflicting plugins and extensions etc.

And when we update a site, we always schedule it for the time which causes least disruption to site owners and their customers. That’s difference for every business, so there’s no way for WordPress to achieve this without looking at the website analytics for 1 million+ websites at a time.

That’s why I believe it’s wrong to have introduced Automatic Updates without any manual controls for a user or administrator which don’t require either coding or installing yet another plugin.


WordPress Auto Updates: Our Advice

One thing we can all agree on – make back ups of your site often. Rhys recommends once per day, which we’d recommend for sites which are critical to you and your business, although it’s really a question of how much you’re prepared to loss in a disaster versus the cost of storage space.

If your site is fairly simple, using core WordPress functionality and a handful of plugins, then Auto Updates are pretty much fine. For instance, I have no issue with having them enabled on as it’s a personal blog with very few tweaks or plugins.

If your site is complex, and uses substantial plugins or extensions, then we’d recommend turning off Auto Updates, which is what we’ve done for various clients. We’re not willing to let anything be changed on those sites without the opportunity to test and double check it.

If your site access is essential for your business, then we’d recommend turning off Auto Updates. Although maintenance mode passes very quickly, you want to be able to experience any issues at a time when you least disrupt customers and you’re on hand to fix any issues, rather than while you’re in a meeting, on holiday or sleeping.



WordPress Auto Updates: Turning them off

There are two ways to re-assert your control if you want to disable or restrict the automatic updates. The first is to edit the code on your site, and the instructions are available on the WordPress Codex. The second is to use one of the various plugins which have sprung up to offer similar functionality, such as ‘Update Control‘.

So far we’ve yet to test the plugin options, and have installed the manual option across a range of client sites to avoid adding plugins which shouldn’t be necessary.  Essentially you’re then updating an additional plugin to cope with the update functionality WordPress introduced to avoid having to update so often.

Web Design: Creating a Favicon for your site

Launching or re-designing a website or brand involves a lot of work. Whether you’re doing everything yourself or outsourcing to an agency like us, there’s a big checklist of images and assets to be created and uploaded. That includes all the imagery required for social networking profiles, but often an important but small part of website branding can be overlooked.


What is a Favicon?

A Favicon is the name given to the image which appears in locations relating to your website, such as an internet browser. It generally appears at a small size, just 16 x 16 pixels in the address bar and browser tab. But it’s important both in terms of usability for people to navigate to the right place when they have multiple tabs open, and also for branding and recognition.

If you’re using various popular CMS systems or website frameworks, you’ll also find that their developers use their own favicon by default, meaning that you’ll look less professional until you create your own – in the meantime you’re advertising their software and also displaying to customers and competitors what you’re using.


Favicon examples from TheWayoftheWeb, and

The good news is that any designer or developer should be aware of the need for a favicon. It’s certainly something we provide as a matter of course. It’s also relatively simple to create and upload for yourself if you are following a DIY approach or fancy making some changes.


Creating a favicon:

To generate your favicon you can either use any graphics or image editing software, or there are various online tools such as, or Dynamic Drive.

We use either Photoshop, or the free, open source alternative, GIMP to create the image. Generally we start with a 64 x 64 pixel square to make it easier to edit and avoid issues when scaling down. Then when we’re happy, we’ll adjust the image size to 16 x 16 pixels.

It’s important to remember how small the favicon will be when displayed in a tab – in the case of this site, we considered that our logo was more important and recognisable than reworking the site logo to be bigger. The same held true for our gaming site, but I don’t have a logo for my personal blog, so I decided to pick my initials.

If you’re looking for inspiration, just take a look at what your favourite sites use.  When designing website assets for clients we’ll include the favicon as part of the package, along with website logos, social media images etc.

When you’re happy with your work, you just need to save the result as favicon.ico. (It’s listed in GIMP as ‘Microsoft Windows icon).


Uploading your Favicon:

Some CMS systems, such as Magento, allow you to upload your favicon directly. All you need to do is visit System > Configuration, and then look under General to find Design and the HTML Head section.

For WordPress various plugins exist to offer similar functionality, but it’s actually fairly easy to upload your new favicon yourself. That way you avoid adding extra software to your site, and having to download updates etc, for the sake of a task you might only ever do once every few years.

After creating a favicon.ico and saving it to your desktop you’ll need to login to your website hosting either via your website host and any FTP manager they provide, or via your own FTP Client (e.g. Filezilla).

First navigate to the Theme you’re currently using for your site, and when you can view all the related files, remove the existing favicon.ico file and upload your creation.

You can also upload an additional copy to the main directory of your site, e.g. to ensure the icon also appears in RSS feedreaders and other locations.

Finally if you want to be compatible across some older internet browsers, you may also wish to edit the header of your page.

  • Go to your WordPress Administration Panel.
  • Click on Appearance.
  • Click on Theme Editor.
  • Select the file called Header or header.php to edit the file.
  • Search for the line of code that begins with <link rel=”shortcut icon” and ends with /favicon.ico” />. Overwrite it, if it exists, or add the following code below the <head> HTML tag.
    <link rel=”shortcut icon” href=”<?php echo get_stylesheet_directory_uri(); ?>/favicon.ico” />
  • Save the changes

And that’s it. When you’re making code changes, we’d recommend using a copy of the existing code and making sure you have a backup in the case of any problems.

You should start seeing your new favicon fairly quickly, although sometimes it can take some time to display due to various cache settings – generally more modern browsers are faster.

WordPress 3.7 released, including Automatic Updates

WordPress 3.7 is now available to install for all users. It’s codenamed ‘Basie’ for Count Basie and includes a number of new features, with the most notable one being automatic updates for maintenance and security updates. The full details are available in the Codex on the site.

There are some additional great new features, including:

  • Better password recommendations, as it will now detect common mistakes which can weaken passwords, such as dates, names, keyboard patterns etc.
  • Better global support for localised version of WordPress and language files for translations.
  • Improvements to Search.



Automatic updates: Some benefits, some risks:

Currently the Automatic Update function is purely for maintenance and security updates issued by WordPress, which will mean that most sites are now able to automatically apply these in the background, with additional security checks and safeguards now in place. It’s disabled if you need to use FTP for updates and requires your credentials, or if you’re using SVN or GIT.

So basically the majority of self-hosted WordPress sites will be able to run automatic updates.


The benefit is that a lot of WordPress sites can go weeks, months or years before the administrator will update them to the latest version of WordPress, which is a big security problem. Generally security and maintenance releases are tackling exploits which can or have been used maliciously, so by not updating regularly, you’re leaving a big invitation to anyone attacking WordPress installs, particularly when they are probing sites en masse.

If you’re using a non-English install, Language Packs should also be automatically updated.

Currently, automatic updates won’t be enabled for major releases, themes or plugins, so those updates will still need to be enabled manually. If you wish, you can enable automatic theme and plugin updates with some code changes.


There are some issues which cause us some concern regarding automatic updates.

  • There is no way to turn these on, or off, without editing code in your wp-config.php file, which not everyone is comfortable doing (Although we’d urge anyone to backup everything properly, or to create a test site, and then have a go).
  • Security and Maintenance patches may cause conflicts with existing themes and plugins. In addition, other fixes may sometimes be included in these releases.
  • Lack of scheduling for updates – given the potential for disruption with any update, we make sure we implement them at times which are less critical for our clients, particularly with regards to eCommerce etc. With automatic updates running in the background, you won’t know when your site will be updated, and have no way to direct it to be at a convenient time. For instance Basie appeared late on Thursday night UK time, so potentially we wouldn’t discover any conflicts until starting work Friday morning.


Our recommendation:

For non-business critical WordPress sites, we’d suggest that you upgrade to WordPress 3.7 and enjoy the automatic updates. Certainly I’ve updated my personal site straight away to test and explore Basie and check how it all works.

The potential risks for most sites from automatic updates are probably much less than the risk of being exploited for running a massively out of date WordPress install.

For anything relating to business, including all our client sites, we’ll be disabling automatic updating for the following reasons.

  • We already monitor and quickly update WordPress versions, themes and plugins upon releases and testing to confirm they won’t break any existing sites or functionality.
  • We need to ensure that any new versions do not impact on increasingly complex functionality, such as eCommerce platforms.
  • And we need to make sure that when we’re updating business critical sites, we’re doing it at a time when there is minimal disruption in the event of any problems. Generally updates go fine, take a few seconds, and the site is back. And if there are any problems, we can always roll back straight away to the backup, but we’d rather keep any disruption away from peak business hours.

If you do want to disable automatic updates, then the details are included in this comprehensive guide to Automatic Core Updates by Dion Hulse. The simplest way to disable it is to add define( 'AUTOMATIC_UPDATER_DISABLED', true ); to your wp-config.php file

WordPress 3.6 is now available

The latest version of WordPress, which is version 3.6, is now live with some new functions and features. As always, we’d recommend backing up your site before starting any upgrade procedure, which is a process we undertake for many of our clients.

The release, codename ‘Oscar’ is covered in this video produced by WordPress:


Features for WordPress users:

For general users and authors, the main features of the new release are:

  • New Twenty Thirteen default theme.
  • Revamped Revisions to save every change with a new interface
  • Post Locking and Augmented Autosave to allow saves by authors and taking over post editing when more than one author is working on an individual post.
  • Built-in HTML5 media player for native audio and video embeds.
  • Improved integrations and oEmbed support for Spotify, Rdio and SoundCloud.
  • Easier Menu Editor.

Developers also benefit from a new audio/video API with access to metadata like ID3 tags, HTML5 markup for more elements, better filters for revisions, and a long list of additional changes.


We’ve already updated this site to 3.6 and some other test sites, and haven’t experienced any substantial problems. But it will depend on the plugins and frameworks you are currently using, so please do make sure you back up before updating, especially if you don’t have regular backups already taking place.

Make sure you upgrade to WordPress 3.5.2

WordPress version 3.5.2 was released just before the weekend. We’ve already advised all clients to upgrade, along with making sure all of our own sites are running the latest version, as 3.5.2 is an important security release.

The new WordPress version fixes 7 security issues, and also contains some additional hardening measures, which is important given the recent spate of brute force attacks on a huge number of WordPress sites. The majority of attacks focus on basic defaults and outdated software, which is why it’s so important to stay current.


Security Fixes in 3.5.2:


  • Blocking server-side request forgery attacks, which could potentially enable an attacker to gain access to a site.
  • Disallow contributors from improperly publishing posts, reported by Konstantin Kovshenin, or reassigning the post’s authorship, reported by Luke Bryan.
  • An update to the SWFUpload external library to fix cross-site scripting vulnerabilities. Reported by mala and Szymon Gruszecki. (Developers: More on SWFUpload here.)
  • Prevention of a denial of service attack, affecting sites using password-protected posts.
  • An update to an external TinyMCE library to fix a cross-site scripting vulnerability. Reported by Wan Ikram.
  • Multiple fixes for cross-site scripting. Reported by Andrea Santese and Rodrigo.
  • Avoid disclosing a full file path when a upload fails. Reported by Jakub Galczyk.

As always, you should back up your site before any upgrade, and your update is likely to include changes to the database. If you’re struggling with WordPress, give us a shout and see if we can help!

New Facebook Open Graph tags for writers and publishers

You may be familiar with the Author and Publisher tools which Google+ offer to websites, and now Facebook has added some additional tools for publishers, journalists and writers to boost their content on the social network.

The new Open Graph tags were officially revealed yesterday, and are as follows:

  • article:publisher lets a publisher link an article to their own Facebook page. When the article is shared in News Feed, a “like” button is displayed so people can like the publisher page.
  • article:author lets a publisher link an article to the Facebook profile of the author. When the article is shared in News Feed, a “follow” button is displayed so people can follow the author. The author needs to have Follow activated on his or her profile for this button to appear.

They are coded as follows:

<meta property="article:publisher" content="" />

<meta property="article:author" content="" />

This means ‘Follow’ and ‘Like’ buttons will appear for those who haven’t already followed the author or liked the Publisher page, when that content crops up in their newsfeed.

The Facebook announcement includes this example:

Example of Facebook Publisher and Author Open Graph tags

So well worth implementing to make the most of your visitors sharing your articles and content on social networks.

The BBC, Facebook and ‘The Supermarket Effect’

With the BBC unveiling a new homepage and Facebook rolling out a whole raft of new features, the predictable ensuing uproar at change is taking place.

Back in 2008, I wrote about what I termed ‘The Supermarket Effect‘ when launching a new design or features on an existing site. As Hugh McLeod once memorably illustraed – ‘Technology Changes, Humans Don’t‘. And I’m not sure the business/media owner approach to unleashing their latest effort to guess what we all want has changed much in the last 3 years, either…