WordCamp Melbourne 2011 went off

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:

Disable Automatic upgrades for a customised plugin

Update, for WordPress 2.8+: Please be advised that any mention of option_update_plugins(and friends) hooks will not be fired. This is due to the new Transients in WordPress 2.8. You’ll need to use the transient_update_plugins(and friends) hook instead. preferably both for 2.7 compat. – See http://groups.google.com/group/wp-hackers/browse_thread/thread/a12f70d6b649c917 for some background.

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:

image1

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,

  1. Disable the upgrade notice entirely
  2. Remove the ability to do core upgrades
  3. Display a different notice instead
  4. 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:

[sourcecode lang=”php”]
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;
}
[/sourcecode]

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:

[sourcecode lang=”php”]
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;
}
[/sourcecode]

image3

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:

[sourcecode lang=”php”]
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>’;
}
[/sourcecode]

image4

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:

[sourcecode lang=”php”]
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>’;
}
[/sourcecode]

image5

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 :)

Week 8 status report

Whats been acomplished this week.

  • Redesigning the Filesystem Options page.
  • Localised more strings
  • Improved Requirements Checking
  • Load jQuery via Add_action(This has made the plugin 2.3-only)
  • Prevented Prototype from loading on my pages(Fixes Incompatibilities when a plugin loads Prototype for the entire Admin console)
  • Started moving all external-access functions (Searching, Info, etc) into separate files and loading via filters/actions
  • [From trac patch] Hide edit column completely when plugin not editable
  • Re-designed some of the options page for filesystem.

Note: Not all of the above is checked into SVN yet, expect in the coming days.

Plans for Next Week

  • Finish more work on the options pages.

Problems Encountered so far (And useful resources)

  1. Visual jQuery

Uni semester is starting up again, Business units, PHP/Perl, Java, should be fun..

Week 7 status report

Whats been acomplished this week.

  • Integrated the Plugin Search page with the Plugin Installation pages
  • Added a few filters/actions here and there
  • Plugin installation page checks requirements before installing plugins(If requirements are available from wordpress.org)
  • Started the ball rolling for the wordpress.org integration server side.
  • A Few misc. other things.

Plans for Next Week

  • Improve Plugin Installation methods
  • Improve FS options (And the Options page for it)

Problems Encountered so far (And useful resources)

  1. #4639 came into play this week, in short, the “admin_print_scripts-plugin_folder/plugin.php” doesnt fire if the plugin is in a subdirectory.. Was found as the issue while looking into westi’s comment here: gsoc-week-5-status-report#comment-52

This week was a rather slow week development wise, and this blog entry is running late too, Hopefully next week there’ll be more to report on.