Let’s make WordPress officially support SQLite
make.wordpress.org
make.wordpress.org
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...
*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.
Likewise, security checks.
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.
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.
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.
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.
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.
Doesn't mean C++ is a bad language.
Just take a look at their coding guidelines: https://developer.wordpress.org/coding-standards/wordpress-c... they're laughably bad and nonsensical.
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.
[1] https://developer.wordpress.org/plugins/hooks/filters/#add-f...
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.
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.
Because the 'non-technical' aspects are what determine this entire discussion.
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.
I keep waiting for WP to die and it never does.
It's all awful code, of course.
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...
https://github.com/Automattic/jetpack/blob/2447e267e40f2d133...
But certainly creating a new table with ENGINE= which you can also find in that file isn't likely to work as intended on other platforms.
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)
These would all work out of the box.
The only plugins that would not work are:
1. Plugins that register their own database tables (however there already exists prior art such as https://github.com/aaemnnosttv/wp-sqlite-db for handling these cases)
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.
Great idea in my opinion!
- 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
Does this compile PHP to dotNet? Looking at the csproj files I cant find the magic dust that enables this.
if it does not compile PHP -> dotNet I find the documentation to be confusing.
Does this create a dotnet proxy / bridge to a regularly running PHP Wordpress site?
Why? Then I could store my WordPress folder in git and realistically merge changes between copies of my website.
Abstract it or don't do it.
It doesn't do what happens in your world well.
It's not hard to clone MariaDB, but sqlite is much more practical.
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.
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.
On the other hand you seem to be completely against the idea on principle despite any advantages.
I can’t see any instances at all.
As for the religion point I completely fail to see how the text could lead anyone to the sort of behaviour you are implying here.
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.
Yeah. That's a lot of high tier wordpress sites. People seem to think that WP is just individual blogs, but that was 10 years ago.
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.
> 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.