Independencies

Software is just other people’s decisions, and if you trust code from people who don’t think consent matters they’ll get around to you eventually. Once again, I am asking you to understand your dependencies, to look at them really closely and act on what you see.

In light of the recent decision by the WordPress CEO to bundle up all of his credibility and trustworthiness and launch it in into the sun I’ve distilled two earlier posts about self-hosting WordPress with SQLite as a backing store into a gist you can read here and which is copied below. Proposed edits are welcome.

If you’re wondering why I do this, the short answer is that I cannot believe that a self-hosted one-person blog running on a tiny little hosted VM needs anything even vaguely like the burden or complexity of an enterprise DB behind it to hand out RSS feeds and the occasional web page. A WordPress install with wp-supercache in front of it and SQLite underneath would still be running smooth and cool if my needs went up 1000x.

More generally, I don’t believe there’s much of a role for MySQL in the world now. If you don’t need Postgres – and if you don’t know for certain that you need Postgres, then you don’t need Postgres – SQLite on fast storage is plenty.

This gist describes the process of making a self-hosted installation of WordPress run with SQLite as a backing store, rather than MySQL.

This is not a step-by-step guide, and will require some degree of comfort with your filesystem, editors, and logging. This involves both fighting with and lying to these systems, and consequently comes with no guarantees whatsoever.

—————

Start by installing WordPress through either your preferred package manager, or directly from the WordPress.org. If you haven’t already done so for other reasons, get Certbot via your preferred package manager and let it do its thing via “sudo certbot --apache“, or whatever webserver you’re using.

(A brief aside: Certbot just works and it’s nearly magic. Setting up certificates used to be a nightmare contraption on stilts. Now it’s frictionless, particularly compared to what we’re about to do.)

You will also need to install php8 support for your web server and for SQLite. On my Debian machine, this means installing libapache2-mod-php8.0 and php8.0-sqlite3 via apt.

Then, clone this repository:

https://github.com/aaemnnosttv/wp-sqlite-db

… and from it, copy src/db.php into the root of your /wp-content/ directory.

Choose a directory and filename for your SQLite database, and in your wp-config.php
file, add the following:

define('DB_DIR', '/absolute/path/to/your/directory/');
define('DB_FILE', 'your_sqlite_filename');

Now for the fighting and lying part of the exercise: SQLite has some database constraints that WordPress doesn’t meet and isn’t interested in meeting, the general thrust of them being that SQLite’s behavior defaults to “strict” where MySQL apparently defaults to sticking crayons up its nose.

In wp-admin/options.php, look for this line at about line 340:

update_option( $option, $value );

… and add $value = $value ?? ” ; to the line above it, like so:

$value = $value ?? '' ;"
update_option( $option, $value );

Next, you will need to modify wp-includes/class-wpdb.php.

You’re doing this because the WordPress people decided to take an abstraction layer – SQL – designed to free you from being locked into a specific backing DB and wrapped it in a second abstraction layer, the “WordPress database access abstraction class”, that frees you from having to use SQL by locking you into a specific backing DB. Your questions, while shared, are outside the scope of this document.

Your next step is to lie to WordPress about your nonexistent MySQL version.

To do that, we need to modify db_server_info() at the bottom of class-wpdb.php, around line 4134 or so, as follows:

public function db_server_info() {
// return mysqli_get_server_info( $this->dbh );
return "8.2.0" ;
}

Next, restart your webserver and log into WordPress. Nothing to it.

Suggested edits are welcome, email me.

– mhoye