New WordPress Plugin: Log Deprecated Calls

New plugin for Y’all. This one is of particular interest to plugin authors and theme designers (and… nobody else).

Activate it, and any time WordPress calls a function or file that has been deprecated, a message will be sent to your PHP log file that identifies exactly where the call came from and what to replace it with. This will allow you to very easily keep your plugins and themes calling the most current functions.

(And yes, the message is more informative than the one returned by WP_DEBUG.)

Here’s the link. Go get it!

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

One of the most powerful features of WordPress is the huge community of developers making plugins that extend the software far beyond what the core application provides. It also allows people to add just what they want to use, rather than having a single bloated homogeneous download. There are drawbacks as well, of course.

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 More »

How to write a solid and stable WordPress plugin

Mark Jaquith has put up a nice article on “How to write a solid and stable WordPress plugin“. It’s more of a rough overview than a detail piece, but he promises more details down the line in separate articles.

This is worth looking at if you write WP plugins, even if you’re pretty experienced — if for nothing more than to check that you’re not missing something…. ;)

Comment Spotlight plugin v 1.1 for WordPress

I’ve updated the Comment Spotlight plugin for WordPress. Changes in 1.1 include:

  • Fully WP 2.6 compatible
  • Lots of code cleanup
  • Fixed spotlight image so it’s NOT inside the first paragraph
  • Spotlighted comments add “clear: both” div to end so spot images don’t extend past comment bottom
  • Moved Settings screen to Settings menu (was in Comments menu)
  • Added direct link to Settings from Plugins “Action” column
  • Added Settings page footer
  • Moved all functions into a PHP class
  • Added get_options and localization functions
  • Added nonces to Settings page — better security

Go get it!

JavaScript Pull-Quotes 2.1.2

Version 2.1.2 of my JavaScript Pull-Quotes plugin for WordPress is up.

The biggest change from the user end is that localizations (i.e. translations) now work. (The had worked previously, but broke somewhere along the way.) It includes French and Italian translations.

If anyone out there would like to translate the plugin for others who speak that language, see the readme in the “languages” folder, and send it along to me - I’ll include it in the next version. :)

Actually, the French and Italian files could probably use some updating too. ;)

Go get it!

Full changelog (for the geeks):
* Fixed design flaw introduced in 2.1.1. Style option now stores file basename relative to styles directory -- should not store full URL if we're going to let user change the directory.
* BUGFIX: Localizations not working. (Incorrect path)
* Localizations (.mo files) will work directly from languages/ folder
* Changed init() to class constructor -- no more hooking "init" action
* Moved activation hook call to constructor
* Minor code cleanup to comply with WP Coding Standards
http://codex.wordpress.org/WordPress_Coding_Standards

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!