Earlier quoted context omitted.
Certainly. One mistake was that PHP was chosen, when it really was unfit for the task at hand. Another one was that CMSes like WP or Drupal were shoehorned into projects that were really unfit for them. etc. But also being unable to upgrade underlying PHP versions due to breaking changes, or just p*ss-poor, bug-ridden PEAR packages. As well as the language design prohibiting proper TDD, isolation, etc. I explicitly s…
I would imagine that your team picking WP or Drupal and attempting to shoehorn in your use case had more to do with your projects failing than PHP itself. I see that happen a lot in the wild, and not just with PHP. I bet you could have picked a python/node/c#/go CMS with a similar outcome.
Just like Rails is part of the Ruby ecosystem. Technically, it is wrong to blame Ruby for poor design decisions made in Rails. Like Rails monkeypatching stdlib classes. But Rails can monkeypatch stdlib classes because Ruby lets it. It did a lot of monkeypatching stdlib classes, because it was common thing to do in the Ruby ecosystem back then. So, I therefore, place just as much blame on those poor decisions in Rails as I place them on the language, Ruby. Whats more: I blame both for promoting this idea in the first place. A new dev may open the Rails code and conclude "if a popular framework is doing X, X is probably a good way to solve my issue".
The latter is, and always has been, my largest gripe with PHP. No, WP is not a good example to learn proper PHP development, but it is the thing most new PHP devs encounter PHP and are then stuck with horrible "best practices" for the rest of their carreer.