In the course of working on WordPress, and plugins and such for WordPress, I frequently find myself at a loss to remember the name of constants provided by the system. Hey, isn’t there a constant for such-and-such directory?
I did a bit of grepping and parsing just now, and in the hopes that it might be of use to my fellow WordPress hackers, here is my list of every defined CONSTANT in the latest WordPress 2.7-bleeding setup.
Read More
If you’ve been using WordPress for any amount of time, you’ve probably come across a plugin that asks you to add something to your template. The instructions will say something like:
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
There’s a new version of the Quiz plugin (a.k.a. “Comment Quiz”). The plugin requires commenters to answer a question before the comment is posted.
Significant improvements in 1.1, including a native meta box in the edit post/page screen, and the ability to have more than one acceptable answers to a question.
New version 0.4 of the Log Deprecated Calls plugin.
Now it has an option to toggle logging to the PHP Log, or a table in the database, or both. If logging to the database you can view the records on the admin page (under Plugins->Deprecated Calls. It also has a test function, and if you’re using WordPress 2.7 or up, it will even clean up after itself if you delete it.
Again, this is primarily of use to those who write plugins and themes.
Otto has released his Automatic Timezone Plugin as part of the current WordPress plugin competition. In addition to being a handy plugin, it comes with a significant bonus for plugin authors.
In addition to its basic function, the code is designed to serve as a tutorial of sorts, showing authors how to use some very interesting plugin techniques, such as modifying any option on the fly as it is pulled from the options table, or how to modify sections of the core admin pages.
It’s worth a look, and thanks to Otto for sharing.
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!
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
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…. 