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.

Week 6 status report

Whats been acomplished this week.

  • Started putting together a linux box for testing purposes, the VM was becoming rather clunky in performance, Slackware+Apache2+PHP5(module), also plan on doing PHP4 and hopefully safe mode on/off, and perhaps even PhPSuExec if i can manage them all.. I can handle Virtual Hosts OK, just not yet sure on how different PHP settings will work.
  • Removing Serialized data support, moving to XML.
  • Added Ajax loading of next page worth of Theme Search results
  • Started the Plugin Search interface
  • Cleaned up a bit of code.
  • Added a few filters/actions here and there
  • Few minor modifications of the Requirement checking

Plans for Next Week

  • Continue tidying up the plugin search pages
  • Add Plugin installation methods
  • Improve Filesystem handlers
  • start investigating what needs to be done to achieve a plugin/theme upgrader
  • Add more filters and hooks into the code
  • Start writing some documentation on the hooks
  • Start PHPDoc comments for the filesystem handlers(Only in the Direct filesystem class for now, the others are functionally the same) as well as any other functions.
  • Continue testing under other environments, If someone would like to do testing for me, get in touch.

Problems Encountered so far (And useful resources)

  1. PHP XML Functions contain no useful method to convert XML into a flat array simply, theres the option of several PEAR libraries, or simply using preg_match (Which i have done for now).
  2. Bug #3002 affected my only tester this week.. turned out to be the reason the last plugin he tried didnt work as well.
  3. The documentation which explains adding a hook into a plugins code is rather lacking IMO, It took me awhile to find something which could explain a action with multiple arguements, Infact, I think Ihad to do a grep over the WP source code in order to find something, Writing up documentation isnt my strong point, but IMO a good chunk of documenation needs to be written on the codex.
  4. Oh, and TinyMCE suddenly breaking into non-breaking spaces again, Someone got a plugin to strip out non-breaking spaces?, Else i’ll write one next week.

Week 5 status report

Whats been acomplished this week.

Mon:

  • Started working on “wp-Update-Manager”, a manager for Plugin authors who want to host the Update system themselves.
  • Changed the method that Requirements are checked in wp-Update, also a few small display changes

Tue:

  • Continued working on wp-Update-Manager, Sorting out weird JS Bugs.(more on this later)

Wed:

  • Wp-Update-Manager: Can return a Serialised array containing update information for any defined plugin.
  • Wp-update: Handles the update text logic better now
  • Wp-update: retrieving update information from custom defined source works OK (Plugin URI: http://…./)

Thu:

  • Wp-Update: Fixed a bug with the comparison of Versions
  • Wp-Update-Manager: Slugs not name in url.
  • Wp-Update-Manager: Added a table of Update URI’s.
  • Wp-Update: Major Fix: When running with “short tags = On” you would be greeted with a nice Fatal Error Syntax notice.. oops, all my dev. machines have it turned OFF (And so should you!)

Fri:

  • Wp-Update-Manager: Fixed a few JS bugs
  • Wp-Update: Added more comments, reviewed the function layout.
  • Wp-Update: Added support for checking if a PHP Extension is available, Implemented a stupid search for version functions from that extension to determine if compatible.
  • Wp-Update: Started some work on the Plugin search UI.
  • Started the ball rolling with getting a data access method into wordpress.org

Plans for Next Week

Hopefully finalise the API, Get some API/hooks into the plugin to allow extra manipulation by other plugins and what not.

Continue with the Documenting of code (PHP Doc commenting), possibly start work on plugin install proceedures(Should use most of the Theme installation code, so shouldnt be that hard).

Investigate bbPress a bit more, I had someone enquire about the possibility of adapting my plugin to work with bbPress, From what i can see it’ll require writing another front end for it, but other than that, it should be possible to re-use all the back end code if i continue into that. Of course at a latter time i’ll be wanting to test with WordPressMU as well.. i’m not sure if theres any major differences that would need to be taken into consideration there.

Problems Encountered so far (And useful resources)

  1. The JQuery tabs plugin cant handle tabs being dynamically added.. Wrote my own version for another plugin i’m working on, Copied it intowp-update
  2. Realised the Tabs JQuery plugin i wrote cant handle multiple tab sections on a page, Added a namespace holder to each tab group.. Started looking ugly at that stage.
  3. Attempted to work out how to create a custom permalink; Custom Queries (Codex) came in useful there..
  4. Ran into a bug with register_activation_hook(), traced it back to plugin_basename() not working on Windows Systems, Turns out its a 11 Month old bug(#3002), Apply the changes from another ticket #4408 and submited a diff back to #3002
  5. More JS Bugs; Remember, Do not create multiple divs with the same ID… JQuery doesnt like it.
  6. Need to work out how to encue jQuery for a single subpage rather than globally into every option page. (check $pagenow, and then check $_GET[‘page’])
  7. Locating the function to create a slug, For future reference, its sanitize_title_with_dashes() no mention of “nicename” or “slug” to be found :)
  8. Completely unrelated to this report, But, Whats the go with TinyMCE breaking out into non-breaking spaces randomly? dont like having to copy-paste to word, do a find replace, and then copy back to code view..

Note: Week 4’s status report was Null and inserted at the end of Week 3’s.

Week 3 status report

Whats been acomplished this week.

Wed:More Filesystem code was written; Specifically find_base_dir() for the FTP class, It should allow the class to find the installation directory on _most_ setups..

Thu: Using the file_base_dir() ftp function i can now install themes via FTP(Using exact same code for both Direct and FTP access), Can also provide a custom base dir in the options panel.

What i’d like to accomplish next week

Complete my Exams :)

As for on the GSoC project, i’ll start to complete what’s been sitting there for the past 2 weeks needing to be done..

EDIT: Week 4: Nothing was done, Exams took priority. Week 5 is now starting, and i’m back up and running.