We were playing around with a little script the other day that would sanity check our own plugins whenever we were about to do a check-in into the repository. There are some common errors we’ve hit a few times during development, so we created the script to try and locate those. It worked so well in fact that we decided to analyze the whole WordPress plugin repository.

The end result is available at http://plugincheck.bravenewcode.com. The HTML files are auto-generated, and will be updated from time to time. It’s really hard to account for all the variations in coding style, so undoubtedly there will be a few false positives in that list. Given that there are nearly 10,000 plugins there, we really don’t have the time to manually edit the content to remove those. That being said, hopefully the plugin checker will be a valuable resource for people that want to try and improve their plugins.

The most common problem appears to be the hardcoding of wp-content in the files. As of WordPress 2.6, you can not only rename wp-content to something else, but you can also move it out of the WordPress tree. If you hardcode wp-content in your code, that feature will no longer function, and will undoubtedly cause errors. The correct solution is to use the WP_CONTENT_DIR definition in your code if it’s defined.

Another common error is that some plugins access the database directly using mysql_connect. The correct way to handle database activity is to use the WordPress database object, $wpdb. Also, to prevent against MySQL injection attacks, developers should use the $wpdb->prepare function to automatically escape all strings.

We’re definitely open to feedback regarding the plugin checker. Right now it’s just a part-time interest, so there are no guarantees that we’ll keep running it. But while it’s up, enjoy!