I can see that the difficulty will be the plethora of plugins that for whatever reason won't end up being compatible, and the Wordpress community will quickly consider SQLite a "broken database" or similar.
For example, one of the most common plugins is Yoast, I'm sure somewhere in this spaghetti something will be MySQL specific.
One of the people cited as being involved in the discussion at WCEU (a major WordPress conference) is Joost de Valk, the creator of Yoast (and currently interim CTO of Yoast). I would suspect if any plugin invests in making sure it's compatible, it'll be Yoast SEO. :)
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.
And the plugin authors would simply self-host them.
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.
Too many people doing that will mean that what you're looking for just won't be in the main (GPL?) plugin area. My own experience years ago was that for many folks, if it wasn't in there, it didn't exist. Downloading and FTPing 'out of store' plugins just wasn't something that folks wanted to get in to. Those projects may have been a minority of the overall username, but it wasn't an insignificant number of projects I knew about. Perhaps that attitude has changed in the last several years?
> The world doesn't need 60,000+ badly-written buggy insecure WordPress plugins.
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.
You're right, and "think" is doing a lot of work there.
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.
> The world might not, but site operators think they do
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.
They really need to force all plugins to pass the VIP phpcs rules (would need to be modified a bit). It wouldn’t be perfect but I bet it would greatly increase security. I’d also like to see them switch to git for the plugin repos.
Would not be a bad idea. With Github actions, doing CI builds for plugins and wordpress should be fairly easy to do with either dockerized mariadb or sqllite. Set up a little matrix build. And for good measure, maybe support nginx and posgresql as well out of the box. Nothing to incentivize plugin developers as having a few red warnings next to their name in the plugin registry.
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.
Your very comment would be enough to turn off 60,000+ plugin developers and 50% of the web who uses WordPress. Nobody likes anything being forced on them there. Less, non-prominent OSS projects trying to force their way in through such arrogance.
WordPress will surely rot if a rather-weakly adopted database engine is not forced upon its entire ecosystem. You can be sure that the flower shop owner somewhere in Idaho, who uses WooCommerce for his flower business and the random anime blogger somewhere in Tokyo, who uses WordPress for blogging, will be hampered by that.
Are you saying that SQLite is weakly adopted in general or weakly adopted in WordPress? The former is rather far from the truth[1], while the latter is rather obvious given that WordPress doesn't support it yet...
Leaving aside that the claims there need to be taken with a grain of salt since there are equal comparisons for most other engines:
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
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.
Remembering the horror that was my first encounter with a description of MySQL as a DBMS, by a far from newly minted* WordPress hosting entrepreneur, the greater difficulty may be overcoming cultural cognitive dissonance that Database != MySQL.
*as a Flash website developer my friend wrote a blood insulin device graphic from spec so completely down to knowing time drift, his unintended emulation was used for regulatory approval purposes.
How Oracle never capitalized on acquiring MySQL as leverage into small businesses via WordPress beggars my belief. But I'll wager that the kind of problems discussed here come into it.
I was expecting some really esoteric SQL used in that file but the most advanced query I see contains a subquery with a union. Does SQLite not support these basic features?
I didn't spend time looking for specific features, as much as pointing out the standard is to be extremely hand wrangled and therefore prone to such issues. I have no idea if this sort of nonsense (this is an official Automattic plugin) is going to work in SQLite:
"This sort of nonsense". I don't think you know what this plugin is actually doing, but it seems to be a backup plugin. So I don't think seeing MySQL specific stuff there is worth mentioning. I think you're trying a little bit too hard buddy
I work with PHP every single day and thankfully never encounter anything like this and certainly don't write it.
You should see some of the C++ I see everyday. My favourite is a single 20,000 line God file called extractor_manager.cpp that merges data from MS Access and MySQL using a variety of typo'd command line arguments.
The culprit is not PHP, the culprit is WordPress being developed with antiquated software engineering practises (or rather, lack of any good practice).
Obviously, because s/he, the languages, stack and software he uses, his software development practices etc are all way better than the WordPress ones. Thats why they are bad. And that's why it is his language, stack and app that is 50% of all websites and 30% of all ecommerce sites in existence. Not WordPress.
So if I'm following correctly, you are saying that WordPress was successful in the first place because of its high code quality and software development practices, right?
WordPress works great from a business standpoint, but it is not well made.
I've spent the past month developing plugins for my own WordPress website, and it is laughable how bad it is. I mean, the official advice to understanding things is not to read their documentation, it's "look through the code lol" [1].
It's probably fair, since their documentation is so bad it does not explain what any of the parameters of the functions are most of the time, accepting a map that you don't know the possible values of unless you read their code.
And, well, that code was probably okay in 2005, but it's hot garbage in 2022.
>I've spent the past month developing plugins for my own WordPress website, and it is laughable how bad it is. I mean, the official advice to understanding things is not to read their documentation, it's "look through the code lol" [1].
This particular advice of looking through the code is for finding "appropriate hooks", if you've had to work with WordPress to implement a fairly customised solution then you'd have realised that you often find yourself in a place where you need to perform some task at a particular time in WP Core's or some other plugin's code's execution ( the very use-case of hooks in WP ), no documentation can effectively help you in finding the appropriate hook. With a little bit of experience in writing WP code you'd realise that it's far more easier and faster to open to source code and and look for `apply_filters` or `do_action` calls than opening documentation.
> So if I'm following correctly, you are saying that WordPress was successful in the first place because of its high code quality and software development practices, right?
WordPress was successful because it prioritized its users' needs and backwards compatibility over high code quality and software development practices.
> WordPress works great from a business standpoint
Yeah. That's whats important to 50% of the web and 30% of ecommerce websites.
> but it is not well made.
There is the critical angle - users don't give two shts about that. Many 'well made' apps, frameworks, projects faded away over the decades because they were 'well made' first, and 'user-oriented' second.
'Well made' code and 'good programming practices' made their inroads into the WP project and ecosystem in the past decade. They really did not provide much value compared to the complications they brought. And most were just discarded or they just faded away.
> I've spent the past month developing plugins for my own WordPress website, and it is laughable how bad it is
Its not. From the moment you catch on to the common practices, its a delight. Code is easy to write. Its immediately compatible with 60,000+ plugins, you immediately get access to 50% of the web. There is nothing comparable.
> the official advice to understanding things is not to read their documentation, it's "look through the code lol" [1].
That relates to the plugin ecosystem. Not the core. And for the plugin ecosystem, that is true - its faster to check through the code of many plugins than going through the documentation. If you have such a need to develop a plugin for ANOTHER plugin, which is an independent project than WP core itself, that's pretty normal. And it beats the majority of OSS projects in that sense anyway - you have flexibility.
> It's probably fair, since their documentation is so bad it does not explain what any of the parameters of the functions are most of the time
Huh? All the functions in the core have their documentation in trac and multiple other places.
> And, well, that code was probably okay in 2005, but it's hot garbage in 2022.
Users don't give a sht about that. That hot garbage in 2022 still works like it worked in 2005. The small store owner somewhere in the US or the NGO somewhere in Asia never had to upgrade anything on their site for it to keep working. THAT is why they love WordPress. Because it helps them run their businesses and lives than having them deal with programmers' trappings about 'cool code'.
...
Your approach and the approach of various others in this thread seem to be a simple case of engineers' perspective being totally out of touch with the perspectives of the actual users. You think something is 'better'. Whereas to the actual user, they are not. This actually explains how large engineering-oriented organizations like Google can fail their user base so easily.
> Your approach and the approach of various others in this thread seem to be a simple case of engineers' perspective being totally out of touch with the perspectives of the actual users.
You answered in a thread of which the initial comment was "seeing this code, I’m happy that I no longer do PHP", why would you expect us to be talking about anything else than the technical aspects?
You're just completely out of topic so I won't waste my time answering the rest of your statements.
half the style guide is taken up with nonsense about tabs and spaces, ridiculous requirements on conditionals, and what seems to be a lack of decent SDLC.
I've given up on it dying. It's too entrenched. It does what it needs to in a way that isn't awful for the end user, and the barrier of entry is so low that developers are cheap and plentiful. And it's old enough that the ecosystem is really broad and can do what 99% of people require.
> seeing this code, I’m happy that I no longer do PHP
The file linked is relatively OK though compared to what's out there (in any language). Or maybe I'm just used to diving knee-deep into decade old 10,000 LOC files and a bit jaded...
Just to note, Make/Core is a relatively open discussion site where contributors to WordPress can post proposals, and this does not necessarily indicate an official plan at this stage. It certainly might become one, but this is currently a proposal requesting discussion to form consensus.
I certainly hope they do not add an ORM into WordPress.
It would add a big layer of complexity and break nearly
all plugins that interact with the database.
This can be mitigated by maintaining and updating both
the database access as it is today as well as the ORM
layer.
Which would probably mean some plug-ins using one and some
the other. Perhaps over a long enough time scale converging
for the ORM.
Right now debugging problems with the interaction between
database and application are blessed by it being fairly transparent
Adding a messy layer in between adds complexity not worth it
unless it is required to add support for many other databases
and I dont see any reason why it would be beneficial for enough
users for that to be worth it.
Introducing just SQlite will expose a lot of problematic edge cases.
since MySql provides a lot of feature that Sqlite does not.
(which in most cases is a very good thing)
I don't think this is a correct take, because most plugins that interact with the database already use the abstraction functions, eg get/set_option(), WP_Query, get_post_meta() and so on.
2. Plugins that do direct queries against the standard database schema (broadly either for invalid (bad code) or performance (valid but slim use case) reasons)
Also, WordPress would of course keep the old query functions around and they would likely add a tag to the plugin repository so authors can mark plugins as supporting thes new ORM features.
Combine SQLite WordPress with the PeachPie Blazor.NET Wordpress (step debugging the PHP in Visual Studio) and ding ding ding we have a winner for security scalability and resource efficiency
and are deploying features and getting feedback from your users 10x faster and ideally uncovering future valuable things that need solving. Good problems to have IMHO... validation quickly and build build build
it works for debugging but xdebug is definitely harder to configure and...
- feels 5x more sluggishly slower than PeachPie in Visual Studio
- not giving you any of the other runtime-speedup or deployment and security and scalability advantages that PeachPie gives you...
Peachpie + wordpress + SQLite will be a very portable stack
nowhere as efficient as Redbean, except the functional convenience of giving you most of PHP and Wordpress now locally deployable as a "desktop sidecar" in your .NET project publish agglomerations
Seems like a good idea - use [WAL mode](https://sqlite.org/wal.html), and UUID based filename to provide obfuscation for the path and it should be a neat encapsulated installation.
You could also place the database outside the web root. As far as I know WordPress already supports putting `wp-config.php` one directory up from the main installation.
I am all for WordPress building a database abstraction layer, but supporting explicitly one specific new database is a step in the opposite direction. It will just make it harder to implement such a layer in the future.
This could spiral into some interesting combinations. Imagine Redbean with PHP support, and it already includes SQLite. You could keep your entire site: PHP, database, files - in one file that also runs your web server, and it works on multiple operating systems.
I would go further than the writer and say SQLite would be appropriate for almost all WP applications. Offhand, I can’t think of a meaningful use case that would make MySQL more preferable to SQLite.
The proposal mentions improving performance, I'm curious if anyone has an "ideal" set up for WordPress architecture? There are so many server configurations and caching solutions out there.
Yes, I'm pretty sure SQLite would be more than enough for a lot of sites.
The point I was trying to make was that, if you are going to add SQLite support, you might as well add some tooling to help you switch between databases.
> No one is required to follow The Rule, to know The Rule, or even to think that The Rule is a good idea. The Founder of SQLite believes that anyone who follows The Rule will live a happier and more productive life, but individuals are free to dispute or ignore that advice if they wish.
As opposed to a standard contributor covenant based CoC, which is totally not religious at all.
I'm not sure the one that says this is the worst option here: (22-34)
Do not give way to anger.
Do not nurse a grudge.
Do not entertain deceit in your heart.
Do not give a false peace.
Do not forsake charity.
Do not swear, for fear of perjuring yourself.
Utter only truth from heart and mouth.
Do not return evil for evil.
Do no wrong to anyone, and bear patiently wrongs done to yourself.
Love your enemies.
Do not curse those who curse you, but rather bless them.
Bear persecution for justice's sake.
Be not proud.
Not defending Contributor Covenant nor SQLite's Code of Ethics, but since you're being overly sarcastic: how is Contributor Covenant anywhere in the same category of religiosity as a Code of Ethics that literally invokes Christian doctrine by name and is directly based on a Christian book?
I get that people use "religious" in hyperbolic ways but the SQLite Code of Ethics is literally religious in the original sense of the word, not some handwave-y "they're taking it very seriously and encoding value judgements some people disagree with" way.
Yeah I didn't quite get this either, personally I have no problem with the SQLite code of ethics because of its inclusion of "individuals are free to ignore or dispute this". But it does also include such lines as "Put your hope in God." and "Be in dread of hell.", which do make it an explicitly and objectively religious/Christian document, which would put it in a different category to mostly secular contributor covenants or codes of conduct in my opinion
Personally I'm fine with the Code of Ethics despite being an atheist as it explicitly doesn't apply to outside contributors and presumably the core team is fine with it (and if they aren't, that's for them to discuss internally, not for me to complain about).
Never cared about it, nor do now, neither do the thousands of major products and companies that embed it in their apps, code, etc. (from Gooogle Chrome to Apple's stuff to Adobe Lightroom to Dropbox, FOSS distros, hardware devices like routers, and countless others).
Nor does it bother contributors, to any degree that impacts this being one of the most well maintained, regularly updated, thoroughly tested and bugfixed, and stable FOSS of all time - if not the best in most of those regards (which is also the reason of its huge mission-critical adoption from the biggest names in the industry).
If this indeed has ever bothered anyone, it's still one of the most inconsequential bothers of all time...
edit: The page also contains the stronger statement wmanley quoted, so it wasn't a misleading quote as I initially assumed. I counted a total of 5 committers in the last year, so it does indeed look like SQLite does not accept outside contributions at all, even with a public domain dedication.
That page says:
> the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain
which is quite different from your shortened quote. This sounds similar to the CLA many projects require for contributions.
How many outside contributions does SQLite accept in practice?
Isn't it the point of the code of conduct to put off troublesome people and to facilitate collaboration between contributors? Maybe it works as intended?
Short for "globally homogeneous", globohomo is a pejorative term for globalisation. Often used by the type of people who believe that globalism is a Jewish plot to undermine Western tradition.
Urban Dictionary is split on the issue, so either a half-witted claim about globalism enforced homogeneity of thought (read: criticism of neoliberalism) or the tragically stupid alternative "globalist homosexual agenda" (read: being asked not to be *-phobic). Either way not a super constructive point with a hint of dog whistle.
Why didn't you do five seconds of research, opened up https://sqlite.org/codeofethics.html and confirmed the claim instead of accusing osmeone of lying, being a bad actor, and demanding an apology for someone else?
The cons that the author of the post lists make it a no-go. From SQLite not going to work well on sites with multiple authors (a killer from the start) to 'web hosts NEEDING TO ACT RESPONSIBLY' for this to work, literally make this the effort of a OSS project unknown to the WP ecosystem (50% of the web) to force its way into that ecosystem withouth having found any widespread use and people having accommodated it.
If it was worth doing it, someone would have published a plugin for it and it would have been working already. WordPress provides filters for database functions as well. So whatever db you want to use, could be reliably integrated by injecting yourself in between the functions and the db.
Of course, this means that you will immediately face compatibility problems with all the 60,000+ plugins in the ecosystem. And those plugins wont make themselves compatible with SQLite, neither they will accept delirious propositions like 'Make it a requirement for getting accepted to plugin directory'.
People have businesses to run, lives to live. WP ecosystem is not a weekend OSS hobby project for 50% of the web that it runs. People's income, their livelihoods depend on it. Users and developers alike. Nobody will take such arrogance to force them to accommodate some obscure OSS project. Obscure, because you can be sure that 50% of the web that use WordPress have no idea what SQLite is. You, the other ecosystems that you are in and contributing, your professional circle, may have. But the average flower shop owner somewhere in the US and the anime blogger somewhere in Japan, have no freaking idea what SQLite is. And they don't care. They have other things to care about than an OSS project that is unknown to them.
The propositions and the mentality in this thread sound extremely arrogant, and it reminds one about the time when Google tried to force Google+ on the people by forcing them to link their Youtube accounts to Google+. We know how that ended up.
If the OSS project that you love is not gaining traction in a certain demographic, its because it doesn't have use cases there and it does not accommodate those people enough. You cant force people to use it in such a case. You must make it accommodate an actual need and make it easy to use it. Not try to force your way into another ecosystem.
There are those who seem to belong to that community and who seem to literally force themselves. This may be the result of the religious nature of the project as hinted by its religious code of conduct. Just check the different comments in this thread.
I asked you to cite an instance but you declined. An example would be a reasonable basis for discussion. Accusing me of bias doesn't more the debate forward.
If you are unable to see the outrageous comments in this very thread that are so bluntly visible, going to the extremes of calling it to be made a requirement for getting a plugin listed in the repo, then it means that you just dont want to see them. There is no basis for discussion in such a case.
> From SQLite not going to work well on sites with multiple authors (a killer from the start)
This is taken out of context and blown out of proportion. The post says:
"If multiple authors are editing posts on a site and updating them at the same time, then their save requests would run one after the other instead of simultaneously – so there would be a small delay (probably milliseconds, but still a delay)."
So, sure, if your site is so busy that multiple authors are posting within milliseconds of each other, there might be some extremely minor performance issues with SQLite.
See, your question is an excellent example of how little the mainstream tech understands the WP ecosystem:
In any WP site, any user that uses a feature is someone who 'saves content'. They don't need to be an editor. The average user that is commenting on a WP blog, the average customer that is using a WP ecommerce site, the directory user that is bookmarking local lawyers in his area - all of these send write operations to the db. Because all of those features are represented as either custom posts in the database. If a plugin does not use the WP post system, then it still writes to its own tables.
So basically any write action taken in a WP site is very likely a 'post'. Its confusing, so just take the word 'post' as 'data type'. The blog posts in a WordPress site are just data with the type 'post'. WooCommerce products in a WP ecommerce site are just data with the type 'product' and so on.
Therefore, even in a middling WP site with ~1 million unique views/month, you WILL have at least hundreds of users hammering the database with the actions they take.
When you go one level up, things get even more complicated:
There is a WP feature called 'Multisite'. This allows you to provide an infinite amount of WP sites over just one single WP installation by sharing the database and the main files. A lot of big WP sites function like this, including the WordPress.com service that Automattic provides. (50% of all WP sites are there, so 25% of all world's websites).
Which means that in such a Multisite WP installation, there will be at least tens of thousands of site owners, whose blogs, e-stores or sites are serving hundreds of thousands of users at the least. (For smallish WP hosts, nonprofits, communities).
This means that yeah, you will be facing write operations that are much more than 1000 times per second.
...
Regardless, one minor performance situation is not the argument that makes it infeasible to introduce SQLite or any other db engine. The compatibility is king in WP ecosystem - ecosystem-wide and backwards. Just like in any ecosystem that has been able gain and serve a large user base on the Internet.
There wasn't just one con listed in his post at WP org. I just took two of them. There are various others which he honestly lists without realizing that various of them are game-breakers.
> missed sqlite PRAGMAS which would make it behave entirely equal to mysql
More the reason for this being done through a plugin instead of being pushed into WP core. If it provides noticeable improvement and people use it, it will get installed by millions of people. If it does not, it wont.
No. Instead let's make dokuwiki officialy support git as its backend!
So i can push/pull dokuwiki content for purposes of backup, deployment, offline access and commandline editing :-)
Why use custom PHP based history tracking solution, when we already have state of the art version control in git?
For example, one of the most common plugins is Yoast, I'm sure somewhere in this spaghetti something will be MySQL specific.
https://github.com/Yoast/wordpress-seo/blob/0efeda377ea09931...