Turning Wordpress Into a Framework With MTV(blog.apps.chicagotribune.com)
blog.apps.chicagotribune.com
Turning Wordpress Into a Framework With MTV
http://blog.apps.chicagotribune.com/2011/10/19/turning-wordpress-into-a-framework-with-mtv/
4 comments
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.
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.
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.
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.
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.
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.
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...
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.
http://www.webresourcesdepot.com/19-promising-php-template-e...
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.
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.
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.
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.
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.
Can't agree more, although I haven't personally tested the MTV plugin its looking super promising for large WordPress sites.
However in the long run it might make more sense putting time into building a revamped admin for Django instead — using WP as the model.
However in the long run it might make more sense putting time into building a revamped admin for Django instead — using WP as the model.
Because WordPress is great, but it's a pain to do extensive development with.
Replicating WordPress functionality in Rails or Django would be an enormous job. Making WordPress more like Django was much less work.
Replicating WordPress functionality in Rails or Django would be an enormous job. Making WordPress more like Django was much less work.
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.
PHP is an HTML templating system. Tacking on yet another one strikes me as more than a little pointless.
"All the HTML is in one place and contains as little code as possible.
One place for code that interacts with data.
One place for code that processes requests and responses.
One place for all the URL regexes.
And all these places are predictable."
One place for code that interacts with data.
One place for code that processes requests and responses.
One place for all the URL regexes.
And all these places are predictable."
So, when you have a problem with the system, then to find the bug you have to look in three or four places instead of one.
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.
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.
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.