- WordPress Coding Standards. I used to be a big fan of the “curly bracket on it’s own line” but many years ago that was beaten out of me. Coding standards can be a subjective preference, but they’re very useful when reading code created by others.
- Data Validation. It’s vitally important that the data your web application accepts is checked for any malicious code. The new $wpdb->prepare() function is something every WordPress plugin author should be using if they have to use the database directly.
- WordPress Nonces. A nonce makes sure that a request you’re sending your blog was one you meant to send. Without a nonce, another site could have your browser load an image on it’s site pointing at your blog’s admin page to do an administrative task. You don’t want another site fooling your browser into doing something malicious do you? See Cross-site request forgery on Wikipedia for more.
If you write plugins for WordPress, please take the time to read through those pages above and learn how to use the security tools on offer. I know of at least one very popular WordPress MU plugin that doesn’t use nonces and I’ve only looked at the code of a couple of them. Most plugins don’t use $wpdb->prepare() yet as it was only introduced in recent versions of WordPress.
As a user of Free Software, you already know that “Free” doesn’t mean “Free as in beer”, it’s “Free as in speech”. If you know anything about software development help plugin authors by looking over their shoulders and checking their code. There is a cost to everything. In Free Software that cost is helping to test or fix bugs in the software you value and enjoy.
PS. WordPress MU 2.7.1 beta 1 is out, as is WP Super Cache 0.9.3 which has even more fixes for those running the latest PHP5 builds. Bloody register_shutdown() and it’s object destruction caused me no end of grief debugging that.