Comment by progbits

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.

they broke tons of stuff with Gutenberg/block editor and didn't seem to be bothered by backwards compat

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.

This isn’t some problem that has developed over time. It was shit from day one.

Vogon Poetry [1]?

[1] https://hitchhikers.fandom.com/wiki/Vogon_poetry

If code is poetry, WordPress was written by William McGonagall <https://en.wikipedia.org/wiki/William_McGonagall>.

They could just go a bit more honest and migrate to "Code is pasta". WP is also closer to a pizza slice than Michelin star fine dining experience.

They never said it was good poetry

Ask an old English teacher whether "poetry" implies anything favorable about quality.

php7 was such a great time period for PHP, honestly lots of great experimental projects around that time too (HHVM before that, etc).

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.

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.

I think PHP came right at the time that every man and his dog was a "web developer" and writing absolute unknowledgable stuff. And PHP allowed for it.

ASP had a bit of a barrier to entry because it required all the MS. Whereas PHP was everywhere.

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.

Let me convince you! :-)

There are match expressions and arrow functions:

  $slug = $title
      |> trim(...)
      |> (fn($str) => str_replace(' ', '-', $str))
      |> (fn($str) => str_replace('.', '', $str))
      |> strtolower(...);

There is meta-programming with annotations:

  final class PostsController
  {
      #[AccessControl(fn(Request $request, Post $post)
          => $request->user === $post->getAuthor()
      )]
      public function update(Request $request, Post $post): Response {
          // ...
      }
  }

Native (and optionally value-backed) enums:

  enum Status
  {
      case Draft;
      case Published;
      case Archived;
  }

Proper class property hooks, fully replacing getters and setters:

  class Data
  {
      public string $fullName {
          get => "{$this->firstName} {$this->lastName}";
          set(string $value) {
              [$first, $last] = explode(' ', $value);
              $this->firstName = $first;
              $this->lastName = $last;
          }
      }
  }

And tons of other features—among them asymmetric property visibility, fibres/green threads, DNF types, lazy object instantiation, an ever-improving yet fully opt-in static type system with runtime validation, a JIT compiler, an amazing package ecosystem and -manager, annotation-backed deprecation, and more.

> Nope.

Beauty is in the eye of the beholder, and I'll disagree kindly with you on that "Nope".

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.

That could as well just be a complete new product then, right?

It would definitely be a breaking change and unmigratable.

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/

Mullenweg will never allow WP to slip away from his control. "He wrote it" so you can't have it.

Who is they? automaticc?

Impossible. WordPress has had the PHP-group even considering writing new PHP features in a separate 7.4 branche and release them specifically for WP.