MVC structures in WordPress plugins

Essentially what I’m talking about is a way of building plugins. Now what I don’t want to do is go uber-technical and make this into a big thing that’s just going to make no sense to anyone who’s not interested in this. It’s also just a bunch of ideas that I’ve had that are starting to coalesce together; it’s not a ready-made solution but it’s something that I’m building in production environments at the moment as a way of making plugins more robust.

So MVC stands for model view [controller] architecture, and so the model: the model is data. That’s where data goes, so in traditional MVC architectures, things like Ruby on Rails and other similar frameworks, it’s actually where you have your data; it’s where you talk about objects and it’s how you connect to your database and represent items in the databse as objects that you can deal with easily and so I’ll get onto how that relates to building plugins in a moment, so next is up views.

Views is about presentation; it’s just about display, so it’s a very one-way system, so it’s about taking data that you’ve got form your model and spitting it out to the browser or to some feed or to something like that. So it’s purely what’s known as presentational logic. And finally…

is the controller, which is sort of the glue between the two aspects. It’s what handles a lot of the functionality stuff, so you’ve got data, presentation and then in the middle is the stuff that actually makes things happen, so when you’re submitting a from, the form would be in a view, it then goes to a controller which deals with that information – maybe it saves that data into the database – and maybe it emails the result of that, and that would kinda of be done in the controller. So next up:

The typical WordPress plugin kind of has a lot of this all smushed together, and you have bits of presentational code, functional code, database code, different bits of logic all mixed up in the same codebase and often in the same file… like, one file… which ends up being massively long, and has got HTML and PHP, sometimes even SQL all mixed up in the same file which is far from ideal.

So what we’re going to talk about is how we can split all of that out and make it easier for us as developers to edit and for people who come after us – sounding needlessly messianic –  to be able to actually make changes and updates and understand what they’re doing. So the idea of having a model architecture is – WordPress doesn’t have that; it has this idea of The Loop, so everything is a Post, you loop through various Posts, but sometimes you need to do things that are a bit more complex. We’re dealing with events at the moment, this plugin that I’m building is an event plugin, and we need to do a few more complex things; we don’t just need to get events from the future we also might need to get events in a particular time window, and some of those events have multiple dates for the same event, so if you’ve got something like a cinema listing, that will have multiple instances of the same event, maybe even on the same day. So we have ways of storing that information using WordPress custom fields, and then what we do is we wrap all of that up using the model idea and effectively what we can do is start building a query system like our own little database API that can talk to WordPress and go “give me back information in the way that I want it”.

So the way that I’ve been working in the moment is building a system that uses SQL but lets me write a query as an object, so rather than have to write a very big long massive hard-to-read query, I can just say “I want stuff from this table, it’s got to link up with that table, where this equals this”. And then I get get more complex, I can actually say “give me this data where information matches this other query which is also just in PHP code, not in SQL”. And what that actually ends up doing is, it actually makes our plugins more powerful because we can achieve things a lot faster, because we’re not having to constantly check our SQL and deal with posts and the flat structure of WordPress being that you sort of have everything as a Post, and then you have key-values… I won’t go into it. But essentially we can make our lives – by doing a little bit of work at the beginning, we make our lives – a lot easier later on, build more powerful applications, because that’s really what, as plugins get more powerful and can do more things, that’s what we want. We want to be making mini applications. So if we move on, I’ll skip views, because views are basically HTML effectively.

So controllers… in more traditional systems, a controller is basically based on your URL, so if you have “mywebsite.com/events”, your system goes and looks for a controller called “Events Controller”. WordPress doesn’t work in the same way because it has its own system of dealing with URLs, and URLs don’t always necessarily match – you know – match up to functions and stuff like that. So I’m working through the best way of doing that at the moment, and essentially what I’m working on is having a plugin controller which can then call on other controllers to do certain things. And the idea being that we compartmentalise the various parts of our app so one of them being having a settings page within WordPress – within the admin – so that is all handled within a Settings Controller, which creates views, handles views, so what we end up with is separating out our settings page into little files so that if we’ve got a typo in a field name or we need to make a quick change, we know where it’s going to be because, well we know it’s the Settings Controller, so we go into the view for Settings and we know it’s this field so we just edit that file, rather than have to do a big search in a bunch of PHP files; we know exactly where it’s going to be, because it uses this idea of convention rather than configuration. So it’s saving “if you follow this pattern, and always name your files; structure them in this way, then because the system knows and expects that, it can give you what you want, and you know exactly where things are going to be, and so does the system”.

So next up is a brief idea of a file structure. So you may or may not be able to see some of this, I don’t know; I’ll move round…

But effectively, the idea if you have your plugin you have the framework which at the moment, we’ve just got a few base classes, and then the actual plugin itself. So the idea is you might be able to take this framework, and create its own plugin so that you install that one, and then all the plugins that you create going on use that framework, and then you haven’t got to repeat a load of stuff. And so we have the actual stuff that relates to our plugins: we’ve got our controller, so we’ve got our base Plugin Controller and we’ve got our Settings Controller. And as you can see, the settings matches up with a view called Settings (a view folder). And so the system expects this so that when we ask for a specific view the system will look at the name of a controller and then try and look for a folder using that name. And so it’s basically using this structure, we can know, if there’s a particular problem with a plugin, chances are we’ll know where to go straight away to actually fix that problem. If it’s a problem with data coming back we know it’s going to be in the model; if it’s presentation we know it’s going to be in the views, and if it’s a problem with functionality, then we know to go to the controllers.

And that’s basically it, so if you pop to the last slide then that’ll be about it, so if anyone does have any questions, feel free, otherwise that’s where you can find me. Thanks very much for your time.

WordPress Birmingham 14th June 2013
Yorks Bakery Cafe, Stephenson Street, Birmingham, United Kingdom