For example: Let’s say you want to make a plugin that works with other plugins. For other plugins to be compatible with it, however, they need to provide some new piece of information, and you want to do this with a custom header. So we’re going declare a new plugin header. Let’s call it… oh…. “Demo Header”. Here’s the code; just drop this in a plugin and activate:

function plugin_header_demo( $extra_headers ) {
	$extra_headers[] = 'Demo Header';
	return $extra_headers;
}
add_filter( 'extra_plugin_headers', 'plugin_header_demo' );

Pretty simple, eh? What we’ve just done is added “Demo Header” to the list of headers that WordPress will check for when get_plugin_data() is run. Now, along with Name, Version, Author, and so forth, a value for Demo Header is returned as well.

Note that this is only for cases where you want any plugin checked for this header. This changes the get_plugin_data() function and takes effect every time that function is run, on any plugin.

Want to do it for themes? The code is almost identical:

function theme_header_demo( $extra_headers ) {
	$extra_headers[] = 'Demo Header';
	return $extra_headers;
}
add_filter( 'extra_theme_headers', 'theme_header_demo' );

Note that this does not allow you to alter the pre-existing headers in any way. You can’t, for example, remove the “Name” header.

Personally, I intend to use this for a third-party update check plugin, which will also be incorporated into Strider Core. For that use, I’ll add an “Update URL” header (or similar).

Next up: How to define your own custom get_XXX_data() function that works like the ones for plugins or themes.

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

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