- 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.
Discover more from Something Odd!
Subscribe to get the latest posts to your email.
Thanks for the links, I want to start my own plugin and this sure helps me out.
I guess most plugin authors will start to use the tips above, if not then they are lazy in my eyes. Please note that it’s my own opinion.
My biggest wish is that theme and plugin developers would use wp_enqueue_script and stop including Javascript over pages that don’t need it. Most do, but the ones that don’t cause plenty of problems.
The curly bracket on its own line is great for text editors like vim, because you can more easily navigate around block elements. What convinced you to give it up?
I think it was before I started work on WordPress seriously. At my last job a colleague put the curly brackets on the same line as the if() statement and it just worked before.
Haven’t really noticed it being harder to navigate in in Vim when % will take me to the start/end of the block 🙂
i from russia, really good post!
WP super cache is very useful ! Thank you for posting these links !