Re:Dolt is Git for Data: a SQL database that you can fork, c...
by berkes on Sunday March 07, 2021 @04:04AM
(#26374373)
At the root of this lies the problem that content, configuration and code is stored in one blurp (a single db). Never clearly bounded nor contained. Config is spread over tables. Usergenerated content (from comments to orders) mixed up with redactional content: often even in tables, sometimes even in the same column. Drupal suffers the same.
What is needed, is a clear line between configuration (and logic), redactional content, and user generated content. Those three have very distinct lifecycles. As long as they are treated as one, the distinct lifecycles will conflict. No matter how good your database merging is: the root is a missing piece of architecture.
Re:Dolt is Git for Data: a SQL database that you can fork, c...
by Hallucinaut on Sunday March 07, 2021 @02:14PM
(#26378778)
Very well summarised. I can see clearly you too have tried to apply normal software lifecycle principles and come out the other end with a rather dismal impression of WordPress.
Re:Dolt is Git for Data: a SQL database that you can fork, c...
by TimTheTinker on Sunday March 07, 2021 @02:38AM
(#26374035)
Sure, but Wordpress is still running PHP files for every page load and back-end query. Dolt would help offload some of the code’s complexity, but that would still leave a significant attack surface area.
In other words, by itself Dolt couldn’t solve the problem of Wordpress not being run mostly from static assets on a server (plus an API).
Re:Dolt is Git for Data: a SQL database that you can fork, c...
by kenniskrag on Saturday March 06, 2021 @06:33PM
(#26371545)
they have a theme preview now. :)
Re:Dolt is Git for Data: a SQL database that you can fork, c...
by jimsmart on Saturday March 06, 2021 @09:24PM
(#26372561)
The parent post here is speaking to the content stored in the database, not the templates on the filesystem. Dolt enables one to merge, push and pull data, just as one would with files and git.
What a lot of webmasters want is, test the site locally, then merge it back. A lot of people turned to Jekyll or Hugo for the very reason that it can be checked into git, and git is reliable. A static website can’t get hacked, whereas anyone who has been burnt with Wordpress security fail knows they’d prefer a static site.
And even more: People would like to pass the new website from the designer to the customer to managers — Wordpress might have not needed to develop their approval workflows (permission schemes, draft/preview/publish) if they had had a forkable database.