[Kluny]

I worked at WordPress for half a year, and I'm no expert, but the code reviews there were more intense than any I've ever experienced. Every line of code gets reviewed before it gets committed, and if the commit is longer than 20 lines or so, it undergoes an additional scheduled review as well as pre-commit review. They also have pretty good code sniffers that ought to catch errors like OP mentioned.

The reason they're concerned, I think, is because they try to protect users who have plugins that came from their plugin repository, where the same code quality rules don't apply. WordPress has always been huge on backward compatibility.

[muglug]

> WordPress has always been huge on backward compatibility.

Yes, and I think that's ultimately the root of its challenges.

A fear of breaking things means WP shies away from large-scale changes that would help it become a modern-looking PHP app.

I wrote this two years ago, and WordPress's basic architecture hasn't changed since: https://medium.com/@muglug/improving-wordpress-with-static-a...

[marc_io]

> A fear of breaking things means WP shies away from large-scale changes that would help it become a modern-looking PHP app.

They are strongly advocating Javascript as the future of WordPress right now, so I'm not sure if they would like it to become a modern looking PHP application.

[noahtallen]

I'm working on some of these "future of WordPress" projects right now, and I don't think PHP is going away any time soon. The JS-future for WordPress is more to do with the editing experience than anything else -- the entire rendering pipeline, backend, and rest API is still PHP, and I'm not aware of any plans to change that.

The main difference with the future of WordPress is that instead of templates (which describe the structure of a site) being written in PHP, they will be written as blocks so that they are user-editable. I would say it's more apt to say that "blocks" are the future of WordPress. The block editing experience is written in JS, but serialized block markup is backwards compatible with HTML, so no JS is needed to render blocks once they are serialized.

[eitland]

Interestingly the one other mainstream language that manages to mess up

- equality

- type coercion

- array handling

and more to the same degree as PHP :-)

[mgkimsal]

> The reason they're concerned, I think, is because they try to protect users who have plugins that came from their plugin repository, where the same code quality rules don't apply.

Then start making the quality rules apply. Or produce code quality ratings for plugins and display them for people to make decisions on.

Making sure that WP can keep working with lower-quality plugins in the name of 'compatibility' just ensures that WP is, at best, a mixed-bag.

[Kluny]

It's a tradeoff they've made. Allowing the plugin store to be a free-for-all creates a very low barrier for entry, and the marketplace is thriving and well populated as a result. They've added metrics you can use to assess quality, in the form of compatibility reporting, user reviews, stars, etc.