To save you a click, the actual headline is "Help us test the SQLite implementation", and the news is that WordPress developers are asking (urging!) hosts, plugin authors, and theme developers to test the implementation and report bugs.
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."
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
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.
Hopefully this will entice more people into supporting SQLite as their backend DB. There's been more than a few things I've purposefully not installed because they require MySQL (it is forbidden on my servers.)
Mainly residual trauma from the early days - I was a big proponent in the early days (back when you could get personal support from Monty) but too many security holes, corruption bugs, etc., lead me to the arms of SQLite + Postgres and I've stayed there ever since.
It's entirely possible MySQL is a superb DB engine now and won't cause me any more trauma but ...
There's a world of difference between the myisam & innodb storage engines. Not encouraging you to return or anything, just throwing it out there that many/most storage related problems were because of myisam.
Oh, definitely, but it was some time after innodb arrived and it brought a different set of (undoubtedly teething) problems. It was kinda damned if you do, damned if you don't at that time. Life was just easier without MySQL.
Fair enough I suppose. I guess I've been lucky enough to not encounter any show-stopping problems with MySQL, at least that I can recall. Maybe you started using it well before I did.
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.
That's reminded me of one problem I had with it back in 2010 - it didn't have indexes on expressions[1]. We had a few hundred million rows with unindexed timestamps (I forget if they were MySQL-native or just ISO8601 strings) and the higher ups wanted a daily aggregate report of some stuff which was, obviously, slow to generate because of having to truncate all the timestamps to just YMD[2].
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.
mysql has a datetime type that can be an index, and should be able use for a range scan. that is, with the appropriate data type, it sounds like you would've had a better time...
> [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.
Nice. That will simplify my installs and my backups and their reliability. There are not many writes, very few concurrent ones, accesses are mostly cached using a WP cache extension. I have a lot of trust in SQLite's reliability. It should fit right in. WordPress is the only reason MariaDB is installed on my servers. Nextcloud too, actually, and SQLite might not be a good idea for this.
I will be testing it with Marmot (https://github.com/maxpert/marmot) to help scale Wordpress when needed! IMO Wordpress + SQLite is a no brainer for 95% of its sites. Hopefully do a demo video. Marmot will help folks scale their sites without central MySQLs.
If you're just hosting a blog or simple informational site, there are better options, for sure.
... 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 database code, though, ends up being a crazy mishmash of Wordpress' existing faked-up/string-escaping wpdb_prepare() then auto-translated from mysql syntax to SQLite. I'm sure they will test it pretty well, but it's a bizarre setup.
Why a flat file CMS rather than a static generator?
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.
The embedded nature of SQLite is somewhat offset by the stack still requiring PHP + Apache installed, what's one more dependency (MySQL)? All WordPress hosts already have MySQL installed, while installing WordPress from scratch is still a pain (or requires programs that manage that complexity for you e.g. XAMPP).
Do you definitely need Apache? I thought PHP worked fine without that these days - or does Wordpress only work with something that supports .htaccess too?
Yes, the standard setup for any PHP application in the last 10 years is a webserver (e.g. Apache, nginx, Caddy, lighttpd) in front of PHP FPM.
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.
- Entirely file based (and can be reasoned about as such, including backups/restores/migrations).
- 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.
You still have to keep the database nature of the SQLite file in mind when doing backups, as far as I understand it is not safe to just copy the file while the DB is running unless you use snapshots or ensure that nothing is written to the DB during that time.
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.
Copying the database file is fairly safe, especially for an application that's likely to be read-mostly like WordPress. It could fail if the database was large enough that copying it took a nontrivial amount of time, and the database was modified during the copy operation -- but even then, there's a fair chance it'd be recoverable. SQLite is pretty resilient.
which writes out a new copy of the database file. Restoring the database would be as simple as renaming the backup to the main file -- the backup is a "real" database file; there's no import operation required.
Well, you don't have to fiddle with drop statements and tag.gz formats and things like that and restoring is just a matter of putting the file back instead of importing huge numbers SQL instructions. You don't depend on php/phpmyadmin or a sql command to get a backup or to run it (no cpu are harmed during the process). Just copy the file.
I can see old gotchas disappear like that (can't wait for the new ones !).
You don't have to spin up a MySQL (or Postgres) instance which is a moving part which doesn't need looking after. Obvs. you'll still need SQLite backups but they're a lot easier, especially with e.g. litestream.
Presuming by “Ruby” you meant Rails, you probably won’t find WordPress a satisfactory replacement for any of them if you’re more of a developer than a site-builder. As a web development framework, WordPress is nearly useless computers to the others.
Yea to be honest, I program in .net for a living, but I've been looking for a simple SAAS on the side.
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.
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."