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.
This entry was posted in GUI Goodness, Webcraft and tagged , , , , , , , , , , . Bookmark the permalink.

5 Responses to On Attribution and Plugin Priorities in WordPress

  1. kahi says:

    Then… it’s nothing more easy than write a plugin that will hide the whole crazy footer. :-)

    (Btw, check your tabindex in the comment-form. ;-)

  2. Stephen says:

    Well, yeah, but I write all my plugins to automatically re-unhide all footers. :`

    RE the tab order — the Quiz plugin is experimental (beta). That field is actually re-positioned via JavaScript if it isn’t manually placed in the comment template. I’ll have to see if I can fix that somehow.

  3. Kevin says:

    It’s not clear (or I’m not smart) how to keep it from appearing on every admin footer, if you DON’T need it to. I only want it to show on admin page(s) dealing with my own plugin, but the code from the first post puts it everywhere. This post seems to tell me how to “demote” it but not to remove it from irrelevant admin pages. Can you clarify?

  4. Kevin says:

    We’ll stick with the “I’m not smart” option ;) Thanks for explaining that for me.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>