Dennis Howlett writes:
A large part of the problem with developing for WordPress is the fact that it has been developed like a traditional PHP application. There is little separation of the presentation from the back end code, and WordPress is hopelessly tied down to MySQL at this point. Speaking of enterprise software, one of the critical problems with WordPress--why I wouldn't use it as a positive example for enterprise users--is that it simply cannot be reliably integrated into a real enterprise environment without rewriting most of its database access code to be able to handle even Oracle or SQL Server. This overall pattern has spilled over into the plugin development process, which is why most WordPress plugins behave like badly written hacks. I learned this the hard way when I wrote a plugin which heavily modified the way that WordPress password-protects entries.
Where most enterprise developers go wrong, and I mean very, very wrong, is that they love to just slap products together by joining together other applications with glue code and similar short cuts. I think this comes from the mistaken belief that writing custom code to handle a specific business need is almost always more expensive than buying a license for an existing product, as well as the belief that most big software products are interchangeable like car parts. The better approach is to start simple, with a small foundation and tailor the solution to fit the problem. If that sounds like obvious common sense, that's because you haven't worked in the enterprise development world.
That's part of the reason I encourage people to choose Movable Type over WordPress. Movable Type eats its own dog food; the platform is built on a solid, but simple framework that allows most of its components to be easily modified or even replaced.
I think however it's important to bear in mind that while Wordpress is incredibly flexible (owing some of that to the open nature of its architecture and hence the proliferation of plug-ins) it remain a single purpose application. Enterprise systems are not.I just installed WordPress 2.7 in my development environment alongside Movable Type 4.23, and was impressed with the new admin console. It seems like WordPress is finally starting to play catch up with respect to creating a good admin console for its users. However, it does still have a ways to go, and one of the things that makes me cringe everytime I hear about how great and advanced WordPress is is the fact that the admin console has been changed several times in the last few releases--about once per major point release! I'm not convinced that the thing that they've really been searching for hasn't, in fact, been an admin console that they can finally settle on.
But don't think for one minute that Wordpress is immune to issues. Theme developers tell me that many of the plug-ins are not properly tested. Wordpress itself struggles with testing. Take the example of the Lighter Menus plugin many had come to love. Wordpress didn't say explicitly but LM killed the WP2.7 dashboard sidebar. I run an automatic upgrade and as far as I can tell, there is no inline plugin compatibility testing. The problem initially left me thinking: 'WTF?' It was only by applying a bit of sideways logic that I figured the LM plugin was likely to be the problem. Once killed, everything was fine - sort of. The Zemanata server side plug-in for WP insists on staying in the top right or left position whereas I'd prefer the Save/Publish/Update panel to be in that position. These are small things but to the author's point about giving customers what they want, even Wordpress and its plugin developer community have a way to go. More to the point, there is no Silver Bullet. But I, like the About UI guys, give Wordpress a lot of credit for working hard to make users' lives a lot easier while continuing to bake in wanted functionality.
A large part of the problem with developing for WordPress is the fact that it has been developed like a traditional PHP application. There is little separation of the presentation from the back end code, and WordPress is hopelessly tied down to MySQL at this point. Speaking of enterprise software, one of the critical problems with WordPress--why I wouldn't use it as a positive example for enterprise users--is that it simply cannot be reliably integrated into a real enterprise environment without rewriting most of its database access code to be able to handle even Oracle or SQL Server. This overall pattern has spilled over into the plugin development process, which is why most WordPress plugins behave like badly written hacks. I learned this the hard way when I wrote a plugin which heavily modified the way that WordPress password-protects entries.
Where most enterprise developers go wrong, and I mean very, very wrong, is that they love to just slap products together by joining together other applications with glue code and similar short cuts. I think this comes from the mistaken belief that writing custom code to handle a specific business need is almost always more expensive than buying a license for an existing product, as well as the belief that most big software products are interchangeable like car parts. The better approach is to start simple, with a small foundation and tailor the solution to fit the problem. If that sounds like obvious common sense, that's because you haven't worked in the enterprise development world.
That's part of the reason I encourage people to choose Movable Type over WordPress. Movable Type eats its own dog food; the platform is built on a solid, but simple framework that allows most of its components to be easily modified or even replaced.
Thanks for the riff and adding to this topic.
To your point: "I think this comes from the mistaken belief that writing custom code to handle a specific business need is almost always more expensive than buying a license for an existing product, as well as the belief that most big software products are interchangeable like car parts."
The 1st part seems off. Let's not forget the ongoing maintenance required to keep all those interconnects in place. As to the 2nd part - darned right.
I can see that, however I have seen that argued in the case if an app that was to be deployed at 600+ sites around the world :) At that point, the licenses badly outweighed the estimated cost of the custom code.