Last weekend was WordCamp 2011, Lots of things were said and done, there was an afterparty that not many talk about (and many suspect the organisers were still drunk the next day), and of course – there were talk from a lot of interesting people.
But of course, this isnt to write about those people, the events, or anything else, this is purely a post to post up a few things which I mentioned.
First part, My presentation: How to become a WordPress Surgeon: An introduction to WordPress Core Contributing. – in reality, it was decided 5 minutes before hand the content, so give me some slack :)
Direct Link: http://wcmelb.blip.tv/file/4826938/
Now the links I promised:
- Search and Replace – An excellent plugin for replacing text throughout WordPress, good for updating old links from other domains
- Core Control – A Plugin of mine which allows you to see inside a bit of WordPress, The main use for this today is determining which HTTP Transport is in use, and the ability to disable those which are malfunctioning.
- Theres another plugin which is useful when changing permastructures to distinctivly different structs, in most cases the canonical redirect takes care of it, but it’s not 100% perfect, I cant find the plugin, but Advanced Permalinks looks like it’ll do the job, But might not be compatible with 3.0/3.1, and might be overkill really.. but search the Permalinks tag on the extend directory and see what you can find.
And links that are just awesome:
Recently there was a question posted to the WP-Hackers list asking how to disable Automatic upgrade for a plugin, Since it had been highly modified.
I was going to post in some code for it, But well.. I’ve been busy. So instead, I’ve just decided to sit back and write it up here instead now that I’ve got a day off.
For my examples, I’m going to use eShop (Simply because it was the only plugin which needed an upgrade at the time of writing this!).
So, You’ve modified the Core files of eShop because it doesnt achieve what you want, Or doesn’t have filters on something, A few days later, Up pops a update notice:

Now, You don’t particularly want to Accidentally upgrade to the latest version and loose your changes, Or worse, a client upgrade and then complain it no longer works!
Now, Depending on the usage, Theres a few options and ways to go from here,
- Disable the upgrade notice entirely
- Remove the ability to do core upgrades
- Display a different notice instead
- Display a the update notice, And a reasoning for the removal
Disable the upgrade Notice entirely
This is quite straight forward really, And doesnt take much effort, Simply insert this tidbit of code into the plugins main file:
add_filter('option_update_plugins', 'plugin_prevent_upgrade');
function plugin_prevent_upgrade($opt) {
$plugin = plugin_basename(__FILE__);
if ( $opt && isset($opt->response[$plugin]) ) {
//Theres an update, So lets remove it.
unset($opt->response[$plugin]);
}
return $opt;
}
Simple enough?
Of course, This method has some drawbacks, The client (Or yourself) is not notified that theres an upgrade available for the plugin, Which could open yourself up to potential exploitation later down the line if a Plugin is found to have a vulnerability in it.
Remove the Ability for the plugin to use Automatically install updates
Much like the previous, Its rather simply to achieve this too:
add_filter('option_update_plugins', 'plugin_prevent_upgrade');
function plugin_prevent_upgrade($opt) {
$plugin = plugin_basename(__FILE__);
if ( $opt && isset($opt->response[$plugin]) ) {
//Theres an update, So lets remove the package to prevent automatic upgrades:
$opt->response[$plugin]->package = '';
}
return $opt;
}

Bingo, The upgrade functionality is disabled, Yet, Still notified of an update!
Of course, This might lead someone to question “Why cant i update it?”, Which is where the next 2 options come in handy
Display a custom notice
This mainly uses the code from section 1, But adds a bit of an extra step, Rather straight forward:
add_filter('option_update_plugins', 'plugin_prevent_upgrade');
function plugin_prevent_upgrade($opt) {
$plugin = plugin_basename(__FILE__);
if ( $opt && isset($opt->response[$plugin]) ) {
//Theres an update. Remove warning
unset($opt->response[$plugin]);
//Now we've prevented the upgrade taking place, It might be worth to give users a note that theres an update available:
add_action("after_plugin_row_$plugin", 'plugin_update_disabled_notice');
}
return $opt;
}
function plugin_update_disabled_notice() {
echo '<tr><td class="plugin-update" colspan="5">There is an update available for this plugin, However the plugin has been modified by XYZ Corp.<br />If you require functionality introduced with the new version, Please contact us for a quote to customize the new version of the plugin for your uses.</td></tr>';
}

Straight forward, Works well, Looks Ok-ish.. But isnt very helpful.
Disable automatic upgrade, And display a custom message
This is my favourite method, Which is why its been left ’till last:
add_filter('option_update_plugins', 'plugin_prevent_upgrade');
function plugin_prevent_upgrade($opt) {
$plugin = plugin_basename(__FILE__);
if ( $opt && isset($opt->response[$plugin]) ) {
//Theres an update. Remove automatic upgrade:
$opt->response[$plugin]->package = '';
//Now we've prevented the upgrade taking place, It might be worth to give users a note that theres an update available:
add_action("after_plugin_row_$plugin", 'plugin_update_disabled_notice');
}
return $opt;
}
function plugin_update_disabled_notice() {
echo '<tr><td class="plugin-update" colspan="5">There is an update available for this plugin, However the plugin has been modified by XYZ Corp.<br />If you require functionality introduced with the new version, Please contact us for a quote to customize the new version of the plugin for your uses.</td></tr>';
}

Looks Alright, And for a non-power user, The extra warning is not going to bother them (hopefully), You can add some custom code to allow users to hide the update if you wish, But i’ll leave that up to you. The only downside to this is that it takes up so much room, You can style it however you want of course.
Also, You might want to prefix those functions with something other than “plugin” :) don’t particularly want to end up with conflicts!
Please Note: The technique above will only work for an active plugin. If your customer is going to deactivate the plugin for some reason, You might like to hard-code the plugin_basename() and put the PHP in your theme instead, Remember, A Theme can do everything that a Plugin can (And more!)
Sorry for the lack of indenting in those code pieces, I cant work out how to get the plugin to preserve formatting :)