simonwillisonblog-backup VS bedrock

> I’ve been running that for a couple of years in this repo: https://github.com/simonw/simonwillisonblog-backup - which provides a backup of my blog’s PostgreSQL Django database (first converted to SQLite and then dumped out using sqlite-

I'm curious, what is the reason you chose not to use pgdump, but instead opted to convert to to sqlite and then dump the DB using sqlite-diffable?

On a project I'm working on, I'd like to dump our Postgres schema into individual files for each object (i.e., one file for each table, function, stored proc, etc.), but haven't spent enough time to see if pgdump could actually do that. We're just outputting files by object type for now (one tables, function, and stored procs files).

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/m...

Workflow is https://github.com/simonw/simonwillisonblog-backup/blob/main...

If you really, really need to be able to see a SQL schema representing the current state, a cheap trick is to run an automation on every deploy that snapshots the schema and writes it to a GitHub repository.

I do a version of that for my own (Django-powered) blog here: https://github.com/simonw/simonwillisonblog-backup/blob/main...

My blog is Django and PostgreSQL on Heroku, but last year I decided I wanted a reliable long-term public backup... so I set up a scheduled GitHub Actions workflow to back it up to a git repository.

Bonus feature: since it runs nightly it gives me diffs if changes I make to my content, including edits to old posts.

The backups are in this repo: https://github.com/simonw/simonwillisonblog-backup

There are ready-made boilerplates like Bedrock and Sword but, at an architectural level, I'm not a fan of any I've seen.

Node (within the docker container) to build theme assets, composer to manage WordPress core + plugins and other dependencies. I built something similar to Roots for project boilerplate, custom starter theme and in-house mu-plugin within it.

Is this any good? https://roots.io/bedrock/ for a plugin?

As I only really use it for keeping stuff up to date, I'm looking at using Roots Bedrock for my next project. I'll then be keeping everything up to date via composer.

What advantages does WordPlate have over Bedrock[1], some of whose packages WordPlate also uses?

[1] https://roots.io/bedrock/

Probably looking for a https://roots.io/bedrock/

WordPress on containers is a very different beast if you actually want to use any of the advantages of containers. You probably need to figure out how to run upgrades by building a new image and not with the WP installer (which you need to disable to not have sudden version rollbacks). You probably want your plugins managed by compose and not a user. You probably want an S3 plugin for media. In fact, you probably want Bedrock. This is not a "single day task", just taking in the requirements and design phase is easily a day or two.

I'd strongly advice using Bedrock ( https://roots.io/bedrock/ ) and possibly even Sage

No, as far as I know it’s not that easy to accomplish with WordPress. You can use Bedrock (https://roots.io/bedrock/ ) as a Boilerplate for your development process. The Database can not be cloned to each environment that easily. Because every instance is working on it’s own. So if others want to work on their local machine they need a database dump which they have to setup manually on their machine. The only way that comes in my mind is to set up a development site that is accessible for every developer. You could then connect your local WordPress environment with the database from that development site. Everyone would than be working in the same database and everybody could see the changes someone else is making. But I think that wouldn’t be best practice but could be an option.