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

That is, developers wants to take an MVC approach to building WordPress applications. And I get it – I love MVC. It’s why I used to work with Rails, it’s why I was really excited when Microsoft released .NET MVC years ago (when I was working in .NET).

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.

Category:
Articles
Tags:

Join the conversation! 20 Comments

  1. I’ve used to have a draft post (which I never finished, and apparently trashed at some point) titled “The OOP Mind”, which is along similar lines. It’s not just MVC that people harp on WordPress about. There are a lot of devs that come to WordPress and gasp, “It’s not Object Oriented! What a mess! We should Rewrite All The Things!”. Of course, they’re ignoring the 10 year history that got us to this point, the massive risk to backwards-compatibility in making such sweeping changes, and the huge progress that has been made in making certain subsystems OOP.

    And like you said about MVC, I’ve got nothing against OOP style coding, it’s great! Encapsulation, organization, scoping, interface contracts, inheritance/reusability, etc. But code written in a procedural style isn’t inherently evil or anything. And in some cases, OOP adds an extra layer of abstraction (or more than one layer) that can get in the way, or be less performant (okay, probably not much performance hit in most cases).

    No, WordPress is not a clean MVC implementation, and not all of it is written in an OOP style. A lot of that is do to its history — it wasn’t an academic project, and it wasn’t originally created as an Enterprise project. But the code is pretty well organized, and easily accessible to a programmer of moderate skill. And I’d call that a win.

    • It’s not just MVC that people harp on WordPress about. There are a lot of devs that come to WordPress and gasp, “It’s not Object Oriented! What a mess! We should Rewrite All The Things!”.

      I’ve been publicly criticized – well, as much as Twitter is public, I suppose – about how I appear to be so OOP and that I push those practices.

      Sure, I dig on OOP, but that doesn’t mean I don’t use procedural programming for certain plugins. Or that I don’t use it themes (consider it has to be done). My biggest complain about procedural programming in the context of WordPress is simply having to prefix functions with unique ID’s to prevent collisions and conflicts with other potential themes or plugins – I think it can make reading the code a little more difficult.

      But I digress on that (for now, at least ;)).

      Of course, they’re ignoring the 10 year history that got us to this point, the massive risk to backwards-compatibility in making such sweeping changes, and the huge progress that has been made in making certain subsystems OOP.

      I had a conversation with someone recently about how all of the major software they use at this point – think OS X or Windows or Linux even, or your favorite office suite or whatever – and how much legacy code likely exists in those applications.

      The difference is closed versus open source. You just don’t know what’s going on under the hood and it seems idealistic to assume all closed source software has this pristine architecture throughout.

      No, WordPress is not a clean MVC implementation, and not all of it is written in an OOP style. A lot of that is do to its history — it wasn’t an academic project, and it wasn’t originally created as an Enterprise project. But the code is pretty well organized, and easily accessible to a programmer of moderate skill. And I’d call that a win.

      Yep. I agree. There’s just a lot of people that don’t. And that’s okay, too. But at least aim to improve a part or parts of it, you know?

      • The difference is closed versus open source. You just don’t know what’s going on under the hood and it seems idealistic to assume all closed source software has this pristine architecture throughout.

        In the world of desktop applications, most developers call Microsoft the king of backwards compatibility. Many Windows 98 applications often continue to work flawlessly on Windows 7 (sometimes even 8 now too) out of the box. In a completely opposite world though, Apple stops supporting versions of OS X released less than two years ago, and frequently drops SDKs from distribution at the earliest possible convenience.

        This really isn’t affected by whether the code is open though, there is no difference between closed and open source in this regard. However, you’re right that you can’t assume closed source software is pristine, my experience has shown quite the opposite typically (not all the time though).

        While WordPress might feel a lot like Microsoft in this regard with it’s backwards compatibility policy, there’s very popular examples of open source web frameworks like CakePHP with backwards compatibility policies that behave closer to Apple where stable branches (even though they are supported for a couple years) are left far behind for huge architectural changes in new major releases. They aren’t afraid to change anything, and frequently remove huge chunks of legacy code all at once, and the code base is definitely way more pristine than anything I’ve found in WordPress. The history is there, but they learned from their mistakes, and moved on without looking back. WordPress tends to look at that mistake and say “oh well, it made it in a release, and now we have to support it working this way for the rest of eternity.” That is essentially what the backwards compatibility policy states.

        • It is an interesting observation about Windows and Apple, I suppose that is exactly why Apple makes it so easy to upgrade that everyone does. When I think about the past 3-4 update I was a part of I think I spent $10 in total. But windows carries the bulk of legacy code while also change hundreds of dollars per upgrade.

          Honestly I wish WP would consider the Apple approach now, I think the community of devs would be better off for it, remove the wasted legacy code, maintain a standard that the community is trying to encourage anyways. Wishful thinking, I know there are reasons to not go down that road, but I think to myself how many times I’ve scrapped my boilerplate/framework to only maintain what is proper and every time it was so worth it even though it required some labor.

  2. Nice read Tom, I appreciate articles like these. It’s true, WP isn’t as modern or “sexy” as some newer frameworks, but it still does very well for what it is. As a blog/CMS that is esy to use and update, it still works well for the vast majority of projects I work on.

    I find as well that after experience, and finding a good starter theme, I personally am in love with the Roots theme, your theme can still be fairly view-like. You don’t need to load up your template pages with a bunch of logic, you can keep that separated to functions/classes in your functions files, which is really how it should be anyways.

    WordPress does get a bad rap, and a lot of it is for good reason. But a large part of it is simply unexperienced or uninformed developers who don’t write the most elegant themes and plugins. Goes with the territory I suppose

    • It’s funny because it’s inevitable that every few months, WordPress will show up on a major site ala Hacker News about its poor architecture, but I’ll be honest: Even in my short career, I’ve never seen an application that’s existed for longer than several years not have some ugly parts to them.

      Anyway, as far as starter themes go, there are definitely some that treat the presentation in a more “view-like” fashion and, really, I’m of the mindset that themes should be more view like, period. There should be very functionality present in themes. This leaves open a whole other debate of bundling plugins with themes or having users install them on their own, but I digress.

      WordPress does get a bad rap, and a lot of it is for good reason. But a large part of it is simply unexperienced or uninformed developers who don’t write the most elegant themes and plugins. Goes with the territory I suppose.

      I almost feel like this could be said about a variety of platforms, languages, tools, frameworks, or libraries (where you substitute their name for WordPress), but everyone has their favorite language through which they see the world through rose-colored glasses, so whatever I suppose :).

  3. I’m in a .Net shop, we’re migrating our .Net solution into MVC, and we don’t have a CMS. If WP isn’t ideal, what is? Orchard? orchardproject.net

    • I know ASP.NET MVC is also an alternative, or are you guys looking to move something completely off of .NET?

      Either way, I can’t speak much to Orchard as I’ve never used it, but CakePHP and Zend Framework and both good alternatives.

  4. I’m curious what kinds of practical problems you’ve run into trying to use MVC when writing WP plugins. Can you give some examples? I haven’t really run into any personally, and I don’t see any inherit conflicts with using it in an event-driven system.

    • Hey Ian,

      I actually agree with you – there’s no problem with putting multiple design patterns in projects. We do it all the time, right? :)

      What I just meant is that from a high-level standpoint, some developers come from other MVC-based frameworks and try to make WordPress inherently behave that way and that can’t really be done with the way the core uses event-driven systems.

      You can definitely implement other patterns within WordPress-based projects, but all I was trying to do was to say that WordPress is event-driven, so we ought not to approach the core foundation or core application like it’s anything else.

      Start by acknowledging its event-driven, implement code as needed using that pattern, and implement other components using MVC, Singleton, Factory, or whatever pattern fits the bill :).

      • Ah, ok, that makes sense. Thanks for clarifying :)

      • Hi Tom,

        For custom functionality, would you suggest first trying to stick with the event-driven pattern, using custom hooks (i.e. do_action) wherever possible, or going the oop route using member functions instead?

        I’m sure it depends a lot on context, but technically the event-driven approach could be carried all the way through and I’m wondering if there is a practical limit to this approach.

        My initial reaction is that, if WordPress is event-driven, we should fully embrace it with the creation of custom hooks up to the point at which it simply becomes impractical. But where is that line?

        Thanks!

  5. Tom,

    I just found this post: http:///hooks-in-wordpress/ which I think answers my question. You really have everything covered here!

  6. I agree with this article 100%. I am perfectly comfortable using the event driven model to build websites/apps on top of WordPress. However, WordPress core is a mess in terms of any kind of coherent structure and is the main reason why I will never contribute to code to core – because it would take just too darn long to figure it all out.

    • However, WordPress core is a mess in terms of any kind of coherent structure and is the main reason why I will never contribute to code to core – because it would take just too darn long to figure it all out.

      I completely understand what you’re saying; however, contributing core really isn’t that bad! I’ve contributed before – to WordPress 3.5, in fact – and it was mainly a matter of going through the open tickets, pulling down a copy of the code from Subversion, making a change, and then pushing it back up.

      Sure, there are some complex tickets that require that you do a lot of work in terms of tracing the code and trying to figure out how to best resolve it, but getting a patch into core isn’t that bad.

      I mention this just because I’d love to see more people doing it ;).

  7. Really helpful and full of knowledge. Thanks

  8. OOP has been a stable for many years; but, based on my experience, MVC is by far more flexible, structured, scale-able and maintainable.

    I do agree that changing WP core to MVC will break backwards compatibility (business wise we don’t want to affect 1/4 of the sites on the internet). But because how open its development is, custom themes and plugins are so different, sometimes over complicated and un-standardized.

    I myself have created a little framework that adds MVC to custom plugins and themes without affecting the WordPress core, with a lot of inspiration on Laravel:

    http://wordpress-dev.evopiru.com/

    Someone already mentioned how messy WP core is… For just one request, and depending the plugins installed, it can run multiple times (which is super inefficient).

    • OOP has been a stable for many years; but, based on my experience, MVC is by far more flexible, structured, scale-able and maintainable.

      I used to be a huge fan of MVC such that I couldn’t imagine working with anything other than that, but as time as progressed as I’ve had gotten more experience with other patterns I don’t necessarily feel that way anymore.

      Don’t get me wrong: I still like MVC and I still think that it fits the model for web pages very well, but I’m not nearly as dogmatic about it as I once was. And I don’t really mind the event-driven system of WordPress.

      I myself have created a little framework that adds MVC to custom plugins and themes without affecting the WordPress core, with a lot of inspiration on Laravel:

      Thanks for sharing this, it’s really cool :).

      Someone already mentioned how messy WP core is… For just one request, and depending the plugins installed, it can run multiple times (which is super inefficient).

      There are things you can do to ensure that a given function only runs once so that it’s not as inefficient. Sometimes this is as simple as dealing with the priority of a hook; other times, it has to do with checking for a value, writing a value, or seeing if something is present.

      If something is firing multiple times, it might need to. Other times, it might not. It depends on what you’re trying to do so having the flexibility for that to happen isn’t necessarily bad, IMHO. It’s just making sure that you do it correctly.

Leave a Reply