Our plugin (VersionPress) needs to track database changes so that it can version-control them. We currently do this by creating db.php and overriding the $wpdb instance in it but it has an issue that if any other plugin decides to override db.php there will be a conflict.

My question is rather generic: to me, it seems that db.php and creating a subclass is very weird and uncommon extensibility point in WordPress - why is that? There will probably be a reason why hooks or filters are not used. Is it because some of the queries are run before a plugin would be loaded and had a chance to influence the query? Or some other reason?

And how to work around it? We want VersionPress to work with other plugins that possibly create their own db.php. Is our only chance hooking into the 'query' filter which unfortunately only provides unstructured query data?

1 Answer 1


Simple, hook on the query filter and structure that "unstructured" sql data. Parsing SQL is annoying but can't be that difficult.

Of course some queries are ran before plugins are loaded as you do need to get the list of active plugins and active theme before including their file. And if you need to access a DB which is different from mysql or ignores the dbname/user/password settings from wp_config.php file, you need to do override $wpdb before the first query is sent.

  • It is actually quite difficult but your answer makes a lot of sense. I've tried to file an enhancement request to WP trac so hopefully hooks for the methods that work over structured data will be added. Thanks. Sep 19, 2014 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.