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