WordPress media library open_basedir error
Well, seems today is my lucky day for finding useful bits of information out about WordPress. Here’s the deal… you backup your site, move servers, restore everything and it all appears to work, BUT, when you go back and try and add an old image that you uploaded before you moved, it won’t display the image in the media library… instead you’re getting an error spouting something about security and open_basedir… if this is your problem… read on as I have a solution.
Disclaimer - This fix is not for the faint hearted. If you are not happy about executing SQL, then don’t do this.
In fact, this is more than a fix just for the open_basedir error message I mentioned. If you have moved your blog, its possible that this problem is affecting you too. Whether or not you receive the error message about open_basedir depends on the version of PHP you are using and the configuration of PHP on your server.
The problem is caused because items uploaded via the media manager in WordPress are stored in the posts table and some of their path data is stored in the postmeta table, so even though you change the upload path in the config file and the miscellaneous options, these paths in postmeta remain unchanged.
The net result is, that when you move your blog to another host, if the OS/server is configured slightly differently, the paths that WordPress uses for locating the thumbnails for the uploaded images are drawn from postmeta which of course was created on a different host so the paths are different.
Now, ordinarily what might happen is the system will point the thumbnail at the full size image and have the browser scale it, BUT, with PHP 5 and it’s enhanced security, PHP might attempt to open a file which is in an area that you aren’t supposed to access. If this is the case, you’ll probably get an error message about trying to open a file outside open_basedir (or words to that effect) and instead of getting the thumbnail and options, you’ll get nothing except the error for that item.
The only way I’ve found to fix this is to run a bit of SQL against the database which corrects the now erroneous entries in postmeta.
UPDATE
wp_postmeta
SET
meta_value=concat('/var/www',right(meta_value,length(meta_value)-length('/home/httpd')))
WHERE
(meta_key="_wp_attached_file") AND
(instr(meta_value,'/home/httpd')>0)
This is the code I ran. You will need to adjust this, but what this does is looks for all postmeta records which have ‘/home/httpd’ at the start of them (this is the part of the old path which is different). We then update them by trimming off the ‘/home/httpd’ (done using the right(meta_value,length(meta_value)-length(‘/home/httpd’)) function) and sticking the new path component ‘/var/www’ on the front (done with the concat function).
So, in the postmeta table, all _wp_attached_file records that have /home/httpd at the start, have that replaced with /var/www, making them correct once more.
Tags: WordPress
