Speak the Web is a series of small, intimate, low cost web design & development events
It's the small things that make a big difference
Just a quick one for today and it’s another which is firmly wedged in the “geek” section – probably for site administrators, only.
On a recent project we were installing WordPress MultiUser (WPMU) and came across a very annoying and somewhat troublesome error whenever we tried to attach an upload to a post or page, or indeed directly upload something in the Library for each blog.
Using either the flash or normal uploader produced the same error:
The uploaded file could not be moved to the upload folder
After several fruitless hours trawling the Googles, we decided to have a cup of tea and a biscuit. They were hobnobs, if it makes any difference to you. They’re the SAS of biscuits. Then it dawned on us, there must be a problem with the way the files are being moved. When we tried to upload a file, the correct directories were being made – i.e. “/blogs.dir/3/files/2009/10/” but the files weren’t being transferred across. We’d read that it’s possibly a permissions problem or a file/folder ownership issue. All of the fixes that were suggested such as changing the owner to Apache or nobody didn’t work and neither did CHMOD’ing everything under the sun to 777 (which seems to be the defacto “something isn’t working, do this to fix it” answer).
We found that in wp-load.php the absolute path to your WPMU install is defined(and it’s then checked in wp-config.php and defined if it isn’t set). After some fiddling around we discovered that for our setup (which in this case was on OpenBSD by the way), this ABSPATH definition wasn’t working correctly.
We had to change the following in wp-load.php:
1 | define( ‘ABSPATH’, dirname(__FILE__) . ‘/’ ); |
to something like the following:
1 | define(’ABSPATH’, ‘/users/mylocation/sites/www.mydomain.com/’); |
Yes, we know it’s modifying the core and yes, we know that’s naughty. You could, realistically, probably just add this definition into your wp-config.php file, instead – but then you might run into “this has already been defined” problems in PHP.
Just to reiterate, we know that you should avoid hacking the core of WordPress wherever possible. However, sometimes, there just isn’t another solution. This does mean that when you upgrade WordPress you will almost definitely need to amend wp-load.php again. If you know of a better solution to this, then please, do let us know and we’ll share!
Comments (2)
Andrea_R wrote:
I’m just glad you found something that worked. :) I haven’t had it happen to me, so haven’t had a chance to figure out why it failed for some and not others.
I’ll just point people here. :)
FriendlyDesign wrote:
Thanks for the comment, Andrea. It definitely seems to be OS-specific with regards to which fix solves the problem. This one worked for us and hopefully it’ll stop other people losing quite as much hair as we did.