It's just because they don't want to break anything in existing sites, sorta like how Microsoft doesn't generally want to break programs on Windows. So, changes are fairly incremental, and the quality is about what you'd expect from a piece of software that's decades old with no plan for what happens if it got this far.
But what do you do in that situation? If they change the structure too much, then either they make it impossible to upgrade an existing site, or potentially break a whole bunch of things said sites depend on (mostly themes and plugins). And that ease of upgrading is likely what stops a lot of people just migrating away to other solutions.
Even just introducing emulation layers for the old parts and making the new parts opt-in would be better than just giving up and keep on going. Plugin authors can choose the new subsystem as they publish updates or new plugins and themes, and in return they get speed and security guarantees.
And since the WordPress foundation controls the extension marketplace, they can reliably determine which parts of the API surface are in use, or even invest a chunk of money every month to send AI-written patches to plugin maintainers to ease the transition.
There would be so many ways to improve the situation (to the benefit of WordPress maintainers, customers, and ecosystem vendors alike, mind you!), but alas, they are stuck to their ways and will not.
> And since the WordPress foundation controls the extension marketplace, they can reliably determine which parts of the API surface are in use, or even invest a chunk of money every month to send AI-written patches to plugin maintainers to ease the transition.
I don't know if things have changed since, but my understanding remains that Matt runs WordPress.org using his own servers and money, not the foundation's:
Fair enough. The way they added Gutenberg was a complete mess. Like yeah, the idea is a good one, and the editor can be pretty good if used correctly. But the way it was built was certainly not ideal, and was probably the worst of all worlds. Felt like someone saw SquareSpace and co, thought WordPress was falling behind and decided to push for those features to be added as quickly and inefficiently as possible.
If the existing at-risk functionality is a security issue I feel like that’s a good time to throw the proverbial flag on the play and make it an issue. Letting consumers play host to malware and phishing portals is the worse move.
Is it? I did a project with WP a very long time ago and was kind of baffled. Like it's nice to have an good rich text editor, I got that part. But the absolute monstrosities people developed to extend WP, when they could have just used MySQL and PHP directly, astounded me. Like I couldn't figure out what WP was offering? It was just like a blog that you could painfully hack into something else if you wanted to. But even at that time there were already loads of great, batteries included PHP frameworks like Symfony or Cake. Why not just skip the painful part and code what you want directly?
Anyway, I probably shouldn't comment as maybe WP has progressed but it doesn't sound like it.
Honestly, the reasons could mostly be summed up as "we already used WordPress for the blog, we now need to add a shop onto the existing site, might as well extend the former rather than rebuild or maintain two systems".
Alternatively, folks that aren't particularly technical hacking together a solution that works 'well enough' for what they need, and agencies that only have the interest/capacity to use one platform deciding that each and every customer needs to use that platform.
If you're a skilled programmer WordPress is probably not a good solution for your issues, but if you're more of a designer or hobbyist that wants a somewhat hacky extendable blog system it's pretty easy to use.
I'm convinced it's by design so that the community that build little businesses around wordpress still stay in the eco system. A client needs new functionality? That's be a week of work because god help anyone who wants to look into themselves.
WordPress is actively degrading the security and quality of the web I general. Has been for many many years.
Everything I've used from Automattic has felt that way. If you ever want to torture an engineer, just make them change the layout of WooCommerce checkout.
As a junior I am glad I happened to start working with PHP on version 7. I had some peeks at our legacy PHP5 stuff (all killed now thankfully) and it looked very different. I am sure it would suck to work with.
I've done it multiple times but no one's gonna use my off the shelf blog when there's a bagilian WordPress plugins they wanna use. But with AI you kinda sorta should just build your own blog. Doctrine with slime framework. You can even throw a WordPress plugin at the LLM and ask it to implement the same thing.
I don't think PHP is a beautiful language. If it was Laravel wouldn't need to rewrite every function from standard library. And, I see no reason to use it compared to Typescript.
I never really understood these complaints about the standard library, that's not what makes a language really. Yes, it's ugly, yes, it carries 30 years of baggage, but it's PHP the language that allows you to interact with a much more convenient abstraction layer provided by Laravel.
PHP can run the same code fully dynamically typed or with very strict type annotations, depending on your requirements. It has runtime reflection APIs that are so cheap that you don't really have to think about using them. You can do OOP or FP with PHP, or even procedural HTML-interleaved-with-PHP if that's your thing. It has late static binding, so you can defer to child classes from their parent class. There are generators and fibres as first-class language constructs now. Property hooks are an extremely clear pattern, way better than in many other languages.
Generally, there have been tons of new syntax extensions over the years, and they all slot in gracefully. With PHP 8.6, we're going to get partial application for functions, which will make PHP 8.5's match expressions one of the most ergonomic implementations I have seen yet!
Ecosystem? The JS/TS ecosystem approach is to use as many libraries as possible for the sake of it, exposing you to a massive supply chain risk. PHP doesn't suffer from that because there are barely any libraries for it.
> PHP doesn't suffer from that because there are barely any libraries for it.
You don't need many libraries in a typical project, because PHP is batteries-included and if you use a framework it does all the rest for you, that is true. But there are still hundreds of thousands of packages with billions of installs:
PHP is a proof that you don't need elegant or good technical solutions to be successful. You can literally pile up slop together and still be successful.
Yeah; the common idea of dignity and self-respect is to replace the duct tape with proper engineering once you're successful though, instead of just taping ever more of it on top and pretending SQL injections aren't really a problem.
What they do is put lipstick on a pig! There is no need to "reduce" the risk of SQL injections when you can use a safe API that eliminates the entire error class. This is a solved problem for the rest of the world!
One usually uses "query builder" pattern for that.
Also, regarding placeholders, historically many DB and frameworks do not support passing lists for a value in a placeholder (like "WHERE id IN(?)") so users of such software fall back to string concatenation.
Not user code, no. Someone eventually has to, but virtually every ORM under the sun allows you to construct dynamic queries without having to concatenate strings yourself or resort to string interpolation.
$results = $wpdb->get_results( "SELECT * FROM {$wpdb->prefix}options WHERE option_id = 1", OBJECT );
> Some of the methods in this class take an SQL statement as input. All untrusted values in an SQL statement must be escaped to prevent SQL injection attacks. Some methods will escape SQL for you; others will not. Check the documentation to be sure before you use any method in this class. For more on SQL escaping in WordPress, see the section entitled Protect Queries Against SQL Injection Attacks below.
It does not however prevent $wpdb users from NOT binding query parameters, which leads to this vulnerability.
It seems that wpdb doesn't support placeholders for comma-separated lists, like in "WHERE id IN (?)". So the developers have to fall back to string concatenation.
A few months back, Cloudflare used AI to make a Rust rewrite of WordPress, but I doubt that they would have found or corrected issues like this on the way?
https://blog.cloudflare.com/emdash-wordpress/
>Rather than executing an SQL query directly, we’ll use the dbDelta function
>Note that the dbDelta function is rather picky, however. For instance:
>You must put each field on its own line in your SQL statement.
>You must have two spaces between the words PRIMARY KEY and the definition of your primary key.
>You must use the key word KEY rather than its synonym INDEX and you must include at least one KEY.
>KEY must be followed by a SINGLE SPACE then the key name then a space then open parenthesis with the field name then a closed parenthesis.
>You must not use any apostrophes or backticks around field names.
>Field types must be all lowercase.
>SQL keywords, like CREATE TABLE and UPDATE, must be uppercase.
>You must specify the length of all fields that accept a length parameter. int(11), for example.