Recently I stumbled upon an article that was written to highlight a flaw in the generalized way that WordPress is written. Amazingly, it was written over 3.5 years ago and still holds true today.

Any time you call the get_posts() or query_posts() function, WordPress is querying the database in such a way that it can easily implement pagination using the SQL_CALC_FOUND_ROWS functionality within MySQL. That’s great in theory, but it’s also slow and inefficient when you have a very large posts table. What if you know that the query you are generating will not trigger pagination? Why include all that overhead?

This is a classic example of software thinking it’s smarter than people; but fortunately, there is a workaround. Thanks to the undocumented variable no_found_rows you can tell get_posts() and query_posts() not to do this extra work with a simple boolean value.

get_posts('no_found_rows=true&cat=1&numberposts=1');

It would be nice to see WordPress attempt to do this somewhat automatically. If numberposts is defined, as it is in the example above, WordPress could check to see if the requested number of results is less than the posts_per_page value. If pagination will not be needed, disable the SQL_CALC_FOUND_ROWS functionality automatically.

Seeing no_found_rows being documented in the Codex would be nice, since this information is not “news” anywhere. A quick Google search proves that people mention this frequently when discussing how to speed up WordPress. And perhaps a better name would be nice as well: the current variable speaks to the technical function it does (“do not use the SQL_CALC_FOUND_ROWS feature”), but why not uses_pagination or get_row_count?

Writing a plugin is great and all, since it will run code all the time affecting how WordPress operates.

But sometimes you want things to happen during activation and deactivation of the plugin. For some plugins, this is necessary (in the case of DisableMU, it is actually the only time that something occurs since the plugin is completely passive the rest of the time). For other plugins, it is simply a convenient time to do something.

register_activation_hook( __FILE__, 'myPlugin_activate' );
register_deactivation_hook( __FILE__, 'myPlugin_deactivate' );

function myPlugin_activate() {
    // Do activation stuff here
}

function myPlugin_deactivate() {
    // Do deactivation stuff here
}

These calls are very straightforward, each one only taking 2 parameters. The first variable is the path to your plugin’s base file, which for the purposes of the example above we’re just assuming is the working file in a simple one-file plugin. The second variable, like most other hooks, is the name of the function that should run when this condition is met. So when register_activation_hook() triggers during your plugin’s activation, it will run whatever you have inside the myPlugin_activate() function.

What you put in these functions is your choice. Add some validation code, initialize values in the Options table for your plugin to reference later: the possibilities are really up to you.

Remember that the deactivation part of the process is especially important. More often than not, you should use the deactivation function to clean up after yourself, and not leave any traces behind on the WordPress installation that was running your plugin. You may shoot yourself in the foot doing this (you don’t want a user to have to set your entire plugin’s complicated options settings again just because they deactivated and re-activated your plugin) but there are still many valid times when it makes sense to “sweep up” during this phase.

Good luck, and happy coding!