undefined | Better HN

0 pointschiefalchemist7y ago0 comments

> "(ease of deployment, ease of extension, ease of configuration, auto-updates, plugins, etc.)"

But those are The Right __and__ The Wrong.

For example, adding Composer to the WP "stack" makes sense. But now you've eliminated 90% (?) of the WP "developers."

That is, in the Universe of WordPress Composer is more friction, not less (i.e., ease of use).

Long to short, for better or worse, WP is Justin Bieber. It will never be Radiohead.

0 comments

krapp7y ago

>But now you've eliminated 90% (?) of the WP "developers."

Maybe, but it wouldn't be impossible to rebuild plugins around Composer and PSR standards. And doing so would make them better organized, and make it easier to manage third party dependencies. If you were going to build Wordpress from scratch, today, that's probably what you would do - just make plugins a special case of Composer dependencies.

The only question is, whether you would still have as robust an ecosystem with a more restrictive framework? Probably not, but the quality of plugins would probably be higher.

chiefalchemistOP7y ago

I think before we worry about plugins and themes it would make much more sense to bring WP core itself up to date. What good is a nice, clean, properly organized plugin, if it's sitting on a foundation of sand.

I filed a core bug report once. Long to short, if I passed (I think it was) false to a core function, I got very unexpected results. The dev that replied to me said, "Well then don't do that." Huh?

The idea that the function should check, that it should be aware that humans (and their code) make unexpected mistakes, was completely foreign to her / him. I lost a lot of faith that day. I lose a bit more every time I go poking around in core code. I'm no Super DevMan. So when __I__ see bad patterns you know something is wrong.

p.s. Fwiw, even the lead dog (i.e., Automattic) has some nasty code habits. Simply dumbfounding.

j / k navigate · click thread line to collapse