Is WordPress MVC compliant? [closed]

Wordpress itself is not architected in MVC, but one can build very MVC oriented themes and plugins within the framework. There are several tools which can help:

WordPress MVC solutions:

• Churro: @ wordpress.org/extend/plugins/churro
• Tina-MVC: @ wordpress.org/extend/plugins/tina-mvc
• Plugin Factory: @ wordpress.org/extend/plugins/plugin-factory
• MVCPress: http://mozey.wordpress.com/2007/01/22/mvcpress-screenshots/#comment-3634 (abandoned, but interesting ideas)

MVC threads on WordPress.org Ideas and Trac:

• http://wordpress.org/extend/ideas/topic/mvc-plugin-framework
• http://wordpress.org/extend/ideas/topic/complete-reestructuring
• http://wordpress.org/extend/ideas/topic/rewrite-wordpress-using-mvc
• http://wordpress.org/extend/ideas/topic/wordpress-theme-revamp (more on XSL than MVC)
• http://core.trac.wordpress.org/ticket/12354 (on MVC in widgets)

Wordpress is kinda-sorta MVC. If anything it is a pull-type MVC layout, where the View 'pulls' data from the model. It does this in a very proceedural way, instead of using lots of different objects, but this actually makes the front end templates easier to write in a lot of ways.

This also gives the views some degree of controller logic (thus the kinda-sorta MVC).

Lets run this down: Wordpress gets a URL. The wordpress core acts as a controller and determines what initial queries to run of the database, and by extension, what view should be loaded (category view, single post or page view, etc). It then packages that INTIAL query response and sends it to the view file.

That view file CAN be a strict display only file OR it can request additional information/queries beyond the built in one. This is the pull-type of the MVC, where the view pulls data from the model instead of the controller 'pushing' data from the model into the view.

Thus, when the view sees code to load a sidebar or widget area, it asks for that information. However, what widgets should be there is determined by the controller, which looks at the model for what widgets are in the sidebar, and then selects those that are set to show on the current page, and returns those to the view.

That each part of that isn't an object doesn't make this any less MVC. You can alter WP core without (necessarily) altering anything about a theme. Similarly, as long as you use built in functions like 'get_pages()' then the model and the database tables could change as long as those functions still returned the right data. So, the model is independent of the view, and the controller is independent as well (except when the view adds controller logic to do more than the core normally does).

While you COULD have a model object holding a number of methods and stuff like WPModel::get_pages('blah blah'), and contain everything that way, there is still fundamental separation of concerns.

View: template files Controller: WP core Model: the various functions that handle specific data handling.

As long as the names, arguments, etc, stay the same (or just have new ones added) then separation of concerns is maintained and one can be altered without disturbing the others.

It isn't a super-clean version of MVC, (especially when hooks get involved), but at a basic level it starts there.

And being proceedural about it isn't a bad thing IMO. A request from a website is pretty inherently proceedural: it is a process with a clear beginning and end, and just needs a procedure to process the request, get data, package it, then die. You can set up those steps with objects and object methods and OOP layouts (which would make some things easier) or you can just write alot of function calls and separate them out that way. Class members like private variables are lost that way but depending on the needs of the application... you might not care.

There is no one-grand-way to do development, and WP sits at like 20% of websites so it is doing something right. Probably something to do with not making people have to learn/memorize complex class hierarchies to get the database to answer the question 'what pages are child of page x?' and deal with that data. Could you make it that easy with OOP? yes, but if Joomla is any example of how hard it is to implement a complex custom website with OOP, then WP is FAR easier and quicker, and time is money.

As already mentioned in the comments, MVC is an architectural design pattern, not a specific framework, and no, Wordpress doesn't follow the MVC pattern.

There is a separation of views (templates) from the programming logic, but only in the frontend, not in the admin panel and a general separation of views and application logic is not inevitably MVC. An implementation of the MVC pattern usually assumes some kind of object oriented programming paradigm behind it and Wordpress is mainly implemented in a procedural way, with plain SQL queries in the PHP functions, therefore not having an actual model either.

Just to update this with more recent information for people hitting this from search engines - the wp-mvc plugin http://wordpress.org/extend/plugins/wp-mvc/ goes a long way to creating a mvc framework for plugin development. You can find out more here: http://wpmvc.org/documentation/70/tutorial/

One of the topics that periodically crops up in discussions as it relates to WordPress is the idea of WordPress and MVC.

But the thing is that MVC is not the silver bullet of web development that we try to make it out to be. Yes, it’s an awesome design pattern, and I personally think that it fits the web application model like a glove, but not every framework or platform implements that design pattern.

Case in point: WordPress is not MVC.

And that’s okay. I think we need to leave the desire of trying to shoehorn it into our projects aside especially when the pattern WordPress provides is not only sufficient, but works well when leveraged correctly.

“But I Love MVC!”

So do I! In fact, I spent the last year working on a project that more-or-less mimicked the MVC architecture. A high-level example of MVC.

A high-level example of MVC.

For example:

Views were implemented using templates
Controllers were implemented by a combination of using function names like create, read, update, destroy, delete, and so on (even though these functions were hooked into the WordPress API
Models were functions also were called to validate and verify data prior to serializing the data. Again, this required that certain functions be hooked into WordPress to achieve the desired result.

Finally, a set of rewrite rules gave the application a clean set of predictable URLs in the format of /people/update/1 or /people/all. What Pattern Does WordPress Implement?

WordPress implements the event-driven architecture (of which there are several variations such as the Observer Pattern).

In short, you can conceptually think of this as the following:

Things happen when WordPress is processing information.
You can register your own function to fire when these things happen.

Not too complicated, is it? A high-level example of event-driven patterns A high-level example of event-driven patterns

When you begin to think in terms of the paradigm in which it works rather than trying to make it work the way that you want it to work, it’s liberating. It helps to solve problems much more easily.

The bottom line is this: WordPress implements the event-driven design pattern, so even if you end up trying to implement MVC, you’re still going to have to utilize the hook system.

If you’re not careful, you can end up trying to craft the perfect architecture without actually getting your work done, and thus end up finding yourself so high up in the atmosphere of software that you’ve effectively become an architecture astronaut. So You’re Saying Avoid Design Patterns?

Not at all! Design Patterns serve a purpose because, above all else, they basically give us solutions to previously and commonly solved problems. Use them!

But the point I’m trying to make is that we don’t need to try to force things to fit pattern just because we like the pattern. That’s not their purpose. Instead, leverage the primary pattern that your platform of choice implements – in our case, it’s an event-driven pattern – and then implement patterns where they fit (such as dependency injection or something like that).

Otherwise, it’s like trying to put your foot in a glove.

Courtesy (and totally copied :P) from : http://tommcfarlin.com/wordpress-and-mvc/