Earlier quoted context omitted.
- https://roots.io/bedrock/ - https://roots.io/trellis/
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
WordPress Core to start using SQLite
61–70 of 71 posts
Re: WordPress Core to start using SQLite
#62Earlier quoted context omitted.
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
Yes. The content in the database remains the same. Developers can continue creating themes and plugins as they normally would.
Re: WordPress Core to start using SQLite
#63Re: WordPress Core to start using SQLite
#64Re: WordPress Core to start using SQLite
#65wget /wp-content/database Laughing deeply in my whole heart. Also, can't wait to use it (drastically simplify hosting for certain usecases) - hope it will land soon! Long live Wordpres
Re: WordPress Core to start using SQLite
#66It's unfortunately awfully slow. Ten times slower. Probably fine if you never use any plugins, but who does that.
Why is that the case? SQLite isn't inherently slower than MySQL for these kinds of read-heavy uses (it's often faster!).
Re: WordPress Core to start using SQLite
#67I'm happy with any new Wordpress advancement, the only one I still struggle with is Gutenberg which still after however many years of being default leaves a lot to be desired.
Initially I felt the same way about Gutenberg, but it’s starting to grow on me. There’s a setting that understands markdown—so it’s easy to copy over posts from Obsidian when they are close to being ready. Plus the layout does just about everything I want with photos and video. I’m content with it.
The way it also treats Headings, etc as just different blocks from the rest of the text is so annoying. It takes 2-3 clicks to do something you used to be able to do instantly. It feels so unfinished, you just shouldn't have to spend so much time doing very basic things. Very baffling considering it's been out for so long at this point.
Re: WordPress Core to start using SQLite
#68This is great. Apps and frameworks should work with the lowest-common denominator of SQL. I get physically ill when I walk into yet another Rails shop to find that they have used every cool feature of Postgres and as a result, the CI must spin up a huge postgres instance and multiple plugins just to run a single unit test. Ugh.
> Apps and frameworks should work with the lowest-common denominator of SQL. Pointless limitation that will make your app slower and SQL code worse. > I get physically ill when I walk into yet another Rails shop to find that they have used every cool feature of Postgres and as a result, the CI must spin up a huge postgres instance and multiple plugins just to run a single unit test. Ugh. shrug . We (not rails shop) j…
That seems to be the common opinion, but I don't think that it's based on anything tangible.
Re: WordPress Core to start using SQLite
#69This is great. Apps and frameworks should work with the lowest-common denominator of SQL. I get physically ill when I walk into yet another Rails shop to find that they have used every cool feature of Postgres and as a result, the CI must spin up a huge postgres instance and multiple plugins just to run a single unit test. Ugh.
You are advising application developers against using their chosen database optimally? I think it is not needed, I rarely see an application change its database.
Re: WordPress Core to start using SQLite
#70Earlier quoted context omitted.
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'…
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 productio…
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.