Live data from Hacker News

WordPress Core to start using SQLite

make.wordpress.org

11–20 of 71 posts

Re: WordPress Core to start using SQLite

#11

> And if your hosting server does not support SQLite ... I thought SQLite was file based. What's there to support?

I think you can choose to enable or disable the SQLite driver when compiling php.

Not sure why any host would disable it, but I could see it happening.

Re: WordPress Core to start using SQLite

#12

> And if your hosting server does not support SQLite ... I thought SQLite was file based. What's there to support?

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

Re: WordPress Core to start using SQLite

#13
post #9

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.

It's not a great system.

Re: WordPress Core to start using SQLite

#14

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

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.

Re: WordPress Core to start using SQLite

#15
Related - WordPress recently released WordPress Playground: https://playground.wordpress.net/ along with a wp-now command-line tool: https://developer.wordpress.com/2023/05/23/wp-now-launch-a-l...

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.

Re: WordPress Core to start using SQLite

#16
post #8

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.

Well... it does suck :) is a surprising amount of infrastructure to operate a mostly static website.

Re: WordPress Core to start using SQLite

#17
post #9

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

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.

Re: WordPress Core to start using SQLite

#18
post #9

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

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

Re: WordPress Core to start using SQLite

#19

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

I really wish Wordpress would ditch the shared-hosting first deployment model and grow up a bit.

Thankfully https://roots.io/bedrock/ exists to bridge the gap if you're absolutely forced to use WP.

Re: WordPress Core to start using SQLite

#20

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.

Honest question: why would CI only run a single unit test?
Post reply on HN