3 ms·

Speaking about WordPress, what does anyone do about diffable version control and automated deployment? From my naive perspective, it seems like an opaque databa

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

solardev 3y ago
Third party providers like Pantheon and Acquia will make their own deployment pipelines and manage pushes and pulls etc for you. The code (theme, plugins) is usually version managed but I don't believe the content is. Normally you'd pull the prod DB down to dev, then push dev code and prod DB together to stage, and then run regression tests (auto and manual) on stage. Then push to prod and hope no editor changed the content in a breaking way in the meantime. It's not a great system.
orev 3y ago
You could ask the same question about any application that uses a database. The answer is you typically don’t do things that way. 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.
- bsder 3y ago
  > the use for Wordpress is an audience who needs a full application to manage a site. 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.
- h0l0cube 3y ago
  > 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
simonw 3y ago
My personal blog runs on Django + PostgreSQL, and I got fed up of not having a version history of changes I made to my content there. 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/main https://github.com/simonw/simonwillisonblog-backup/commits/m... Workflow is https://github.com/simonw/simonwillisonblog-backup/blob/main/.github/workflows/backup.yml https://github.com/simonw/simonwillisonblog-backup/blob/main...
- sjmiller609 3y ago
  That is awesome! Did you consider using the temporal_tables extension? I think it's basically like version history for tables. I haven't used this before personally though. https://pgt.dev/extensions/temporal_tables https://pgt.dev/extensions/temporal_tables
  - simonw 3y ago
    I didn't - I hadn't seen that extension before, it looks like it could be really useful in the future! 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.
- h0l0cube 3y ago
  A version history sounds great, but it's not really the problem I'm talking about. 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.
clintonb 3y ago
- https://roots.io/bedrock/ https://roots.io/bedrock/ - https://roots.io/trellis/ https://roots.io/trellis/
- h0l0cube 3y ago
  Do these tools work well when people are editing content and config from the site vs developers adding features/content by version control? It's this tension that has caused me some grief when working on legacy Wordpress sites
  - clintonb 3y ago
    Yes. The content in the database remains the same. Developers can continue creating themes and plugins as they normally would.
    - h0l0cube 3y ago
      Sometimes 'development' isn't as clear cut and that and does involve creating content to drives a custom plugin that's in development. I dream of a day when PHP moves from a database to a file structure of plaintext documents that can be merged and diffed, instead of to another database, and maybe even uses git to commit changes. But it's a pretty wild dream, and it's probably better to just use a different platform for new projects, and just wear the pain for the legacy projects.

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

solardev 3y ago

Third party providers like Pantheon and Acquia will make their own deployment pipelines and manage pushes and pulls etc for you. The code (theme, plugins) is usually version managed but I don't believe the content is. Normally you'd pull the prod DB down to dev, then push dev code and prod DB together to stage, and then run regression tests (auto and manual) on stage. Then push to prod and hope no editor changed the content in a breaking way in the meantime. It's not a great system.

orev 3y ago

You could ask the same question about any application that uses a database. The answer is you typically don’t do things that way. 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.

bsder 3y ago
> the use for Wordpress is an audience who needs a full application to manage a site. 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.
h0l0cube 3y ago
> 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

simonw 3y ago

My personal blog runs on Django + PostgreSQL, and I got fed up of not having a version history of changes I made to my content there. 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/main https://github.com/simonw/simonwillisonblog-backup/commits/m... Workflow is https://github.com/simonw/simonwillisonblog-backup/blob/main/.github/workflows/backup.yml https://github.com/simonw/simonwillisonblog-backup/blob/main...

sjmiller609 3y ago
That is awesome! Did you consider using the temporal_tables extension? I think it's basically like version history for tables. I haven't used this before personally though. https://pgt.dev/extensions/temporal_tables https://pgt.dev/extensions/temporal_tables
- simonw 3y ago
  I didn't - I hadn't seen that extension before, it looks like it could be really useful in the future! 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.
h0l0cube 3y ago
A version history sounds great, but it's not really the problem I'm talking about. 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.

clintonb 3y ago

- https://roots.io/bedrock/ https://roots.io/bedrock/ - https://roots.io/trellis/ https://roots.io/trellis/

h0l0cube 3y ago
Do these tools work well when people are editing content and config from the site vs developers adding features/content by version control? It's this tension that has caused me some grief when working on legacy Wordpress sites
- clintonb 3y ago
  Yes. The content in the database remains the same. Developers can continue creating themes and plugins as they normally would.
  - h0l0cube 3y ago
    Sometimes 'development' isn't as clear cut and that and does involve creating content to drives a custom plugin that's in development. I dream of a day when PHP moves from a database to a file structure of plaintext documents that can be merged and diffed, instead of to another database, and maybe even uses git to commit changes. But it's a pretty wild dream, and it's probably better to just use a different platform for new projects, and just wear the pain for the legacy projects.