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.]

Virtual Multiblog and WordPress 2.6

This is an important note to anyone using my Virtual Multiblog system for WordPress:

WordPress version 2.6 is going to be released very soon. Until I have had time to test Virtual Multiblog on WP 2.6, I recommend that you not upgrade WordPress past 2.5.1.

I’ve always said that the VMB system is quite future-proof, “unless WordPress makes significant changes to wp-config.php”. Well, WP 2.6 allows users to change the location of that critical file, and the wp-content folder. Either one of these changes may have ramifications for Virtual Multiblog.

Hang Tight folks. I’ll test it out and let you know.

if somebody daring does take the plunge, I would appreciate any problem reports. :)

Paged Comments for WordPress “Sandbox” Theme

The page for my Virtual Multiblog system has grown to contain over 200 comments, which, while gratifying, makes for a long load time and a lot of scrolling. Yesterday, I noticed on Ozh’s web site that he has paged comments, which means the page only shows some of the comments at a time, with links to the rest that are familiar to anyone who’s ever used Google: « 1 2 3 …9 »

A quick email later and I was checking out Keyvan’s Paged Comments plugin. Though a little unpolished, (e.g. settings via file edit rather than an Admin screen), it works very well, and I quickly got it running on those pages with lots of comments.

It didn’t take long for me to realize that the comments looked radically different than they had before. I use a restyled version of the (very) popular Sandbox theme on this blog, but the plugin didn’t have a template for Sandbox.

So I made one. :)
Read More »

Anti-Spam “Quiz” beta test

In the last couple weeks I have been working on a significant update to Andy Skelton’s Quiz plugin for WordPress. Andy gave me some feedback, which led to further fixes, and I think it’s working pretty well.

As of this morning I have turned off the Spam Karma plugin, which has been protecting this blog from comment spam1 for a few years now. In its place I have activated a beta version of Quiz.

What the plugin does is add a question to the Comments form, which must be answered correctly before a comment is submitted. You can set a default question, set a different question per-post, or choose for a particular post to not have a question.

This is pretty close to a release version, I think, but I would appreciate some feedback from the community. It requires (I think) WordPress 2.5.

You can download it here: Quiz 1.1 beta 5

Note: If you have been using Andy’s version 1.0, the Q&As you have entered previously should still work, but you will have to re-enter your settings on the new admin page (no more editing PHP files). Also, rather than using pseudo-shortcodes, you now enter the Q&A in a regular meta box on the Edit Post screen. If there is demand, I may restore the ability to continue using the shortcode method, but for now it is gone.

[Update: If upgrading from 1.0, you must deactivate it and reactivate once to set the default preferences.]

1: I am, however, still running Bad Behavior as well.

Give your WordPress plugin credit without cluttering the GUI

In a previous post I discussed the idea of locating your plugin’s Settings screen where it made sense within the Admin menus — giving an example of my own pull-quotes plugin’s Settings going under the Design menu. I briefly touched on a further aspect of this, when I suggested that authors not make their plugins scream “This is a plugin!”

A massive neon Holiday Inn signI’m sure a lot of people reading that first thought “But wait! I put a lot of time into my plugin — I want people to know that it’s a plugin!” So we end up with an admin screen titled John’s Comment Filter Plugin 3.2 or worse, a “mystery meat” menu item that doesn’t identify what the plugin does at all1! That first example is somewhat like having a store with a giant flashing neon sign up front — it certainly gets the information across, but it’s not all that attractive, and very obtrusive on the surrounding landscape.

I admit that we’re riding a line here — we all want credit for our hard work; but awkward plugin integration, spread out over multiple plugins, can end up making WordPress itself look awfully kludgy. Our blogs, and our plugins, deserve better than that!

So, we’re looking for a way to give credit where credit is due, while maintaining a clean integrated interface that looks as though it were a part of WordPress from the beginning. First, name the menu item for what the screen is for, not what the plugin is called. Ditto the page <title> and header. By way of example, my pull-quotes plugin is called “JavaScript Pull-Quotes”, but the Admin screen is under Design -> Pull-Quotes, and the page title and header read “Pull-Quote Settings”. The menu item and page header do not have to match the name of the plugin!

Okay, so… what if you still want to show the plugin name, and maybe have a link back to the plugin’s homepage? Simply allow your eyes to drift downward to the bottom of the admin screen…

screenshot

There’s the name of the plugin, the version number, and a link back to the home page; but it’s discreet and unobtrusive — it looks as though it belongs there. The information is there if you’re interested, but it doesn’t get in your way if you’re not; giving us a good balance between giving credit and keeping the GUI clean. Of course, if enough plugin authors start doing it on all their plugins, people will come to expect that bit of extra info, and that little slice of screen real estate will be as good as gold.

Here’s how I do it:

  • Within the function that creates the content of the Admin page itself, put the following line (probably best at the very beginning or very end of the function):
    add_action( 'in_admin_footer', 'myplugin_admin_footer' );
    

    This attaches a function to the page footer that will insert our attribution text.

  • Then of course we have to add the footer function itself:
    function myplugin_admin_footer() {
    	$plugin_data = get_plugin_data( __FILE__ );
    	printf('%1$s plugin | Version %2$s<br />', $plugin_data['Title'], $plugin_data['Version']);
    }
    

That’s pretty straightforward — all we’re doing is outputting a line of HTML — but I should point out a couple of things. First, we’re wrapping it in an if() and checking against $_SERVER['REQUEST_URI'] because we don’t want our plugin’s attribution showing up on every page. (Of course, you’ll have to change the URL string in that if() so it’s right for your particular page.) You can use in_admin_footer to insert anything you like, of course, but in the interests of creating something resembling a standard, I hope you consider sticking to the format I give above. (One alternate that comes to mind, however, is that some people might prefer to use something like “Comments Filter Plugin | Version 3.2 | By John Smith”. Go for it. :-) ) I definitely recommend the <br /> at the end of the text you’re inserting — otherwise it will be clumped on the same line as the existing text, which will look cluttered and will diminish your own plugin’s attribution.

We’ve just torn down the ugly neon sign, and replaced it with an engraved brass plaque next to the door. Not too bad, that. In the longer run, this is something that might be nice to roll into core WordPress code, which would really make it a consistent standard. Until then, it’s quite easy to give your own plugins credit in a way that cleanly and elegantly integrates with WordPress.

[Update: Ozh improved upon my code a bit by moving the add_action() into the function that creates the Admin page itself. It simplified things quite nicely, and the code above has been adjusted accordingly.]

[There are updates to this topic here and here.]

Previously: Use Action Links to direct users straight to your WordPress plugin’s admin page

Coming next: Consolidating your plugin’s settings so you don’t clutter up users’ wp_options tables

1: I didn’t originally intend to name names, but a good example jumped out at me recently. Under the “Manage” menu I have an item called “pageMash“. Quick (no peeking!) — what does it do??? It’s an amazing plugin, by the way, just poorly integrated in the menus.

Use Action Links to direct users straight to your WordPress plugin’s admin page

I’ve recently come across repeated discussions (especially on the wp-hackers mailing list) debating where plugin authors should place their custom admin pages. I discussed that question directly in my previous post, and basically stated that the plugin’s admin page can go any number of places, depending on what the plugin does. Some people disagree with this argument, saying that all plugin admin screens should go under one menu — usually “Settings” or “Plugins”, depending on whom you ask.

While I disagree, they do raise one good point: many end users will have trouble finding your admin page because they have come to expect such pages to all be dumped under Settings. Many plugin authors solve this by hard coding a link into the plugin Description, but this really isn’t the right place for that, and it can create inappropriate clutter in certain situations1. There is a better way.

WordPress 2.5 makes it fairly easy for plugin authors to add “action” links to the Plugin Management screen, like so:

Screen shot of a "Settings" link next to the normal plugin "Deactivate" link
Read More »

On Plugin Design and Integration

A frequent question on the wp-hackers list (a mailing list for people who write both WordPress core code and plugins) is where plugin authors should place the Admin screens for their plugins. A majority seems to say they go under the Settings menu; while a not-insignificant number insist that they should all be under the Plugins menu because, duh, they’re plugins.

My take on this is quite simple: From the user perspective, plugins should be invisible. That is, the fact that such-and-such part of the interface was made by a plugin should be invisible. The best design for a plugin is to seamlessly blend into the existing interface so that someone who didn’t already know would not realize that that thing there is not part of the basic system.

Therefore, if you have a plugin that has something to do with managing plugins, go ahead and put the screen under the Plugins menu. If it just has a basic settings screen, put it under Settings. If the screen lets the user manage something, then “Manage” is probably the right place.

I have a plugin that lets people easily put pull-quotes into a post. The admin screen for that plugin allows people to set options that control what the pull-quotes look like. Therefore I put the screen under “Design” (”Themes” in WP < 2.5) because it's primary function was to control the appearance of part of the blog. The Design menu is where it made the most sense.

So: Don’t make your plugin scream “this is a plugin” to the end user. If it were going to be part of core WordPress, what menu would you expect the screen to be under? Put it there.

(On a related note, the header on the top of your plugin’s page should not say “Such and Such Plugin” — it should just say “Such and Such”. I’ve seen some otherwise wonderful plugins made so that the header on the admin page is the file name. Yuck!)

Coming up next: How to put a direct link to your plugin’s admin screen on the Manage Plugins page.

Virtual Multiblog v2.3 for WordPress

I’ve released a new version of the Virtual Multiblog system for WordPress.

Version 2.3 is mostly under-the-hood improvements, but it might fix some of the issues people have. Additionally, I’ve made a few updates so it fits more seamlessly within the WordPress 2.5 Admin section.

I’ve also managed to abstract the optional Multiblog Support plugin to such a point that after this update you may never have to update it again! All plugin functions are now within the /multiblog/ folder, so changes down the road will happen within the main VMB system files instead of the separate plugin file.

Go get it, and Enjoy! :)