

Turning Wordpress Into a Framework With MTV - jashkenas
http://blog.apps.chicagotribune.com/2011/10/19/turning-wordpress-into-a-framework-with-mtv/

======
stdbrouw
I think this fits some use-cases very nicely, where there's not enough
incentive to use a proper framework like Django, also not enough incentive to
mix a framework and WordPress in a CMS+app setup (e.g.
[http://multimedia.journalism.berkeley.edu/blog/2010/nov/24/a...](http://multimedia.journalism.berkeley.edu/blog/2010/nov/24/argo-
network/)), but on the other hand where doing everything as plain WP plugins
would be a grueling experience. Yes, I can see myself actually enjoying this.

Of course, it'd be better if WordPress, the kick-ass blogging platform that it
is, would just _be_ a framework or be built on one, so the Tribune wouldn't
have had to do this, but when stuff like WordPress and Drupal got started, (1)
nobody had ever heard of MVC in PHP and (2) the OO was crap. So it's hard to
blame Matt.

------
brianboyer
I'm sort of shocked at the negative reaction this project has elicited. When I
first saw this work, I was thrilled.

When I popped the hood on my first big WordPress project a couple years ago, I
was appalled with what I found. Modern web frameworks have converged on a MTV-
or MVC-style development style. Writing code in WordPress is like travelling a
decade back in time.

This project is a very thoughtful effort to keep all the best of WordPress,
while replacing the backwards template system.

I suspect that the ire this has drawn is the result of developers in the
WordPress community not crossing over to other languages/frameworks. Anyone
who's made a website in Rails or Django would feel right at home in WordPress
MTV.

~~~
Otto42
I'm sort of shocked that you're shocked. The rigid and inflexible architecture
of systems like Rails and Django are the primary reasons for WP's success.
There's a reason WP has more themes and plugins than these other systems, and
that reason is ease-of-programming.

Every time I see some programmers advocating the use of highly rigid
architectures or programming models, I'm forced to remind myself of Lisp. Lisp
is _the_ programming language. Lisp created most of the fundamental constructs
you see in modern programming languages today. It's quite possible to do damn
near anything in it, and it's arguably as close to the perfect mathematical
construct of a computer language that can be made. It's a bit rigid and weird
in it's syntax, but the list model is just great once you wrap your head
around it.

On the other hand, the language that is clearly the most successful one ever
is C, and it has often been argued to be the worst language ever. It has
arcane syntax, it requires detailed knowledge of memory pointers and other
oddities, and it's very much a lower level language. And yet it is clearly the
most successful language ever. Why? Not because of its model or architecture
(which are frankly terrible), but because of its flexibility. Programmers both
inexperienced and experienced can use it to produce powerful systems. It
covers the whole gamut of skill levels.

That's the problem with rigid architectures. Programmers tend to flock to them
as they become better at their craft, because they provide organization and a
system of management of the large scale code they're creating. But
inexperienced programmers find the learning curve just a bit too steep.

You can't go from "Hello World" to creating a new WP theme in an MVC style.
But you can go from basic HTML and PHP knowledge to creating a theme
modification or a plugin. It may not be the technically best solution, but by
god it'll get the job done for now. Speed of delivery _matters_ , and if the
choice is between doing-it-right and doing-it-right-now when you have a
deadline and need to get paid, guess which path is going to get chosen?

Code has a limited life expectancy. It doesn't survive long in the wild, and
this time is more and more frequently measured in years, not decades. So it
doesn't make a lot of sense, in the long run, to spend extra time to build
around a large framework when, damnit, we've got work to do. Every moment you
spend learning yet-another-framework is a moment you didn't spend creating the
next product and earning the next dollar.

Systems that are fast to learn and flexible enough to get the job done quickly
_always_ win over systems that are rigid and hard-to-learn.

~~~
stdbrouw
WP is more successful than Rails and Django because WP is a blogging system
and more people need a blog than they do a development framework. Secondly,
it's successful because it's in PHP. But successful because it's "not like
Rails", are you kidding me?

Also, check the damn tutorial. A line for url routing, a couple of lines to
fetch some data from the DB and then a couple of lines to render a template.
There's nothing scary about it. The reason people find it so easy to make and
mod WordPress themes is because they can start from existing code. If they'd
have to make one from scratch without the ability to copy-paste or look at
existing themes, 90% of 'em wouldn't even know where to get started, no matter
how good everything would be documented. There's no reason why this same
learn-by-copy-pasting routine couldn't work on top of an MVC approach.
Beginning programmers _do_ learn Rails and Django, y'know. Hundreds every day.

------
pp19dd
To widen this templating-aspect perspective to yet another extreme, here's
more fuel for the fire.

[http://www.webresourcesdepot.com/19-promising-php-
template-e...](http://www.webresourcesdepot.com/19-promising-php-template-
engines/)

List of nineteen promising PHP template engines. Nineteen. And this isn't even
tip of the iceberg. The templating diaspora can partly explain how MTV was
received.

------
OkkeFF
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)

~~~
yurivictor
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.

~~~
pp19dd
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.

~~~
rmrk
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.

