[wp-hackers] WordPress Maturity (was)Re: hate

Harry Metcalfe harry at dxw.com
Tue Apr 30 16:06:20 UTC 2013


> No clue what kind of issues you have with deployments and how WordPress need to solve them. Same counts for content staging. It isn't something WordPress need to care of. Also content staging is always a pain but not a common one when you have good rules.
Primarily, it's the database munging you have to do to transfer a site 
from one host to another. It's also a little annoying that the whole 
WordPress codebase has to sit in the web root, and that uploads sit 
alongside code in wp-content. I understand why these things are the way 
they are, and it's not *that* bad. Just a bit annoying for us since 
we're doing automatic continuous deployments in an environment where we 
have to meet government security standards. For us, it would be useful 
if we could stash the whole of WP in /usr/lib or something, and it would 
be great if we didn't have to have webserver-writeable directories 
alongside code.

That said, I do understand why most of those things are like that and 
wouldn't expect them to change on our account. We are probably an edge 
case. But things like the database rewriting are just unacceptable.

> Test coverage is growing and there isn't a real good coverage number for as I know. You need to run the unit tests in different ways to do so.
This has long been a bugbear. I would like to be able to check out some 
tests and run them in our CI. I'd like those tests to fail if one of our 
projects or a plugin does something dumb that breaks one of WP's 
assumptions. I would like that test suite to be so good that plugin and 
theme authors would want to write tests for their code because it would 
be strange not to.

It's a cultural thing as much as anything else, and -- frankly -- the 
PHP/WordPress community are so far behind Ruby/Rails people and others 
that it's a bit embarrasing. WordPress is now the only reason we use PHP 
at all!

> Code quality in plugins isn't something WordPress core can fix. Also when you think that is an issue then build it yourself. That is always what I do for large scale environments. It's almost stupid to use a plugin for something that does so much more then needed.
Again, this is more of a cultural problem. But I do think there are 
things core could do to improve the situation, like providing an API for 
people to create and modify files that plugins need to be writeable, 
instead of letting plugin authors sprinkle them about in WordPress 
codebases where the entire core is writeable by the webuser. Which is 
another unacceptable thing, imo.


> About capital_P_dangit() you are right and we do a lot of feature creeping right now as the Post format UI and to less focus on bug fixing.
Glad you agree :)

> This doesn't mean you can't create a ticket and looking at your tickets you don't do it wrong at all. 1 closed, 1 fixed with props and 2 open tickets where 1 is debatable for a fix.
That's useful feedback - appreciated. But part of the reason is that I 
don't raise tickets unless I'm pretty confident that the thing is just a 
bug, and isn't some weird wontfix or policy decision. Also, sometimes 
things just seem to get ignored. Like this one:

https://core.trac.wordpress.org/ticket/18039

And then I post snippy comments that I subsequently regret :)



More information about the wp-hackers mailing list