This is good news. It will allow me to drop MariaDB, only used for a few low traffic websites I manage, making my things more robust, more lightweight and easier to maintain.
I don't care for managing ports / sockets, migrating configurations, doing the creating database (careful not to use the not-really-utf-8 charset), user and granting privileges dance. Overkill for my use case.
Backups will also be easier: a simple rsync call will do, no need to call the specific mysql backup command anymore (of course it's automated but that's one less thing that can fail, less moving parts)
> Backups will also be easier: a simple rsync call will do, no need to call the specific mysql command anymore (of course it's automated but that's one less thing that can fail, less moving parts)
Technically, that's incorrect way of doing it; practically it rarely fails (as writes are usually much rarer in many cases SQLite is used, especially if you backup in the middle of the night, and format itself is pretty resilient), but you should be doing one of methods here:
> They suggest that if the plugin grows to a million plus installations, then it would support the desire for SQLite to be introduced in WordPress core. As of publishing this article, the plugin had 30 installations.
This is a poison pill suggestion. I would absolutely switch to SQLite for my blog, but I'm not going to make that commitment using a plugin for something as important and central as the database layer. It's kind of ridiculous to even consider that, to be honest.
With a plugin I have to go through the installation process, install the plugin, migrate the data, and then serve my blog. No one is going to do that. With plugins I'd also be scared that I'd be locked out of upgrades in Wordpress if the plugin lagged behind, and I would definitely worry about the plugin being dropped altogether. Those concerns go away completely if it's built right into Wordpress itself. That's on top of the fact that the plugin explicitly states that it's for testing.
Good for them! Perhaps this is an action item that came out of their WordPress Playground: A WordPress that runs entirely in the browser as discussed here:
They’re probably thinking of shared hosting environments that don’t have the SQLite library for PHP installed. That seems like a concern you could raise about any database connector, though
If a service provider doesn't provide a service you require, then find another provider!
With a bit of effort you can run WP on say a RPi or an Odroid. Use a free dynamic DNS service to get it out there. A couple of NAT port forwards on your router. Lets Encrypt gets you a free SSL cert. A bit of research into web servers gets you an A+ score at SSL labs and a frisson of security! WP has some app firewall style addons and the web server eg apache or nginx have some useful addons and modules.
Self hosting isn't for everyone, obviously. You are not restricted in any geopolitical sense when choosing a provider. If say, you are living in the US, you can rent a VPS in say Germany and crack on.
You can also get quite a lot of Cloudflare for free, for example.
Its 2023 and the options for publishing on the internets are absolutely astonishing. I used to use telnet to get to a rather plain text thingie at CERN back in the day (1994ish). Obviously the estate has changed somewhat since the and we have to deal with some really nasty issues that the early web didn't have.
I argue that self publishing is the only way to go but please either get yourself clued up on the security aspects of IT or hire it in or ensure your external platform is segregated from your non platform stuff (that might be VLANs, for example).
We all have an intrinsic ability and I think an inalienable right to be able to communicate a message. Not all messages are welcome and that is where things get tricky. I think we also have a right to not receive messages that we might find offensive. There is no agreed approach to "offensive". There are several "societal norms" and the like but those change depending on say location or even current mindset.
The internet allows anyone to communicate with anyone, via social media and other madness! That means that a Masai warrior, wandering the veldt and looking for a lion to take on, his asegai trembling in his hand so he can advance to manhood and then his phone finds a base station and he might suddenly be chatting with a child from the Netherlands (they both subscribe to the same Facebook Barbie fan group)! That is obviously nonsense but the world is really, very, very connected these days.
Oh sorry, SQLite? I have no idea why WP hasn't supported it for years. It is quite literally the obvious first choice. How many bloggers do you know that are also closet DBA's?
The usual mitigation for safely using sqlite in PHP projects is as follows:
- 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.
Before they added SQLite as WP plugin, I would use https://github.com/aaemnnosttv/wp-sqlite-db/ and I would use `define('DB_DIR', '/absolute/custom/path/to/directory/for/sqlite/database/file/');` to define the database location of my choice; I believe they would let users do the same with core 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
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.
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.
I'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.
i remember a long time ago we used 3dcart as our ecommerce platform which used MSAccess as the database backend. I laughed my ass off at the time, but came to realize that 99% of their customer were like us... maybe did 5K a month in sales so not a huge amount of traffic so why pay for the license and cost of SQL Server. This is actually a really good move for WP as it will free up alot of resources on the server and simply deployments and migrations.
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.
> 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) just create temporary database, pass it to CI test, remove after. Picking database because your CI is done badly is like one of the worst ways to decide on architecture
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.
I don't know if all the blame goes to postgres or not, but a unit test in Rails is typically what others would call an integration test and Rails' architecture is more to blame than SQL. If someone chooses to use postgres in their application, don't be surprised when you see code that uses postgres. Wanting to force others to make applications that work with the lowest-common denominator of SQL could make one appear naive, and that you might not have ever faced the same problems others developers have faced.
[+] [-] jraph|2 years ago|reply
I don't care for managing ports / sockets, migrating configurations, doing the creating database (careful not to use the not-really-utf-8 charset), user and granting privileges dance. Overkill for my use case.
Backups will also be easier: a simple rsync call will do, no need to call the specific mysql backup command anymore (of course it's automated but that's one less thing that can fail, less moving parts)
I bet we are many people in this case.
[+] [-] ilyt|2 years ago|reply
Technically, that's incorrect way of doing it; practically it rarely fails (as writes are usually much rarer in many cases SQLite is used, especially if you backup in the middle of the night, and format itself is pretty resilient), but you should be doing one of methods here:
https://www.sqlite.org/backup.html
[+] [-] tommy_axle|2 years ago|reply
[+] [-] fmajid|2 years ago|reply
[+] [-] tedivm|2 years ago|reply
This is a poison pill suggestion. I would absolutely switch to SQLite for my blog, but I'm not going to make that commitment using a plugin for something as important and central as the database layer. It's kind of ridiculous to even consider that, to be honest.
With a plugin I have to go through the installation process, install the plugin, migrate the data, and then serve my blog. No one is going to do that. With plugins I'd also be scared that I'd be locked out of upgrades in Wordpress if the plugin lagged behind, and I would definitely worry about the plugin being dropped altogether. Those concerns go away completely if it's built right into Wordpress itself. That's on top of the fact that the plugin explicitly states that it's for testing.
[+] [-] lolinder|2 years ago|reply
Edit: It looks like at some point the article was changed to point to the official WordPress site, I think this was the original link:
https://blogiestools.com/wordpress-sqlite-database/
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] hbcondo714|2 years ago|reply
https://news.ycombinator.com/item?id=36726593
[+] [-] CodeCompost|2 years ago|reply
I thought SQLite was file based. What's there to support?
[+] [-] ItsABytecode|2 years ago|reply
[+] [-] nfriedly|2 years ago|reply
Not sure why any host would disable it, but I could see it happening.
[+] [-] gerdesj|2 years ago|reply
With a bit of effort you can run WP on say a RPi or an Odroid. Use a free dynamic DNS service to get it out there. A couple of NAT port forwards on your router. Lets Encrypt gets you a free SSL cert. A bit of research into web servers gets you an A+ score at SSL labs and a frisson of security! WP has some app firewall style addons and the web server eg apache or nginx have some useful addons and modules.
Self hosting isn't for everyone, obviously. You are not restricted in any geopolitical sense when choosing a provider. If say, you are living in the US, you can rent a VPS in say Germany and crack on.
You can also get quite a lot of Cloudflare for free, for example.
Its 2023 and the options for publishing on the internets are absolutely astonishing. I used to use telnet to get to a rather plain text thingie at CERN back in the day (1994ish). Obviously the estate has changed somewhat since the and we have to deal with some really nasty issues that the early web didn't have.
I argue that self publishing is the only way to go but please either get yourself clued up on the security aspects of IT or hire it in or ensure your external platform is segregated from your non platform stuff (that might be VLANs, for example).
We all have an intrinsic ability and I think an inalienable right to be able to communicate a message. Not all messages are welcome and that is where things get tricky. I think we also have a right to not receive messages that we might find offensive. There is no agreed approach to "offensive". There are several "societal norms" and the like but those change depending on say location or even current mindset.
The internet allows anyone to communicate with anyone, via social media and other madness! That means that a Masai warrior, wandering the veldt and looking for a lion to take on, his asegai trembling in his hand so he can advance to manhood and then his phone finds a base station and he might suddenly be chatting with a child from the Netherlands (they both subscribe to the same Facebook Barbie fan group)! That is obviously nonsense but the world is really, very, very connected these days.
Oh sorry, SQLite? I have no idea why WP hasn't supported it for years. It is quite literally the obvious first choice. How many bloggers do you know that are also closet DBA's?
[+] [-] Gigachad|2 years ago|reply
[+] [-] jay3ss|2 years ago|reply
[+] [-] throwaway888abc|2 years ago|reply
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
[+] [-] tredre3|2 years ago|reply
- 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.
[+] [-] stefanos82|2 years ago|reply
[+] [-] giancarlostoro|2 years ago|reply
[+] [-] amiga-workbench|2 years ago|reply
Thankfully https://roots.io/bedrock/ exists to bridge the gap if you're absolutely forced to use WP.
[+] [-] indymike|2 years ago|reply
[+] [-] mopsled|2 years ago|reply
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.
[+] [-] dang|2 years ago|reply
Submitters: "Please submit the original source. If a post reports on something found on another site, submit the latter." - https://news.ycombinator.com/newsguidelines.html
[+] [-] h0l0cube|2 years ago|reply
[+] [-] simonw|2 years ago|reply
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...
[+] [-] clintonb|2 years ago|reply
- https://roots.io/trellis/
[+] [-] solardev|2 years ago|reply
It's not a great system.
[+] [-] orev|2 years ago|reply
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.
[+] [-] partiallypro|2 years ago|reply
[+] [-] samsolomon|2 years ago|reply
[+] [-] notjoemama|2 years ago|reply
[+] [-] thrownaway561|2 years ago|reply
[+] [-] whalesalad|2 years ago|reply
[+] [-] Avamander|2 years ago|reply
[+] [-] ripley12|2 years ago|reply
[+] [-] mattl|2 years ago|reply
[+] [-] codegeek|2 years ago|reply
On a serious note, this is very interesting. SQLite is just awesome and this will be a welcome addition to the core.
[+] [-] pessimizer|2 years ago|reply
[+] [-] vcryan|2 years ago|reply
[+] [-] phendrenad2|2 years ago|reply
[+] [-] ilyt|2 years ago|reply
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) just create temporary database, pass it to CI test, remove after. Picking database because your CI is done badly is like one of the worst ways to decide on architecture
[+] [-] radiator|2 years ago|reply
[+] [-] karmaMeansCool|2 years ago|reply
[+] [-] sodapopcan|2 years ago|reply