Why in heavens name would you want to change wordpress like this? If it doesn't live up to your standards, just use Ruby+Rails or Python+Django. (Or even PHP+some framework)
Wordpress does publishing right. The admin is easy and intuitive for writers, photographers, editors and the news production. Ruby on Rails and Django have admins best saved for programmers.
I suspect the time and effort to create a user-friendly admin and publishing system for either framework was higher than just using Wordpress, which already just works and people are familiar with. This makes sense.
But, Wordpress can be a pain for programming teams with front end and back end developers. The code is often embedded, which means both a designer and programmer often have to touch the same file at the same time. The MVC model fixes this problem allowing teams to work simultaneously with designers designing and coders coding, while also simultaneously making the coding easier by creating a model built around standard framework structure.
Wordpress wins for writers. MVC wins for programmers and designers. MTV wins for both.
Noble and geeky effort, but I'm skeptical whether I'll use it (disclaimer: I did try smarty implementations before and had similar experiences.)
Think the dissenters' consensus is that this goes against grain of what's been organic WP development (not that it's all perfect, but, there is a massive contributing base.) This thing might become obsolete nightly or I could be entirely wrong and it'll get adapted whenever WP guys wrangle major internal design changes at some point.
I'll skip over all that and just address specifics that make me feel uneasy.
As they stated in their writeup, one problem is that function exports have to be hard-coded. Not to say they won't fix this (switch it to smarty3-like model or control what gets installed), but that means they've interfered with the admin process of installing plugins that need minor template alterations or otherwise meet unspecified limits; ex: wp-paginate. That means that the core MTV team is still involved with the end user, and the template designer.
Secondly, sure, WP templating hasn't changed all that much lately - but historically it has changed drastically between major releases. This MTV implementation forces Trib. guys to spend time keeping up with updates and changes that will come out of nowhere. I'm not sure if MTV breaks WP's template hierarchy, or its template inheritance features, but those I rely heavily on.
We're concerned about the upgrade path, but so far we've upgraded from 3.1 to current without any issues.
MTV can break a lot of plugins that filter front-end output. But it depends on how you use it. It doesn't have to.
We like having function exports be hard-coded. Making all functions available to the templating engine is unnecessary. It's pretty trivial to declare new functions to use in the templates, and it doesn't have to be done in the MTV plugin, you can declare those in your theme or plugin.
We are always involved with our end users and we design the templates. Our users can't install plugins or themes and we typically lock down lots of settings. So we don't mind if we break template tags because we have complete control over how our sites are used.
MTV has it's own template structure and supports all sorts of template inheritance. That all comes from Twig. It also supports child theme inheritance, if you're using MTV to build your themes all of your themes.
We've tried to get around the future-update-breaking-shit issue by making the core of MTV sit on top of WordPress. It's totally possible to build an app with MTV and no WordPress.
Again - MTV works for us, but won't work for everyone. And it's really only useful if you're gonna build a site from scratch.
Gotta say that I don't get it either. They've basically just added yet-another-HTML-templating system into the mix. Question not answered: "For the love of all that is holy, why?"
PHP is an HTML templating system. Tacking on yet another one strikes me as more than a little pointless.
By that reasoning, we should just code a whole site in a single PHP page that handles both the backend processing and the display layer and generation of HTML.
It's not about decreasing the number of files (to look into to find bugs), it's about organizing the code into logical pieces that are more manageable.
