Marcus Downing

That’s good to know, thanks. Has it changed the database format?

I noticed that the database format changed a few times since we started using this plugin. Are there plans to change it further? It would be good to stabilise, so that external tools can read the database reliably.

Apologies, I didn’t look into the issue in detail. I simply switched the plugin on and saw that XML-RPC was still reachable. I only got as far as the “XML-RPC server accepts POST requests only” message, while I think the xmlrpc_enabled filter is checked further down the line.

There are indeed plenty of ways to block XML-RPC, and there’s no reason why your plugin should have to limit itself to just one of them. Here’s some code (go ahead and use it for free) for blocking that file with WordPress’ .htaccess, using activation hooks to make sure it’s applied with the plugin.

add_filter('mod_rewrite_rules', 'noxmlrpc_mod_rewrite_rules');
function noxmlrpc_mod_rewrite_rules($rules) {
  $insert = "RewriteRule xmlrpc\.php$ - [F,L]";
  $rules = preg_replace('!RewriteRule!', "$insert\n\nRewriteRule", $rules, 1);
  return $rules;
}

register_activation_hook(__FILE__, 'noxmlrpc_htaccess_activate');
function noxmlrpc_htaccess_activate() {
  flush_rewrite_rules(true);
}

register_deactivation_hook(__FILE__, 'noxmlrpc_htaccess_deactivate');
function noxmlrpc_htaccess_deactivate() {
  remove_filter('mod_rewrite_rules', 'noxmlrpc_mod_rewrite_rules');
  flush_rewrite_rules(true);
}

Instructions that approximately work:

http://askubuntu.com/questions/166280/how-do-i-install-the-clamav-extension-for-php-5-on-11-04

It’s messy though, and involves installing your own version of ClamAV. I’m left wondering why there isn’t a neat way of doing this.

http://wordpress.org/support/topic/blocking-the-wp_login_failed-event

We’re looking at the possibility of using your plugin to satisfy some UK government requirements for audit logging on a site. The logs of important events like logins will be collected straight from the database.

Having spoken to the company providing the log collection software, millisecond accuracy isn’t as necessary as I thought, since they can use the EventNumber field to guarantee no log messages are missed by their collector. So it isn’t a strict requirement for us after all.

Still, an event time stored in date/time format is potentially subject to issues with time zones, incorrectly set clocks etc. So for reliable timekeeping, a raw timestamp seems like a good idea. You can get PHP’s highest accuracy with the microtime function. On my machine here it’s only accurate down to about 0.1 milliseconds rather than the promised microseconds, but that’s as good as it gets. It’s well supported across platforms since PHP 4.