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.

Fixing_Wordpress_Error_Failed_Temporary_File

 

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.

 

WordPress 3.8.2 now available to download and install

The latest version of WordPress is now available to download and install. It’s an important security release which solves some important security issues, along with fixing a number of bugs.

WordPressLogo

The security list is:

  • Potential authentication cookie forgery. CVE-2014-0166.
  • Privilege escalation: prevent contributors from publishing posts. CVE-2014-0165.
  • (Hardening) Pass along additional information when processing pingbacks to help hosts identify potentially abusive requests.
  • (Hardening) Fix a low-impact SQL injection by trusted users.
  • (Hardening) Prevent possible cross-domain scripting through Plupload, the third-party library WordPress uses for uploading files.

There’s more information available in the WordPress Codex. If you’re already allowing automatic updates, the release will apparently install throughout the next 12 hours, or you can update manually now. As always, before any significant WordPress or plugin update, it’s always best to back up your site.

 

 

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-Automatic-Updates

 

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 www.danthornton.net 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.

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.

WordPressUpdate

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.

locks

Security Fixes in 3.5.2:

From WordPress.org:

  • 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!

How to import Posterous to self-hosted WordPress

With the news that Posterous will be closing on April 30, 2013, many people are now looking to export their content and start to publish on a different platform. We tend to always recommend self-hosting if your site is important to you and your business, partly because third-party services can close or change, and partly because it gives you a lot more control over backups.

WordPress is particularly suited to self-hosting, as it’s so widely used and most hosting services will offer a simple one-click install to get you up and running. The complications tend to come with adjusting the look and functionality to exactly what you require, and that’s certainly something we can help with.

So assuming you don’t want to move from Posterous to another third party service like WordPress.com, Tumblr etc, what do you need to do?

 

Setting up self-hosted WordPress:

To set up your site, you need 2 things. The first is your domain name, if you don’t have one already. The second is your hosting account, and for most sites this can be organised quickly for a few pounds per month.

If that is already filling you with fear, give us a shout as we run hosting a number of websites, including installing WordPress, setting up themes and plugins, and organising regular backups.

Once that’s in place, you’ll need to wait for the hosting to be up and running to allow you to install WordPress. Once that’s done, you can then transfer your content across. When that’s complete, the final step will be to change any existing domain names to point to your new site.

You now have 2 options for getting your content into your new site – one doesn’t require a Posterous export, but we’ll cover it anyway as it’s good practice to always keep a secure backup on your computer or an external hard drive.

 

Exporting from Posterous:

Log into your Posterous account, and you’ll see a bright yellow ‘BackUp’ button in the top right of the dashboard. Clicking on that will arrange for a backup to be created for export (You’ll need to wait a little while for it to be ready). Once it’s prepared, you’ll see a green ‘Download’ option which will export your existing content.

BadgerGravlingPosterousBackUp

This will let you download a Zip file which contains contains your content.

 

Importing into self-hosted WordPress:

Option 1: Using a Plugin:

There’s a useful Posterous Importer plugin available which will import posts, comments, tags, and attachments directly via the Posterous API. Simply go to the Plugins section of your WordPress dashboard, select ‘Add New’ and search for Posterous Importer and you should see it as the first result (Authors include Automattic, the company which runs WordPress).

Once this is installed and activated, you’ll then be able to go to Tools in your WordPress dashboard, select Import, and Posterous will now be a listed option.

Click on Posterous, enter the url of your current Posterous site, along with your username and password, and the import will begin when you click submit.

PosterousImport

Hopefully that will work for you nice and easily. You’ll then need to go through and check each post, amending author details etc as required.

If it doesn’t work for any reason, there is a slightly more complicated alternative.

 

Option 2: Importing via WordPress.com

If that doesn’t work, the other option is to use the importer created for WordPress.com, and then export from that version to your self-hosted site.

So you just need to sign up at WordPress.com (Which is the hosted version of WordPress). Once that’s done, look in the Tool section of your new site, and then click on the Posterous import option.

This method will now ask you to upload the wordpress_export_1.xml file from your Posterous export earlier. This will then be uploaded to your WordPress.com site. There’s a more detailed tutorial on the WordPress.com site, so I won’t repeat their instructions.

Once that’s done, you can then choose to export from WordPress.com. And then go to your self-hosted site, select Tools and the WordPress importer. Choose the .xml file to upload from your WordPress.com export, and you should be all set.

Obviously this version does include a couple of extra steps which are a bit of a pain, but could be useful if the Posterous API stops working prior to April 30.

 

Finishing off the process:

Finally, once all your content is in your new site, spend some time checking the author names, embedded videos and anything else which may have changed during the import process. If you’ve got thousands of posts, then start with any that you know are particularly popular!

If you’re mapping an existing domain name across to your new site, now’s the time to do it. If you want to keep the same url structure and avoid losing any links, you’ll need to go to ‘Settings’ and select the ‘Permalinks’ option. The default setting for Posterous appears to be ‘Post Name’, which displays as http://danthornton.net/sample-post/ for example.

Finally you can play around with the look of your site, and the additional extensions that are available to WordPress users.

49% of the world’s top 100 blogs are using WordPress

An interesting study released yesterday by Pingdom reveals that 49% of the top 100 blogs as ranked by Technorati are using WordPress as their CMS platform.

You can debate whether Technorati is still a decent ranking system, and it doesn’t include 8 sites for which information wasn’t available, but 40% of the sites with available information are on self-hosted WordPress (with 9% on WordPress.com’s hosted alternative). The article also has an informative list of what each of the top sites is actually running on – sadly TheWayoftheWeb just missed out on making the list, but for the record, I’ve been using self-hosted WordPress for a number of years now for pretty much all my sites (I do have one or two on both Blogger and Tumblr).

There are a number of reasons why I recommend self-hosted WordPress, including the fact that you have ultimate control over design, data etc, and as long as you’re backing up regularly, you’re better offer in the event of hosting/domain name failures.

It also gets increasingly easy to use – in addition to usability improvements to the core product, all the big third party theme providers and frameworks have made big steps in making everything quicker and easier to setup. Most of my sites currently run on the Genesis framework from StudioPress (aff link), but there are also great products I’ve been checking out from the likes of Headway and Pagelines, who are both offering drag and drop customisation.

More and more themes are now coming with responsive design as standard (meaning your site automatically works on mobile/tablets), and it’s really easy to find extremely talented designers and developers who are not only familiar with WordPress, but the relative ubiquity of it keeps prices fairly realistic. If you’re stuck for designers/developers I’m always happy to recommend several that I’ve enjoyed working with both on my own sites and client projects.

And that’s before you get into the various projects built on top of WordPress – for example, Jigoshop, a client of mine who produce a frankly amazing WordPress eCommerce solution. Not only can you install and set-up a fully functioning online store for free, but there’s an amazing range of extensions for it already which means your shop has all the services at a level you’d expect for a big online retailer.

And if you need some help, I can provide domain names and hosting, plus initial set-up for a low fee, having currently set up a number of sites for my own projects and for a range of friends and businesses, which regularly get many thousands of visitors each month, so feel free to contact me. I’ve also had experience of transferring sites from other platforms, and if you just want some quick tips, advice or reassurance, feel free to give me a shout!

Great job opportunity for UK Web Developers…

If you’re a UK-based Web Developer looking for a career with a brilliant and fast-growing company, then one of my clients, Jigowatt (creators of Jigoshop) , might have just the thing for you.

They’re looking for talented and experienced web developers to become a core part of the team, with the opportunity to become a core part of evolving the brilliant Jigoshop WordPress eCommerce product, and also the chance to work on a range of interesting projects for a growing number of clients.

You can read the full details on the Jigowatt and Jigoshop hiring here, but there are a number of things to consider that aren’t in the formal details.

  • The team are great to work with – all very talented, all very driven, and all nice enough that they can put up with me in the office. And there’s a great atmosphere in the office.
  • The company has existed for 3+ years and continues to grow at a good rate.
  • You’ll get a chance to choose what’s on the office stereo – at least when Chris isn’t at his desk and he’s left Spotify running.
  • Almost every day someone brings in cakes and biscuits, which is brilliant if you’ve overslept and missed breakfast.
  • And most importantly – as a free and open source project, Jigoshop is all about the amazing community, whether that’s the contributions made via Github, the designers and developers adapting Jigoshop for clients, or end users, and it’s a wonderfully gratfying experience to be able to help, support and encourage that community to achieve the best results. It’s what is really seperating the Jigoshop experience, and makes it a joy to work on.

I can honestly say that working with Jigoshop is one of the most fun things I’ve ever managed to get paid to do. So if you’re a web developer, you really should check out the ad.

 

Gentleman, we can rebuild him…

Today I have been mainly breaking things and fixing them again in the backend of this site and some of my others, hence why I’m currently running a bare bones implementation of the basic Genesis framework.

So far today I have:

  • Managed to break the free theme I was using, and finally decide to get a move on with redoing this site, so invested in full access to Studiopress themes – something I’ve meant to do for ages since starting out with their Metro theme.
  • Managed to recover all of the posts from 140char.com before it became just a link blog, import them into a fresh WordPress install, and then export them to be merged into this site. They’re now in, safe and sound, although I think most of the images will take some work to sort out manually.

That’s in addition to client work, of course.

 

Things left to do:

  • Update TheWayoftheWeb to the latest Mysql database as it doesn’t happen automatically on Godaddy, so I can’t upgrade to the latest WordPress until it’s sorted.
  • Decide whether to use a Genesis child theme, or start customising this one.
  • Re-categorise all 140char.com posts and permanently redirect the url to them for the small trickle of traffic still visiting it.
  • Sort all the images again.
  • Add all the usual widgets, ranking sites and other bumph which bloggers do to slow down their sites.

And then catch up on all my other sites, all my client work and collapse…

Client solves Ecommerce for WordPress via Open Source

I don’t often write about clients on my blog for various reasons, but I wanted to spread the word about Jigoshop, which is a great Ecommerce for WordPress solution that I’ve been working on for a couple of months now. One reason is simply that it’s a really good product which I can easily recommend – as part of research I played around with the alternatives and I can honestly say that I’d already decided to use Jigoshop to power a couple of future projects before working with them. And the other is that it’s one of the first times I’ve been working on a project which is delivering something via Open Source, rather than using OS products as an end user.

Jigoshop Ecommerce for WordPress

 

So what makes Jigoshop so good?

It’s worth explaining that the company behind it, Jigowatt, specialises in Ecommerce sites for a large range of clients, using both WordPress and Magento, so they’ve spent a lot of time working with all the existing ways to produce effective and attractive online stores, and have particular experience handling the backend admin side of getting lots of products uploaded and ranking in search for their clients. That means they’ve got a long list of all the features that they wish existed and eventually reached the point that they knew it made more sense to build something to answer all their problems.

It’s incredibly quick and simple to use – even I can get an online store up and running in about 20 minutes. But at the same time it’s also highly configurable when you want to get into setting attributes, localising your shop, and stock management.

 

The benefits of a true Open Source Ecommerce solution

I was lucky enough to start getting involved with Jigowatt and Jigoshop when they started discussing how to licence Jigoshop, and how they could try and ensure that it has the optimum chance of being the best possible product, and also how it can generate revenue to justify continuing to work on it alongside the masses of client work they’ve got at any time. They had already started discussing the open source model, obviously drawing from their experience with the likes of WordPress and other open source developments and plugins, and they’d also been open and honest on their blog about their ideas – which led to really helpful input from other WordPress plugin developers, for instance, comments and suggestions from some of the guys at RocketGenius, who make the great Gravity Forms solution.

I also whittered on about everything from the birth of the Free Software Foundation and Open Source to the business models used by the likes of Arduino, and slowly the shape of the Jigoshop business model emerged, which was to release the shop itself under a GPL licence.

  • That means that you can download it, get your store up and running, and take payments via Paypal without having to sign-up for a trial or submit a credit card.
  • And it means anyone can build on top of it, whether that’s additional features or themes etc.

The revenue streams are all around specific extensions to the main Jigoshop platform, whether it’s payment gateways or specific themes, as well as allowing donations. And that’s an approach I really hope works for this specific project, because I really want to see Jigoshop continue and evolve.

 

It’s not just me recommending Jigoshop

Obviously as a client, I might be a little biased, but the good thing is that absolutely loads of WordPress specialists and big independent sites have been giving positive reviews to Jigoshop, reinforcing the fact that it’s a really good product. Just some of the mentions since it launched include Mashable, ThemesForge, and Envato. And there’s a growing forum community on the site which is worth checking out.

 

So I figured there’s enough to justify writing about a client for once! And obviously if you’re interested in finding out more about the range of freelance content and marketing services on offer, then please do get in touch….