Last active
October 18, 2024 18:09
-
-
Save mhoye/d2a0ac715f0e44e9fa98d6d9adc79e8f to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment