Speaking about WordPress, what does anyone do about diffable version control and automated deployment? From my naive perspective, it seems like an opaque database is just a bad idea
I solved that by setting up a GitHub repo that mirrors the content from my database to flat files a few times a day and commits any changes.
It's worked out really well so far. It wasn't much trouble to setup and it's now been running for nearly three years, capturing 1400+ changes.
I'd absolutely consider using the same technique for a commercial project in the future:
Latest commits are here: https://github.com/simonw/simonwillisonblog-backup/commits/m...
Workflow is https://github.com/simonw/simonwillisonblog-backup/blob/main...
I'm adding features and content to legacy Wordpress websites where the clients are liable to change config and add and alter content themselves via the admin portal. There seems no easy way to automate deployment from local development into production without accidentally erasing someone's changes, and to keep up to date with production without losing your own work.
It seems like a tricky problem to solve, and maybe a bespoke version control system might be required (e.g., throw CRDTs at the problem?), but essentially I should be able to diff and merge between my local work and the production version while clients are making their own edits.
If so I'd be tempted to have a really shonky system - basically run a "git commit -a -m 'Updates' && git push" on an hourly cron, purely to capture their changes.
Merging in changes made elsewhere would still be hard, but at least you would know what was changed by them and when.
For my purposes here the feature I care most about is backups - having my content backed up to a GitHub repo feels extremely robust, since I know GitHub mirror content to (I believe) three continents.
It's not a great system.
If all you need is a static site generator with code in git, then go ahead, however the use for Wordpress is an audience who needs a full application to manage a site.
AFAICT it’s not that. It’s that most shops want the ability to edit content without a developer. But such a requirement doesn’t mandate that data lives in a database vs something like, say, a set of plain-text files, that would be amenable to version control and diffing
The use case for WordPress is businesses who don't really need a website at all but everybody demands that they have one and they want to outsource running a website so you can blame somebody else when it gets hacked into and can tell your marketing and sales department go bother somebody else about the website. <Raises hand>.
Anybody who actually needs an application to manage their site has staff and they don't use WordPress.