Study: 20% of the Most Popular WordPress Plugins Are Vulnerable to Cyberattacks

In other news, sky still blue.

I just spent the better part of a week rewriting a traditional Wordpress plugin to be an AJAX backed AngularJS widget. I have never before seen a system work so hard to discourage you from doing the right thing.

* Need to make an ajax endpoint? Create a global function, call wp_hook to register it twice, and be sure to die() at the end of it. Oh, and you can't selectively register on HTTP verb, plus too bad if you wanted to use the param "action" for anything.

* Want to serve some JS? Great! wp_enqueue_script has you covered. Unless you're plugin is included after the header. Unless unless you pass the optional "place in footer" flag. Unless unless unless the theme doesn't call wp_foot() (which is depressingly common). Good luck!

* Need to serve something that isn't JS or CSS, like a static HTML template? Fine! Just pass the whole path to the file! Since we don't do any routing other than cleaning up permalinks, every file has its own URL! Oh, just be sure to use plugin_dir_url() to get the base path. But despite the name that returns the path to the current file not the plugin so you should probably call it once in your plugin initialization file and cache the result in a global constant or something.

* Looking to do some safe SQL queries? Fantastic! Here's $wpdb->prepare. Which, by the way, doesn't have a named argument syntax. So if you have any optional params or dynamic segments in your SQL then you're going to have to prepare a whole query for each permutation. Oh, and I know you're building your queries by hand, but be sure to use "SELECT * FROM {$wpdb->posts}" instead of "SELECT * FROM wp_posts" just in case the table prefix isn't set to the default.

And that's just off the top of my head. Seriously, even assuming you know the right way to do any of the above (which in an environment that is quite explicitly aimed at being friendly to non-developers is far from a given), actually doing it involves jumping through countless obscure hoops. The simple fact is that making an ajax.php file and starting it with require_once('../../../../wp-config.php') or doing string interpolation into raw SQL, though horrible from both security and portability standpoints, are not only easier to write but make for clearer and more understandable code.