WP could make a test suite mandatory and run tests on their hardware under their supported configurations; if it doesn't work on sqlite, it is not accepted in the plugin index.
Likewise, security checks.
Likewise, security checks.
Some of the top plugins available (and are linted) on WordPress.org tend to be stubs containing a lite version plus an ad, and those plugins will have less friction if they entirely self host on their own servers.
The world doesn't need 60,000+ badly-written buggy insecure WordPress plugins.
Adapt or die, and in WordPress's case, preferably the latter.
The world might not, but site operators think they do. It's the biggest appeal of the platform and why agencies have such a tough job doing non-Wordpress work. For better or worse, the simply stupid number of Wordpress plugins out there drive roughly half of all websites on the web today.
Everyone wants their very own special magic guestbook plugin or some damn thing, and they're often very much a "my first PHP module" thing. So it's hardly surprising that they're not the best code or written with particularly safe practices in mind. Guddling about on some old disks a few months ago I found some of the very first PHP3 code I ever wrote, and it's one big SQL injection from start to finish. The 90s were a simpler time...
Roughly half the 404s on the forum I run are some attempt to access WordPress admin pages, which I guess must tell us something.
Well. Considering how WP is basically ~50% of all websites on the planet, that would indeed classify its 'the world' who thinks that they need those 'badly-written' (whatever that means), buggy (is there non-buggy code anywhere), insecure (any software that gets used by 50% of the Internet without security issues?) WordPress plugins.
...
Really, his/her perspective just feels like a junior dev's perspective. Or the perspective of a senior dev who never had to take at least a position like a tech lead. And god forbid any kind of actual interaction with the end users in a given ecosystem.
Could you explain this idea some more? It doesn't seem related to your first suggestion.
Some people just use the svn plugin repos as a release system, the actual development being done in git. There are even github actions to automate it.
I setup builds for most of my oss projects. It's not that hard. Of course at the scale the wordpress community operates, this would require some non trivial amount of resources.
Problem solved, nothing to do for 60,000+ plugin developers.
There is absolutely no need for SQLlite compatibility in WordPress ecosystem. That is 50% of the web. There is no business, user, or programming case that would require it.
The proposition that a software should support something because a browser or a handheld supports it is illogical from the start. Why.
> WordPress’s minimum requirements would be a simple PHP server, without the need for a separate database server.
> SQLite support enables lower hosting costs, decreases energy consumption, and lowers performance costs on lower-end servers.
This can be translated to lower operational overhead and faster loading times for small-database sites, and that equals money.
That doesn't help anything. The complications come from the plugins and themes that make the WP ecosystem. Not the WP core itself.
> SQLite support enables lower hosting costs, decreases energy consumption, and lowers performance costs on lower-end servers.
Thats too extreme a stretch. The flower shop owner in Oregon has bigger concerns than contributing to those with 0.0001%.
> This can be translated to lower operational overhead and faster loading times for small-database sites, and that equals money.
It doesn't, really. The reality of the software and infra costs in the industry is that they are already pretty low. And the meager improvement that will come with adoption of anything - leave aside SQLlite - just do not merit the effort that will go into doing it.
Majority of the web hosts already use reverse proxy caches that directly serve HTML instead of ever contacting the database. This applies to majority of the WP traffic including ecommerce traffic. If you are visiting any prominent WP web host as an anonymous user, you are very likely seeing a static HTML being served to you without db ever being contacted.
And in the case the db is contacted if the host does not have a reverse proxy cache or anything, it is only being contacted to get a minimum amount of information with the simplest of queries, and then again, a static page is being served from a caching plugin's cache.
Going further - if you are actually a logged in user, using a WP website without being served a cache and actual WP queries are happening, the chances are high that few of the queries that are happening can ever benefit from any db engine that is 'more optimized'. The majority will just use standard stuff, with MySQL servers that are already optimized for it.
So, all the glorious improvements that you imagine are not applicable in the real world. That's why nobody will lift a finger for it.