JavaScript Pull-Quotes 2.1.1 for WordPress

A new version 2.1.1 is up. Among the changes:

  • Increased efficiency of version checking
  • Fixed a small bug with the admin footer
  • Significant cleanup of Style selection code
  • Moved Default style to resources folder so it can’t be misplaced
  • Significant error checking RE missing or renamed styles
    • If chosen style is missing, falls back to default rather than linking nonexistent file

Two notes if you’re upgrading from an old version:

  1. You may discover that the Styles dropdown in the Settings screen now has two items called “Default”. If so, go into /jspullquotes/styles/ and delete Default.css — you don’t need it anymore.
  2. There has been a change to the way the Style setting is saved. It should auto-update existing settings, but if it doesn’t work you may find that your chosen style has reverted to the default. If so, simply go into settings and re-save with the style you want.

As of 2.1, JavaScript Pull-Quotes is fully compatible with WordPress 2.6.

Go get it!

On Attribution and Plugin Priorities in WordPress

A few weeks ago I wrote instructions on putting a plugin attribution in the footer of your plugin’s Admin/Settings screen. It’s a good technique, and I’ve already seen a few plugins using it. I’ve noticed somewhat of an issue recently. This is nothing Earth-shaking, nor will it break anybody’s blog; it’s really just a matter of politeness. Fixing it, however, involves a simple, powerful, and frequently overlooked, feature of calling hooks and filters in your plugins.

The issue that came up is that there is a plugin using the footer attribution, but because the plugin affects every page of the Admin section, the author chose to put the footer on every page instead of just on the plugin’s Settings page. I don’t really have an issue with that — I do it myself with the Virtual Multiblog (”VMB”) system — but the main point of the technique is discretion, and if many plugin authors start adding attributions to every single admin page, things are going to get awfully messy. I can’t wait to have an admin footer eight or ten lines long!

So, I guess part one of this is an admonition: Think hard about it before deciding that your plugin rates a, er… plug throughout the entire Admin section. Maybe it does, but for the vast majority, it’s probably best to stick to just the footer on that plugin’s own page. (I do it with VMB because WordPress is running entirely on top of that system — it can affect everything WordPress does.) Also, if you do put it on every page, be brief. Don’t be chatty. (The VMB footer is two words long.) As I suggested in the original article, make it look like it belongs there.

The second part of this is a small change to the code if you are going to put it on every page: Set a later-than-default priority when calling the hook. Why? This one is a matter of politeness to other plugin authors. If another author is also adding an attribution to just his plugin’s page, your “every page” footer should come after it. (Also, it’s in keeping with the overall trend: Page Specific, then Whole Admin, then WordPress.)

The change will take you about three seconds. Ready? Change this:

add_action( 'in_admin_footer', 'myplugin_admin_footer' );

to this:

add_action( 'in_admin_footer', 'myplugin_admin_footer', 11 );

What we’ve just done is set the priority for that call. The default (if you don’t put any number there) is 10. By setting it to 11, we’re saying that it should come just after the default run of that hook. (We could set it lower than 10 also, but again, that would be kind of rude in this case….)

This is a subtle but excellent technique for plugins. It’s a good way to make your plugin compatible with another plugin* — setting your priority higher or lower so it runs before or after that other plugin (or as the case may warrant, convincing the other plugin’s author to do so). The general range for the priority is from 1 to 20. I’ve rarely set it anything other than 9 or 11 of I set it at all; though I’ve seen plugin authors set it in the thousands when they want to be really, really sure that it runs after everything else. (This of course can escalate into a rather silly “numbers race” — well, some other guy does his at a thousand, I’ll do mine at two thousand just to be sure. Hm… some other guy set his to two thousand — I’ll make mine ten thousand……..) The “exteme end” standard seems to be around 995-1000 in the plugins I’ve looked at. I wouldn’t go much beyond that. If someone else wants to make theirs an even million, that’s their problem.

So putting it all briefly: think twice before putting your footer on every page of the admin, and if you do, set the priority to 11 so that page specific footers will come first.

*: I remember an example of Plugin A specifically advertising compatibility with Plugin B. Both made CSS changes to the Admin, but the instructions for Plugin A said “To use this with Plugin B, open up that plugin’s file and change such-and-such code.” Some compatibility! I emailed the author and suggested setting the later priority, so that his CSS came later. He was very happy with the results, and his users didn’t have to edit files any more.

Javascript Pull-Quotes 2.1

I’ve just put up a new version of the JavaScript Pull-Quotes plugin.

Along with various bits of polishing up the code, 2.1 is fully compatible with WordPress 2.6. (Specifically, it won’t choke if you move your wp-content folder.)

Go get it!

Virtual Multiblog 2.4

Okay, folks. A user pointed out a recent bug that can prevent the VUSER from being determined correctly. It probably accounts for the vast majority of the “This isn’t working” reports we’ve been getting around here lately. Sorry about that.

So, if you’ve been having trouble getting the latest version to work, try version 2.4. It’ll make you smile. :)

One more thing — before you upgrade to 2.4, deactivate the Virtual Multiblog Support plugin. In fact, you can delete the thing — it is no longer needed. The system now calls that functionality automatically without the kludge of a separate plugin to hook in to.

One more one more thing — I still haven’t finished testing with WordPress 2.6, but I believe that as long as you don’t relocate wp-config.php or wp-content, it should work without problems.

Go get it!

Winna Winna Winna!

Look, Ma, I won somethin’!

Hmmm… “1 Theme of Choice from Blogalized.com“. Not too bad. I’ve been thinking about maybe sprucing the place up a bit….

Technical Difficulties…

A reader (or at least someone who tried to be one…) emailed me to point out that my site was down for a good portion of the day. To further the embarrassment, in place of my content was a PHP error message pointing a finger squarely at the Shrinkylink plugin that I just yesterday used as an example in a tutorial article.

I just wanted to put on the record that the error had nothing to do with what I described in that article, in which we turned version 0.2 of the plugin into a working version 0.3.

The error was in fact a small-but-significant oversight in the process of turning out version 0.4, which, beyond shutting me down for a few hours, you haven’t seen yet. Funny, it worked just fine on my local test blog — not sure why, actually….

I now return you to your regularly scheduled blog.

Consolidate Options with Arrays in your WordPress Plugins

If you’ve ever written a plugin for WordPress you’ve probably dealt with giving the end user options. Unless you’ve taken the low road and forced the user to directly edit the plugin file, “options” means a Settings screen in the WordPress admin, and most likely you are storing those options in the blog’s wp-options table. Over time, bloggers using various plugins can end up with hundreds of extraneous records in their options table*. If they ever stop using a plugin, or if they ever want to manually clear out options, this job can be made difficult by all the clutter, and the problem is made far worse when plugin authors add a new record for each separate setting in a plugin. Beyond the mess, plugins written this way generally make many more calls to the database than they need to, which adds unnecessary burden on the server.

I have seen and used plugins that added anywhere from ten to thirty new records to the options table, and a correspondent of mine reports that he has encountered a plugin that, upon activation, adds a whopping 140 new records to wp_options. Egad! There has to be a better way!

There is a better way. With a few simple changes to your code, plugin authors can put all the various settings into an array, and enter that array as a single record in the options table. This article will show you how.

On this site I use a plugin called ShrinkyLink. It performs the straightforward but useful function of shortening long URLs to a specified length, or replacing the link text entirely with a specified string. It was created by Andrew Rader, but as far as I can tell his web site no longer exists. For the purposes of this article, it has a number of good qualities:

  • It inserts 10 separate records into the Wordpress options table
  • It is not likely to see further updates from the original author
  • It is useful and thus worthy of updating
  • The original author was kind enough to release it under the GPL2 license

The last version of ShrinkyLink was 0.2, released in 2006. Today we’re going to begin the rehabilitation of this plugin and create a version 0.3 that stores all its settings in a single array.

I’m going to split this into multiple sections:

  1. How to set and retrieve settings using arrays
  2. Upgrading your plugin’s Admin Screen form to use an array
  3. Upgrading existing settings from multiple records to a single array

Let’s get to it.

Read More »

WordPress plugin attribution footer — update

In a recent post I showed how to put an attribution in the footer of your plugin’s admin screen. In the example I gave, I used a format of:

MyWidget plugin | Version 1.0

I have seen a few plugins already updated and using this methodology, but for the most part authors are adding a third bit of information to that string, namely, themselves.

MyWidget plugin | Version 1.0 | by John Smith

Another thing that has happened since I posted that is that Ozh came up with a better way to call the in_admin_footer hook. Rather than calling it during init and then having to keep testing to see what page is being displayed, he simply dropped the call into the function that creates the actual admin page. That way, it’s only ever called in the first place when the admin page is created. Nice improvement.

So in the continued interest of creating a relative standard, here’s an updated version of the footer plugin, including the author information:

function myplugin_admin_footer() {
	$plugin_data = get_plugin_data( __FILE__ );
	printf('%1$s plugin | Version %2$s | by %3$s<br />', $plugin_data['Title'], $plugin_data['Version'], $plugin_data['Author']);
}

Remember to take the add_action and put it inside the function that echoes the admin page. As a reminder, here’s the add_action that calls that footer:

add_action( 'in_admin_footer', 'myplugin_admin_footer' );

The original article is here.

…and to all the people in the USA who are (not) reading this tonight, Happy 4th of July! :)

[A further post on this topic is here.]