I currently work for a multi-million dollar company that is completely dependent on this lumbering geriatric. A design from the turn of the century, that limits how we can configure it, modify it, test it, version it, deploy it, roll it back. A rotting piece of fruit with so many bugs and holes we need to constantly look for a newly-announced bug so we can rush to patch it so the rot doesn't spread to our business.
Even the managed hosters have barely adopted modern practices. Do you know it's actually easy to treat the database as an ephemeral, versioned object? Nobody I've talked to does. You just back up the logical database, and rename the database name in the backup to a unique string (including a version, or datestamp, etc). Now you have versioned, uniquely-named database, so you can do immutable infrastructure. Load this backup into a database server (even the "live" database server, as it won't conflict with the old db name). Start a new WordPress container and pass env vars pointing to the new database name. Now you can pair a snapshot of the code with a snapshot of the database. Upgrade or downgrade in seconds, with confidence. (that is, after you've done all the manual work to upgrade, test, and fix in an ephemeral environment)
This simple method makes operations more robust and predictable, makes dev & testing easier, and is used by.... nobody, as far as I'm aware. All the managed hosters I've seen just give you an admin portal, and a "dev", "test", and "live" instance. No ephemeral environments. No snapshots or diffs of configs or databases. Plugin upgrades are largely left to the user, because there's no way to know other than by manual testing if any change breaks everything. There doesn't even seem to be an open source project for containerizing & deploying it immutably (or there wasn't wasn't when I created one 4 years ago). Because everyone's mind is stuck in this box from 2003. Of the bad designs and cloistered practices that were passé 10 years ago.
Organisms can't evolve if they live forever. In order for CMS to evolve, WordPress needs to die. Please just let it die.
> Do you know it's actually easy to treat the database as an ephemeral, versioned object? Nobody I've talked to does. You just back up the logical database, and rename the database name in the backup to a unique string (including a version, or datestamp, etc). Now you have versioned, uniquely-named database, so you can do immutable infrastructure. Load this backup into a database server (even the "live" database server, as it won't conflict with the old db name). Start a new WordPress container and pass env vars pointing to the new database name. Now you can pair a snapshot of the code with a snapshot of the database. Upgrade or downgrade in seconds, with confidence. (that is, after you've done all the manual work to upgrade, test, and fix in an ephemeral environment)
There is a good reason why nobody does that: it makes very little sense on any sort of web platform more complex than a static website. Indeed, as the WordPress database schema is quite normalized especially around metadata and taxonomies, there are many INSERT/UPDATE queries running/queued basically all the time on a busy website.
For example, 1ms after you've snapshot your DB and "versioned it" (renamed it rather) locally, it's already obsolete because 2 users have just logged in and their last logon timestamp got updated as metadata stored in the _usermeta table. Switch to the versioned snapshot in the meantime and you lost that information. This is Bad(r).
Even then, say 30s after making the snapshot and before you've "deployed" the code upgrade, a cronjob has triggered an image optimizer plugin, inserting various optimized copies of the image objects in the main _posts table (it also updated the metadata of all those images). Rollback the DB because your deployment caused a crash and you've lost images. Again, a big no-no.
The simplest WordPress-safe upgrade path in case of code changes impacting the database is for the code to support rollup/rolldown migration queries on the database: rename a meta_key when upgrading and rename it back when downgrading.
Use WP abstraction functions to interact with the database, and generally treat the database itself as a blind storage medium, to be restored only in extreme cases.
This is my point. The problem is WordPress's design. Despite that, there are better practices... but the best practice would be not to use a design from 20 years ago.
Even the managed hosters have barely adopted modern practices. Do you know it's actually easy to treat the database as an ephemeral, versioned object? Nobody I've talked to does. You just back up the logical database, and rename the database name in the backup to a unique string (including a version, or datestamp, etc). Now you have versioned, uniquely-named database, so you can do immutable infrastructure. Load this backup into a database server (even the "live" database server, as it won't conflict with the old db name). Start a new WordPress container and pass env vars pointing to the new database name. Now you can pair a snapshot of the code with a snapshot of the database. Upgrade or downgrade in seconds, with confidence. (that is, after you've done all the manual work to upgrade, test, and fix in an ephemeral environment)
This simple method makes operations more robust and predictable, makes dev & testing easier, and is used by.... nobody, as far as I'm aware. All the managed hosters I've seen just give you an admin portal, and a "dev", "test", and "live" instance. No ephemeral environments. No snapshots or diffs of configs or databases. Plugin upgrades are largely left to the user, because there's no way to know other than by manual testing if any change breaks everything. There doesn't even seem to be an open source project for containerizing & deploying it immutably (or there wasn't wasn't when I created one 4 years ago). Because everyone's mind is stuck in this box from 2003. Of the bad designs and cloistered practices that were passé 10 years ago.
Organisms can't evolve if they live forever. In order for CMS to evolve, WordPress needs to die. Please just let it die.