Join the Internet Defense League using the Cat Signal plugin for WordPress!

Back in 2012 “the internet”, as a collective, realized the power of people speaking up with the Internet Blackout to fight against SOPA/PIPA. Major players stepped up and told the government they did not like what was happening with the two bills, including companies like Google, reddit, Mozilla, WordPress, Craigslist and more.

Since then, other campaigns have happened – though none have drawn nearly as much press as the Internet Blackout did. To help boost awareness of, and participation in, future similar campaigns a group calling themselves the Internet Defense League have created a means of easily disseminating code, so that as many websites as possible can quickly get the code and implement it in the future.

Cat Signal is a WordPress plugin that implements the JavaScript needed to participate. Turn it on, leave it on, and your website will always display a message any time a campaign happens. For example, today 9/10/2014 is the Internet Slowdown which is being used to inform people about Net Neutrality and collect digital signatures which will sent to your local Congressman. Here is a screenshot of what Binary Templar looked like when a site visitor would come to the site for the first time today.

Internet Defense League

If you don’t want to keep the plugin enabled, feel free to deactivate it between campaigns. As long as you know something is happening, you can always turn it back on again. But as long as you’re not so worried about the extra js file include on your site performance, you are probably fine to just keep it enabled so that you don’t have to proactively do anything the next time a campaign occurs.

If you like, you can also go to the Internet Defense League’s members area to grab a badge for your site, advertising that you support their cause. There are multiple to choose from, for use in including in different locations on the site or with different designs.

Have fun, and happy protesting!


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.


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!