WordPress to support SQLite back end
make.wordpress.org
make.wordpress.org
The most interesting bit for me: "The SQLite code used has been in use for many years and has been battle-tested. We opted to start with a tried solution instead of starting from scratch because many of the problems we would have encountered have already been addressed and solved in the pre-existing implementation."
I say this because in theory Drupal core supports postgresql 100%
In practice, unless you actually comb through the code base if all the modules you install, you will have some that won't work. I have only tried this on Drupal 8 but I doubt much will change with 9 or 10.
> I say this because in theory Drupal core supports postgresql 100%
> In practice, unless you actually comb through the code base if all the modules you install, you will have some that won't work. I have only tried this on Drupal 8 but I doubt much will change with 9 or 10.
Why no one mentions typo3 [1]
[1]https://docs.typo3.org/m/typo3/tutorial-getting-started/main...
https://github.com/aaemnnosttv/wp-sqlite-db
This has been around since some time and is itself a fork of a previous work.
The interesting part is that this drop-in replacement (mostly) already works well, there are a few issues that are related to some quirks in the WordPress core itself, for example: https://github.com/aaemnnosttv/wp-sqlite-db/issues/18
And maybe now they will be fixed.
It's entirely possible MySQL is a superb DB engine now and won't cause me any more trauma but ...
For what it's worth, in the cases where you need a client-server database, I know that Postgres is supposed to be "better," but MySQL is everywhere and it's always been up for almost any task I've thrown at it. I've found it to always be sufficiently good enough.
For Postgres, I would have just created an index on (the equivalent of) `truncate(YMD, timestamp)` (and I demonstrated this as a POC to the higher ups as a good reason to switch to Postgres. But alas, no traction.)
[1] Seems to have arrived some time around 2013-14?
[2] Storing the date and time parts separately would have been sensible but the schema was set in stone a couple of years old before I arrived.
> [2] Storing the date and time parts separately would have been sensible but the schema was set in stone a couple of years old before I arrived.
The real benefit of postgres*: offline transactional schema changes. mysql would've done a table copy in order to change it. if mysql supported offline schema changes, perhaps you'd have been able to change the data type, solving the root cause of the problem.
* I haven't had the pleasure of using postgres in production, so I can't speak to how effective any given feature is -- only what the marketing appeal is.
Related:
Let’s make WordPress officially support SQLite - https://news.ycombinator.com/item?id=32807601 - Sept 2022 (115 comments)
Wp-SQLite: WordPress running on an SQLite database - https://news.ycombinator.com/item?id=31396732 - May 2022 (97 comments)
... except that you can just go click a couple buttons, and be ready to start editing your first blog post, right in your browser, with Wordpress, because there are a bunch of easy-to-use hosting solutions.
If you're doing much more than that with your site, it can be hard to sell a solution other than Wordpress. The plugin ecosystem and 3rd-party service support is pretty damn good. Consider how few other web platform ecosystems exist that can support individuals and even small teams selling commercial plugins—like, full-time, that's your day job.
I think WP's a fucking mess and hate developing for it, but it's hard to advocate for anything else, for a pretty large set of Web use cases.
The page you linked explicitly says "We’re not talking about static site generators here", but doesn't elaborate why, and even includes a bunch of static site generators, eg Jekyll. I'm confused.
I guess to the OP's point, it does still require PHP, FPM, a number of other PHP extensions, and the webserve all to be installed on the server. At which point, MySQL is just one more dependency. I would argue that SQLite is a little easier to back up and transfer than MySQL, but WordPress does that make easy anyway.
I wonder if there's a plan afoot to embed the whole thing inside an Electron app for some kind of portable TiddlyWiki like service.
- Reduced attack surface (e.g. no DBMS running on a potentially unsecured port, fewer code-execution vectors).
- Reduced maintenance (SQLite's library will be patched as part of WordPress).
Will it scale worse? Sure, but a lot of Wordpress installations simply don't need it, in particular if you throw a Wordpress cache (e.g. Super Cache, W3, etc) in front of the thing. You could Wordpress cache and then server cache on top of that (e.g. Cloudflare, CloudFront, etc), and I bet the thing could handle millions+ of impressions.
SQLite is still easier to manage than a standalone database server, so it is interesting in any case. But I'm not sure it makes backups easier.
The "safe" way of doing the backup would be:
sqlite3 wordpress.db ".backup wordpress-backup.db"
I can see old gotchas disappear like that (can't wait for the new ones !).
A second option is to use the SQLite command line tool, it provides a backup command.
If you need something more complicated, SQLite provides a backup API you can make use of.
Are you sure about this? I think it's a lot more likely that it'll use PHP's sqlite3 extension.
Edit: confirmed, it uses PHP's built-in PDO SQlite3 driver: https://github.com/aaemnnosttv/wp-sqlite-db/blob/master/src/...
I've been looking for a simple plugin type solution. Django, RoR, etc all have the promise of third party packages but honestly most wordpress templates are easy and more feature rich for alot of things.
SQLite along with a jam stack service for auth would make my life super easy.