[HN Gopher] WordPress Core to start using SQLite
___________________________________________________________________
WordPress Core to start using SQLite
Author : JPLeRouzic
Score : 85 points
Date : 2023-07-26 20:49 UTC (2 hours ago)
(HTM) web link (make.wordpress.org)
(TXT) w3m dump (make.wordpress.org)
| hbcondo714 wrote:
| 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:
|
| https://news.ycombinator.com/item?id=36726593
| dang wrote:
| Url changed from https://blogiestools.com/wordpress-sqlite-
| database/, which points to this.
|
| 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
| mattl wrote:
| Start supporting it natively without a plugin... but most users
| will still use WordPress with MySQL.
| Avamander wrote:
| It's unfortunately awfully slow. Ten times slower. Probably fine
| if you never use any plugins, but who does that.
| phendrenad2 wrote:
| 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.
| karmaMeansCool wrote:
| 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.
| sodapopcan wrote:
| Honest question: why would CI only run a single unit test?
| ilyt wrote:
| Well, if you're currently writing one unit test, and want to
| test that test...
| ilyt wrote:
| > 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
| radiator wrote:
| 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.
| hoherd wrote:
| While I agree, it's amusing to see this comment in a thread
| about an application providing a new database, and where one
| of the main reservations is around people needing to change
| the DB.
|
| > WordPress developers who do not agree with the idea of
| introducing SQLite in WordPress core are mainly concerned
| about ... migration process or converting from one database
| to another
| jraph wrote:
| 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)
|
| I bet we are many people in this case.
| ilyt wrote:
| > 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:
|
| https://www.sqlite.org/backup.html
| codegeek wrote:
| 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.
| vcryan wrote:
| Well... it does suck :) is a surprising amount of
| infrastructure to operate a mostly static website.
| jraph wrote:
| The weight of WordPress is a bummer. On the other hand, it
| usually covers any use-case, even those you don't know yet,
| while still remaining usable by non-technical people, which
| is quite a feat.
| pessimizer wrote:
| You did the opposite of waiting; you made it.
| throwaway888abc wrote:
| 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
| giancarlostoro wrote:
| Really should be in a parent directory that will never be
| visible by anyone's browser.
| ilyt wrote:
| Which is not how wordpress install is set up to work, because
| of both webhost and wordpress developers incompetence
| stefanos82 wrote:
| 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/sqlit
| e/database/file/');` to define the database location of my
| choice; I believe they would let users do the same with core
| support.
| amiga-workbench wrote:
| 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.
| tredre3 wrote:
| 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.
| h0l0cube wrote:
| 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
| orev wrote:
| 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.
| bsder wrote:
| > the use for Wordpress is an audience who needs a full
| application to manage a site.
|
| The use case for WordPress is businesses who don't really
| need a website at all but everybody demands that they have
| one and they want to outsource running a website so you can
| blame somebody else when it gets hacked into and can tell
| your marketing and sales department go bother somebody else
| about the website. <Raises hand>.
|
| Anybody who _actually_ needs an application to manage their
| site has staff and they don 't use WordPress.
| h0l0cube wrote:
| > needs a full application to manage a site.
|
| AFAICT it's not that. It's that most shops want the ability
| to edit content without a developer. But such a requirement
| doesn't mandate that data lives in a database vs something
| like, say, a set of plain-text files, that would be amenable
| to version control and diffing
| simonw wrote:
| 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...
| sjmiller609 wrote:
| That is awesome! Did you consider using the temporal_tables
| extension? I think it's basically like version history for
| tables. I haven't used this before personally though.
| https://pgt.dev/extensions/temporal_tables
| clintonb wrote:
| - https://roots.io/bedrock/
|
| - https://roots.io/trellis/
| solardev wrote:
| 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.
| CodeCompost wrote:
| > And if your hosting server does not support SQLite ...
|
| I thought SQLite was file based. What's there to support?
| jay3ss wrote:
| Maybe something like Heroku?
| nfriedly wrote:
| 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.
| ItsABytecode wrote:
| 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
| whalesalad wrote:
| would be pretty neat to run a wasm wordpress on cloudflare pages
| or fly.io at the edge, with a copy of the full site db there too.
| partiallypro wrote:
| 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.
| tedivm wrote:
| > 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.
| mopsled wrote:
| 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.
___________________________________________________________________
(page generated 2023-07-26 23:02 UTC)