All articles from: August, 2009

Running a WordPress Plugin, always…

As seen on my local WP development environment

As seen on my local WP development environment

Sometimes you’ve created a site with WordPress standard (not single user), but have had allow the site owners or users to have full admin access to it.  You have plugin and theme dependencies, and if the site owner disables that plugin, you have problems.

For example, you’ve written a plugin that carries out a certain range of syndication functions for your client.  If the client accidentally disables it he will lose money, and you will have a call-out, potentially an angry one, when he finds out.  He wants admin access, but you know he’s dangerous with it.

So, since WordPress 2.8 you’ve had the facility to create a folder in wp-content called mu-plugins.  It will work just like the mu-plugins folder in WordPress MU – as in, any plugin placed there, will run automatically.  Activation code won’t fire off, but apart from that, so long as the plugin is correctly written, everything will work.

I’m not sure if this change is a part of allowing ‘must-use’ plugins support, as suggested in http://core.trac.wordpress.org/changeset/10737 or if it’s also planned as part of the move towards merging WP single user and WP-MU.  Either way, it’s an incredibly useful tool for those of us who set up and configure sites for clients who are a little prone to fiddling.

Watch out for plugin updates – you can’t auto-update anything in mu-plugins, and you won’t receive any notifications.  Be aware that you have to stay on top of this by yourself, just like in the old days!

Categorised as: Wordpress

WordPress 2.8.4 Released

wpbug

Slightly broken code, now fixed.

Those who follow WordPress closely will understand that a vulnerability has been found that, whilst not being especially dangerous, could be very annoying for some – especially for high-profile blogs.

By using a specially crafted URL, it’s possible for an attacker to force a reset of the admin password.  The attacker can’t know this admin password, it will be a random string, and this password will be e-mailed to the administrator of the blog.  However, there’s no denying that this could be annoying to the administrator.  More specifically, an administrator could be locked out of a block while some other exploits are tried, simply by resetting the password at short intervals.

So, it’s not the end of the world, but it’s an annoyance and in a few rare cases a potentially dangerous one.

To fix this vulnerability in older versions of WordPress, such as 2.7, you can manually change wp-login.php using the code shown in the Changeset on the WordPress Trac: http://core.trac.wordpress.org/changeset/11798 – ideally, you should upgrade to the just released WordPress 2.8.4 but if you have legacy reasons for staying with 2.7 (and many have, for example problems with widgets) then you may need to delay this.

Categorised as: Wordpress