> And if your hosting server does not support SQLite ... I thought SQLite was file based. What's there to support?
Not sure why any host would disable it, but I could see it happening.
11–20 of 71 posts
> And if your hosting server does not support SQLite ... I thought SQLite was file based. What's there to support?
Not sure why any host would disable it, but I could see it happening.
> And if your hosting server does not support SQLite ... I thought SQLite was file based. What's there to support?
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
It's not a great system.
wget /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
- Have a .htaccess to block it. Only works with Apache of course but that covers most shared hosting.
- Have rewrite rules that takes precedence. Only works if the user enables url rewriting (automatic only on Apache)
- Part of the sqlite database file name will be randomized. eg sqlite_xJ4D6e1E3.db. That usually works well but I suppose in theory it can be bruteforced...
- The documentation will recommend it should be placed outside the webroot but the installer won't do it automatically because it can't safely assume the user has access to the parent folder. Realistically not that many people will end up doing that.
I, for one, am still excited to no longer have to deal with questionable plugin to use wordpress on a mysql-free server.
These utilize WebAssembly (php-wasm) and an SQLite database backend to run a whole WordPress instance in the browser or a local Node.js instance.
Waiting for obligatory comment of "WP sucks. Who still uses PHP in 2023".. On a serious note, this is very interesting. SQLite is just awesome and this will be a welcome addition to the core.
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
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.
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...
wget /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
Thankfully https://roots.io/bedrock/ exists to bridge the gap if you're absolutely forced to use WP.
This 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.