Let’s make WordPress officially support SQLite(make.wordpress.org)
make.wordpress.org
Let’s make WordPress officially support SQLite
https://make.wordpress.org/core/2022/09/12/lets-make-wordpress-officially-support-sqlite/
121 comments
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.
Likewise, security checks.
Likewise, security checks.
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.
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?
[deleted]
Yeah. You can be sure that 60,000+ plugin authors and 50% of the web that use WordPress and those plugins will just allow that.
Fuck 'em.
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 doesn't need 60,000+ badly-written buggy insecure WordPress plugins.
Adapt or die, and in WordPress's case, preferably the latter.
> 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.
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.
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.
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.
> I’d also like to see them switch to git for the plugin repos.
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.
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.
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.
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.
Note that Wordpress don't use Github, or Git for that matter.
https://core.trac.wordpress.org/browser/trunk
https://core.trac.wordpress.org/browser/trunk
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.
Or you could do nothing and let Wordpress rot until nobody uses it anymore.
Problem solved, nothing to do for 60,000+ plugin developers.
Problem solved, nothing to do for 60,000+ plugin developers.
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...
[1]: https://www.sqlite.org/mostdeployed.html
[1]: https://www.sqlite.org/mostdeployed.html
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.
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.
TFA does mention some points that address your "why"; the ones that most speak to me the most are:
> 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.
> 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.
> 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.
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.
[deleted]
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.
*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:
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.
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 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
Those plugins that don't work with SQLite will be replaced with plugins that do.
Should the creation of prepared statement be shifted down from that code to adaptation layer between it and each database's library ?
seeing this code, I’m happy that I no longer do PHP
"Happy you no longer do Wordpress"
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.
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.
The culprit is not PHP, the culprit is WordPress being developed with antiquated software engineering practises (or rather, lack of any good practice).
Just take a look at their coding guidelines: https://developer.wordpress.org/coding-standards/wordpress-c... they're laughably bad and nonsensical.
Just take a look at their coding guidelines: https://developer.wordpress.org/coding-standards/wordpress-c... they're laughably bad and nonsensical.
Could you explain why they're bad?
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.
[1] https://developer.wordpress.org/plugins/hooks/filters/#add-f...
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...
>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.
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.
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.
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.
> why would you expect us to be talking about anything else than the technical aspects?
Because the 'non-technical' aspects are what determine this entire discussion.
Because the 'non-technical' aspects are what determine this entire discussion.
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 keep waiting for WP to die and it never does.
I keep waiting for WP to die and it never does.
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.
It's all awful code, of course.
It's all awful code, of course.
I would love to know your take on why the coding guidelines are laughable?
> 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...
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)
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.
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!
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!
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
https://github.com/iolevel/wpdotnet-sdk
https://docs.peachpie.io/scenarios/blazor/debugging/
https://github.com/iolevel/wpdotnet-sdk
https://docs.peachpie.io/scenarios/blazor/debugging/
I have been trying to figure out how this works,
by looking around the repo.
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?
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?
Yes, PeachPie is a PHP -> .NET compiler/runtime.
What about xDebug?
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
- 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.
Time series would be more beneficial for a significant user base of WordPress which is using WP as a de facto company record described as a CMS-CRM.
And completely useless for the most significant user base of WordPress which is using WP for their small marketing website or blog.
Why would a time series database be better for a CMS-CRM? Or am I completely miss reading your comment?
I'd go even further and replace the database with a folder full of JSON files. (Or other similar structured text files.)
Why? Then I could store my WordPress folder in git and realistically merge changes between copies of my website.
Why? Then I could store my WordPress folder in git and realistically merge changes between copies of my website.
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.
Abstract it or don't do it.
Abstract it or don't do it.
I'd rather have PostgreSQL.
well, there is a plugin for that, even if native support would be great
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.
I was surprised that WordPress didn't support SQLite when I used it recently since a long time.
Makes sense that it does.
Would love to see an abstraction layer in WP. It’s always boggled my mind why Postgres or any SQL db can’t be used instead.
Awesome! I hope Mediawiki will follow suit!
I think Wordpress should do one thing well. There are plenty of small CMS platforms that support SQlite like Bolt.
It doesn’t do anything that well, so this could be the chance!
If it didn't do anything well, 60% of CMS wouldn't run Wordpress.
It doesn't do what happens in your world well.
It doesn't do what happens in your world well.
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.
It would be great to use sqlite during development and then MariaDB in production.
It's not hard to clone MariaDB, but sqlite is much more practical.
It's not hard to clone MariaDB, but sqlite is much more practical.
For most sites you do not need to switch away from sqlite for production. It is fast enough.
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.
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.
There are other considerations besides speed for production - like redundancy.
edent(9)
I've been saying this for a decade!
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.
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.
I can’t see anyone forcing SQLite into WP just an informed discussion of the pros and cons.
On the other hand you seem to be completely against the idea on principle despite any advantages.
On the other hand you seem to be completely against the idea on principle despite any advantages.
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.
Care to cite where anyone from ‘that community’ are forcing themselves into WP?
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.
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.
Just keep reading the comments in the discussion threads under this HN post. You'll soon see enough.
I have and I see nothing of the sort.
But I did. Maybe youre too biased.
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.
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.
> So, sure, if your site is so busy that multiple authors are posting within milliseconds of each other
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.
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.
You mean that there are normal WP sites where editors are saving content more than 1000 times per second?
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.
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.
You have misunderstood the "con" entirely and the author has (possibly?) missed sqlite PRAGMAS which would make it behave entirely equal to mysql.
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.
> 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...