Introducing: “TwentyTen: Remove Max Editor Width”

(Download Link)

The new TwentyTen WordPress theme is a pretty awesome theme if you ask me. Written by decent people who know what they’re doing (Unlike many other themes out there — Which whilst shiny on the outside, can be a rabbits nest underneath).

The theme only has one problem to me — and as i’ve noticed, to some other people as well. Infact, Its annoying me right now, just writing this post.

So, What is it?

Its the limitation of limiting your TinyMCE (Thats your visual text editor on the New Post screen) window to 640px. It does have some uses, but for someone like me, just writing text, and not caring about the benefits; can be downright annoying.

Oh, I nearly forgot, It also applies to fullscreen mode. So for people with a 1200px wide monitor.. well.. you get the idea (If you dont, it means, your post will be using the left most 53% of the screen). This is actually a limitation of TinyMCE not being able to distinguish between inline and fullscreen edit modes to be fair, but is still a PITA all the same.

Do try and use it yourself however, I quite like it for aligning images, but not for general purpose posts..

So, Whats the benefit exactly?

Floating images. When was the last time you were writing a blog post, and tried to insert an image, then hit preview, and found it was in a completely different place than you were expecting? And that the text was flowing badly around it? Well, this allows you to have a preview of how the actual post WILL look right in the WordPress new Post administration panel. Pretty cool in general, a downright pain to others.

So, What can i do about it?

I’ve written this short (Seriously, Theres more comments than code in this plugin) plugin which allows your editor to regain its innermost full content width.

You can download the plugin from the WordPress.org repository Here. But since the plugin isn’t actually live yet (awaiting creation) you may download it HERE instead.

Revision Control 2.0 Beta

The time has come for a Beta release of Revision Control 2.0. Would also like to announce that I’ve Cracked the 20k downloads on a plugin! currently its standing at 417,141.

Download 2.0-beta Now. Download POT file for Translations

Things to note of this release:

  • Fully rewritten from scratch
  • Better support for multiple post types
  • 100% api usage, less chance of breaking something
  • Revisioning of Categories and Tags (Well, Any taxonomy really!) – One limitation, It doesn’t restore this, thats for the next Revision :)
  • WordPress 2.9+ only.

Compatibility with older releases: I’ve not 100% tested backwards compatibility, That will come this next week, For new users, you’ll have no problems, for existing users, you should be warned that your settings may not be remembered, more testing needs to happen to verify that it works in 100% of cases.

If you’d like to submit a Translation of this plugin, or encounter a bug just send it along to wordpress@dd32.id.au

Thank you to all,
Dion

EDIT: Release Date: 24th Jan 2010 – approximately.
EDIT2: Updated the POT and .zip locations, There were a few translation issues.

Nearly there… Revision Control 2.0

Revision Control 2.0 is nearly here.

A quick list of changes:

  • Fully rewritten from scratch, Will require WordPress 2.9+
  • Better support for custom post types (Will make much more sense with 3.0!)
  • Support for Revisioning of Taxonomy data ( Doesnt restore at present, Mearly revisions it)
  • Many small bugs removed from previous versions

Features in the pipeline (2.1?)

  • Restoring of Taxonomy Revision Data
  • Support for Metadata revisioning (Custom fields, Post thumbnail, etc)
  • Delete all revisions from Admin UI (Or potentially, cleanup so theres only 5 revisions for each post for example)

This seems like a small list, but for a small plugin, its actually a rather large ammount of work to get through.. If you feel like testing it out, Please do, You can download it from here: http://downloads.wordpress.org/plugin/revision-control.zip

Some of those 2.1 features may be in 2.0, It depends on how much time i have amongst other things in life, and how much testing is required.

Translators: Sorry, But i dont have a list of your email addresses to contact you directly.. I’ll be setting up a GlotPress installation for this sort of thing i think :) Feel free to take the langs provided and update them.. I may remove the old ones entirely shortly..

To those of you using some of my other plugins which have been lacking in updates, Most will be recieving a rewrite this year, hopefully in the coming months – But i do not have the time to give any definites here, Some will not be touched. Add From Server is the next on the list however!

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