I've been working with WordPress for about 5 years now. After 3.0 was launched the amount of WordPress development I've done has quadrupled. Before Springbox I had always worked in single installation sites. Low budget development work to create a basic blog for a person or a business. The content was never complex and they typically had a few dozen pages. Springbox had larger requirements from the platform because the sites were much more complex with a couple orders of magnitude more content. At first I didn't think the WordPress could sustain such installations. But by comparison to other CMS frameworks available on the market, it was still a clear winner. And for situations where the core codebase couldn't handle what I needed I could always rely on plugin hooks or even directly patching the core codebase if necessary.
It wasn't until Springbox that I discovered how woefully broken the patform really is. As a practitioner of continuous integration and agile based development and qa cycles, my first roadblock was being able to work with and modify the same database from different servers. WordPress has a major bug in their system that stemmed from their B2 days whereby they embed the entire absolute URL of the site into every facet of the database. The Core development team today calls it a "design decision" and refuses to change it. They provide a bunch of meaningless criticisms to the root relative url approach that is used in 98 of the top 100 Alexa websites. One developer went as far to say that without the domain name in the url, your content loses portability to books. I tried to explain that you can easily prepend any domain host to a root relative url on export, but he didn't really understand or see the problem, so a solution seemed meaningless.
So like any good hacker I refactored the WP core in about two days to support root relative urls. I wrote a plugin and asked the core dev team to take a gander and let me know what options there were to integrating this into the core logic. I was met with a bunch of absolute url zealots, and they refused to even consider the notion. Even more hilarious was the excuses they gave as to why they wouldn't implement the feature, even as one that could be toggled on and off, would have actually been solved and improved with my plugin. Yet they continue to battle HTTP/HTTPS issues, inability to access the admin portal of a locally developed site on mobile devices, a crazy insane migration process that involves doing search and replace transformations on raw database exports, and hundreds if not thousands of lines of needless code that hurts system performance and still has bugs to this day.
And I'm not the only developer who has asked for this feature or thought that it was crazy that this wasn't a feature of WordPress to begin with. Though I think I am the first developer to offer a legitimate solution that requires no extra work on the part of the user. Others before me (going back to as far as 2004) had offered solutions like putting special text codes in front of the url, or auto search and replacing the content on data exports, or only fixing such a small part of the equation that even I would have rejected the patch out of principle if I were a core dev. So now there are two major problems with WordPress, not only do they use absolute urls, but they also don't listen to their community very well. Their support forums are full of complaints related to this and they simply say what you are doing is not necessary and we refuse to reconsider.
Then I discovered the Visual Tab vs HTML tab debacle that has existed since day one of wpautop. My prior sites had zero complex markup. My Springbox sites where html5 productions with complex html structures. When I discovered how mangled the html markup became when switching tabs I was horrified. I was dumbfounded when I discovered that the recommended practice by the core development team was to disable the html tab when handing off a project to the user. Have they never heard of ongoing support and development contracts? Even crazier is that they all blamed TinyMCE for the problems that thousands of users experience on a daily basis. And there are two versions of wpautop, a php version and a javascript one. A couple core devs didn't even know about the client side one - they believed that if you disabled the php version everything worked just fine. This litle discovered resulted in a three week delay in our project delivery and a horrible customer hand-off experience. I had never felt so unprofessional telling the copy editor how to deal with the html markup being corrupted on certain pages if they used the HTML tab, so don't click on that tab.
I tried to get that situation fixed, and tried to add support for HTML5 and tried to minimize the logic incompatibilities between the php and javascript versions of wpautop - yeah did I mention that they process the content in different and incompatible ways? Yet the response from the core team was, the problem is with TinyMCE not Wordpress, HTML5 isn't supported yet, and the javascript version of wpautop is intentionally different because it does different things. I might have pissed some of them off with the Root Relative URL discussion so I understand getting some pushback, but it wasn't just me, there are dozens of other developers who have tried this route before, and they all told me good luck when I said I was going to give it another try. In the end the only patch that was accepted was one that fixed one of the 50 different http/https logic bugs and it took them 10 months to integrate 30 lines of code.
So not only have I learned that a few devs on the WP core team are naive, that others on the team dislike change or being questioned, that at least one dev doesn't understand basic premises on how URLs have worked on the internet since 1992, that at least two of the devs don't even understand much of the core code, but I've also learned that there's no use trying to change it. So I gave up my intentions of correcting the core issues. I now will only write plugins that I need to get my job done. And that's a shame because it's not how you maintain a good developer community. And if you don't ever strive for something more than just a blogging platform, your project will never be considered as an option amongst enterprise businesses. And sadly WordPress is not far from being the best CMS available on the market for enterprise websites.
I'll be sure to fill in the details of all of my assertions above. I have chat logs and forum posts and emails that are really amusing reads that I'll eventually post here as well. I have a love hate relationship with WordPress now, and I'm not the only one. I still recommend it for new clients because the administrative features are first class (if implemented well) and the plugins I've written to date fix 95% of the blocking issues. So if you see me make snarky remarks in my code or on my site, this is pretty much why. Dealing with the WP Core team is like dealing with the department of transportation.
To be fair, there are a couple core devs who sympathize with me. One in particular wishes he had changed the absolute url problem back in the old days when there weren't 15 million users to consider. So it's not the entire lot that is clueless or obstinate.