To be a viable web app development model Wordpress really needs to follow down the ExpressionEngine -> CodeIgniter route. Slowly evolving into a set of modular

To be a viable web app development model Wordpress really needs to follow down the ExpressionEngine -> CodeIgniter route. Slowly evolving into a set of modular components that work together. (Or how bulky symfony evolved into lightweight symfony2 + components) Wordpress is still very much stuck in the old-school PHP world: download one big codebase, add some Wordpress specific packages (themes and plugins). That's a far away from where modern PHP is: smaller components brought together with composer and packagist. Which leads to more nimble frameworks for putting together web apps, picking and choosing the right set of components. Don't like Doctrine, use Propel, or RedBean, or Eloquent. It's okay if your app fits into Wordpress' constraints of the world. My concerns over the current state of Wordpress as a web-app framework: * Plugins are special snowflakes, and so raises a gnarly set of conflicts and issues. * Themes that do a lot more than theming - like WPGeo, which is an entire location-based functionality. It's like there's a packaging construct that involves themes + set of plugins that's missing. So themes become a dumping ground for any code. * Dependence on global variables (like $wpdb) * The datastore being SQL is leaked through the codebase. * The visual layer drives the processing - so themes take control. * Plugins are wordpress plugins, not well-built PHP packages. * The extension mechanism (pseudo-event-binding through global functions) makes any code "Wordpress code", it's a lock-in. * The custom data storage is a joke and inconsistent. serialised php being stored in mysql field, or serialised JSON. Wordpress is missing a mechanism to encourage structured data. I care about the quality of my data, my app needs to care too. * Unit tests. Wordpress' architecture makes decent unit test coverage difficult. * The quality of third-party plugin development isn't great. Understandable considering the typical Wordpress audience. If the plugin works, great. If there's a conflict, that can open up a pile of hurt. * Essentially it's a code-coupling problem. It's difficult to disentangle. So you're mostly writing Wordpress specific code, not componentised PHP modules. I like the admin interface, I wish that was a separate component that could be forked, and used as the basis for a web app. I can't see how Wordpress can deal with these issues in a backwards compatible way. Yes, they can create a modular and componentised core that can be packaged up for use outside of Wordpress, but at some point there's going to have to be a shedload of Adaptors to translate that clean crafted and organised code into a bunch of global variables and global functions that themes and plugins rely on. I can see good bits of Wordpress (like the admin ui) being forked off into separate projects and worked on in isolation to the point they catch up with modern PHP development. But these won't be backwards compatible with Wordpress without a grungy wordpress layer over the top. Perhaps the damning thing is the lack of a consistent and appropriate data model, backed with a properly structured database. Sure, I can define my own relational database, do by hand what a content management system should already be doing for me - at that point where's the benefit? What if I want to be using a noSQL store instead? It's hard to justify starting with Wordpress, when there are so many much better frameworks available for PHP that are more suited to packages and componentised code. First step, up-to-date autoloader and namespaces.