The tests were done with ACFW Version 0.82 and WordPress 3.0 (Beta 1).

For more information about the widget, check out my wiki.

The wiki is located at http://athena.outer-reaches.com/wiki/ and is accessible through the ‘Wiki’ option in the menu at the top of each page.

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.

So, you’ve been careful, you’ve downloaded the security scan plugin from Semper Fi Web Design and you’ve followed all the advice it provides… your blog is nice and secure. Although you may not now be able to login as administrator, but thats a different problem which took out one of the blogs I look after and, from the looks of the posts I’ve read, several others… anyhow, thats a story for someone else to tell… unless you’re desperate and you can’t login to your blog, in which case, do a search for force-upgrade or force-update, as that fixed it for me and allowed me to login as admin (although some other users have reported that whilst that worked, it didn’t restore their admin rights… there are posts around about that too). Anyhow, I digress…

The advice from Semper Fi about securing your blog includes securing the wp-admin folder so that authentication is required to execute the PHP scripts it contains. Great advice, unfortunately, what they don’t do is give a good example of what to drop in your .htaccess file to protect your wp-admin directory. So, if like me, you have half a clue (we’ll come onto the missing half shortly), you’ll run a search and find either the information you need to secure it or an example. You’ll implement the change and everything will be sweet… or so you think.

Time will tick by and one day you’ll want to post an update which includes some media… you’ll try the flash uploader which used to work, and it will suddenly ask you for authentication… you’ll suddenly remember that you’ve updated WordPress (a couple of times), and what else have you changed???? I can’t remember… what could be causing it… ARGH!!!!

Then you’ll remember the authentication fix you added to your .htaccess file, you’ll pop the username and password in there, but still nothing… no matter what you do, it won’t work. And that brings me to that missing half a clue.

The flash updater struts it’s funky stuff by calling a script… that script is protected by our .htaccess mod that prevents unauthenticated users from accessing it, and for some reason, the authentication doesn’t appear to work. The answer is to modify the .htaccess file to include a bypass for the script used by the uploader.

So, to get the flash uploader working again, drop this on the end of your .htaccess file that protectes the wp-admin directory.


<Files async-upload.php>
Order Allow,Deny
Allow from all
</Files>


Once I did this, and regained my missing half clue, my uploader was fine again. Lets just pray there are no security holes in that script.

And for the record, let me be 100% clear, I’m not slagging off the security scan plugin. Overall, it’s great, but it does suggest you tighten up the security on the wp-admin directory but then fails to provide a good example of how it’s done (or at least, at the time of writing I can’t find a good example they provide) and I’ve had it knacker one blog and prevent the admin from logging in when it did the database table rename (admittedly, the config file wasn’t writeable but that not being writeable and the administrator losing their admin rights… I fail to see how the two are linked). That did cause me a major headache, but overall, the plugin does a great job, but some aspects of it are a little flakey, but it is still under development, so hopefully they’ll get all the little teething troubles sorted. Then it will be a fantastic plugin.

And just in case you are looking for a complete example of securing the wp-admin directory…. here’s my .htaccess file (suitably tweaked to keep somethings secret).


<Files ~ "\.(php)$">
AuthUserFile
AuthType Basic
AuthName "Athena's Pad - Admin Area"
Order Deny,Allow
Deny from all
Require valid-user
Satisfy any
</Files>
<Files async-upload.php>
Order Allow,Deny
Allow from all
</Files>


So, to use this, create .htaccess in the wp-admin directory, drop this into it. Provide the full path to your the password file (see the Apache documentation about htaccess and creating password files for information about creating them) and that should be it… for obvious reason, your password file should not be accessible via the webserver.

I have a few plans for things I want to include in version 0.6 but I’m a bit tied up with work and one or two other things at the moment. As soon as my current urgent commitments are finished, I plan on knuckling down and getting 0.6 finished off and released.

The problem was that under certain circumstances, the widget failed to display the information linked to a particular page. It was caused by other widgets using the $post variables. Thanks to James Collins for highlighting this after he put the widget below the recent posts widget and found it didn’t display anything.

Get the latest version here or upgrade it automatically using the plugin manager.

Apologies to anyone who has downloaded it and is now using it, but version 0.3 had a couple of issues that I desperately wanted to fix.

First up, when the plugin is deactivated, it deletes it’s configuration… not great when you use the automatic updates… so, for upgrading to version 0.4 I highly recommend a manual upgrade. I’ve tried deactivating the plugin on my development blog and the changes appear to work as the configuration is still there once it’s reactivated. Feedback would be appreciated if you have problems with this as I want to get any issues like that nailed early on.

The other thing I wanted to fix was the lack of a .POT file. I believe the one that’s now provide is up to scratch. If not, again… feedback is appreciated.

I should also give a shout out to Jacob Santos for his information about the uninstall hooks in WordPress 2.7 (available on his blog at http://www.santosj.name/2008/general/wordpress-27-plugin-uninstall-methods/). Unfortunately I found his example of the uninstall file didn’t work and I had a nightmare getting it to work, so here’s the one from ACFW.

<?php

if (defined("WP_UNINSTALL_PLUGIN")==TRUE)
{
	if (current_user_can(activate_plugins))
	{
		delete_option("widget_adv_custom_field");
	}
}

?>

http://wordpress.org/extend/plugins/advanced-custom-field-widget/.

But I just noticed that I haven’t sorted the translation code out! DOH!!! So, if you download it and expect it to be capable of being localised, I’m afraid it’s not at the moment. I’ll see if I can get it sorted this week.