Some recentish changes in the WordPress codebase – in particular the “database abstraction” class – have had the unfortunate side effect of cementing MySQL as a hard requirement for that stack. If you took advantage of my post about making WordPress run with SQLite and you’ve updated since, you might be having a bad time right now.
Lucky for you, I’m here to “help”. Or at least get you back up and running, which if you squint kind of might be similar.
This has manifested itself for me in the traditional manner of PHP errors, where nothing visible works but something behind the scenes starts barfing stack traces disguised as web pages into your server logs, because who wouldn’t want that really.
The meat of that error is:
PHP Fatal error: Uncaught TypeError: mysqli_get_server_info(): Argument #1 ($mysql) must be of type mysqli, WP_SQLite_DB\\PDOEngine given in /my-wordpress-install-dir/wp-includes/class-wpdb.php:4143\n
The \ns all over the place are of a particular flavor, very dog-at-a-keyboard. Where are we, how did we get here, what is even happening?
The comments at the top of the class-wpdb.php file are informative:
* WordPress database access abstraction class.
*
* This class is used to interact with a database without needing to use raw SQL statements.
* By default, WordPress uses this class to instantiate the global $wpdb object, providing
* access to the WordPress database.
… and I think that means they’ve decided to take one abstraction layer that frees you from being locked into a particular backing store and wrapped it in a second abstraction layer that frees you from having to touch the first abstraction layer by doing exactly the opposite, which is I guess a choice you can make.
Anyway, insofar as it affects us today, this means that when you upgrade, you’ll get this wrapper class calling a PHP builtin to check your MySQL version number, and we don’t have that, so…
public function db_server_info() {
// This is _so gross_ but it also works. - mhoye
return "8.2.0" ;
// return mysqli_get_server_info( $this->dbh );
}
… here we are at line 4134 of class-wpdb.php, last function in the file, straight up lying to the computer until it does what we want.
There’s nothing magic about “8.2.0”, it’s the current release of MySQL; it doesn’t matter. There are going to be future circumstances where it does matter, but it looks like dramatic WordPress schema updates are infrequent enough that I think I can burn that bridge when I get to it.
You don’t need to copy in the comment about this whole exercise being gross, obviously, but you definitely should, because this is definitely gross.
If you’re wondering why I’m doing this, the justifications I prefer to deploy are “I’m not particularly fond of having something I personally care about taking a dependency Oracle” and “backing up a SQLite database is just ‘copy a file'”, but the prime motivator is actually “It’s my computer and I’ll do what I want.” For the sake of future searchers – hello, future searchers! – key terms of this exercise are:
- mysqli_get_server_info
- mysqli
- SQLite
- WordPress
- Argument #1 ($mysql) must be of type mysqli
- WP_SQLite_DB\\PDOEngine