Insert the following into your theme files where you want the plugin’s widget to appear:

<?php my_plugin_widget() ?>

The slightly more intelligent instructions will understand that the plugin might be deactivated, and suggest you wrap the function in an if() that checks for its existence:

<?php
if ( function_exists( 'my_plugin_widget' ) ) {
	my_plugin_widget();
}
?>

In your own plugins, you can streamline this for the end user by wrapping your function in a custom add_action. How? It’s incredibly easy. Just add an add_action() to your plugin file, like so:

add_action( 'show_my_plugin_widget', 'my_plugin_widget' );

function my_plugin_widget() {
	...
}

Now your users can use one straightforward line in their templates.

<?php do_action('show_my_plugin_widget'); ?>

One short line of code. No worrying about deactivated plugins. A small extra effort on your end can save your end users some frustration down the road.

Next Time: Cold Fusion! (article may be delayed by technical feasibility)

Previously: Use Classes in your WordPress plugins to increase code portability and reduce name conflicts

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

Any time a software package opens itself up to third-party additions, there is a potential for mischief. With WordPress, different plugins can end up stumbling over each other, as each is coded for the core but doesn’t anticipate other plugins. You can also have naming conflicts — when functions or variables in different plugins are given the same name. This is often avoided by adding the plugin name to the beginning of each and every function, variable, constant, etc.

If you have multiple plugins, you probably have a good bit of code that you reuse in all of them. If you’ve been appending the plugin name all along, then any time you update those common functions, you can’t simply copy the new versions over to the other plugins — you have to go over them and update the function names and any internal calls from one function to another.

These problems and others can be avoided by using classes.

By wrapping your plugin’s functions in a PHP class, you gain a number of advantages. You can set plugin-wide variables. You can use common function names and create easily-remembered “wrapper” functions that modify the way common WP functions do things. You can create portable functions that can be copy-pasted into other plugins without any adjustment.

Ready? Let’s get started…(...)
Read the rest of Use Classes in your WordPress plugins to increase code portability and reduce name conflicts (835 words)

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

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.

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

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 the rest of Consolidate Options with Arrays in your WordPress Plugins (1,731 words)

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

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

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

I’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 all¹! 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…

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

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh

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 situations¹. 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:

(...)
Read the rest of Use Action Links to direct users straight to your WordPress plugin’s admin page (522 words)

This article was originally published at Nerdaphernalia. Planet WordPress is authorized to reproduce WordPress-related entries. If you're reading this at any other web site, the site owner is stealing copyrighted work. Please visit the original page:

Feed enhanced by Better Feed from Ozh