WordPress with MVC? Cantilever Philosophy Explained
Articles,  Blog

WordPress with MVC? Cantilever Philosophy Explained

Hello, my name is Ty Fujimura. I’m the
founder of Cantilever and today I want to give you a behind-the-scenes
look at the methodology that we use to build WordPress projects
which is called Cantilever Philosophy. As you will know if you work
with WordPress, it can be a little bit tricky to create code
that is sustainable and maintainable for the long term; and that’s what we’re all
about at Cantilever. So, when we realized that clients really wanted WordPress
sites quite a bit and that it was going to be here to stay, we
resolved to build some infrastructure that would let us create WordPress sites
in an architecture that is a little bit more suitable for modern web development
– and that’s what we’ve come up with. So, I’m going to give you a quick tour. So, this is Philosophy. I’m showing
you a local environment. The way Philosophy works is it’s essentially
a full website project, but it’s just for testing. We try to keep it up to date
with our latest practices. Every time we create a project, all of
our projects are very much coded by hand. So, we start off with the basis
that Philosophy provides us, but then we’re going to continue to grow and
evolve from there as we continue on the project. A lot of the time we’ll make innovations in
certain projects and then bring them back in. A couple months ago we did a large round
of updates to Philosophy to make it even more – I think it made it feel even more
modern – and so I thought it would be the perfect time to do a little demo. The
main driver behind why Philosophy works is that you want WordPress to be there
to manage your content, but you don’t want your code to
be running through the normal methods that WordPress uses. If you’re doing
custom, you know sort of real software development, if you’re making a blog,
you’re making something simple based off an existing theme, even something complex —
there’s lots of companies that make really amazing things happen with
the normal WordPress template hierarchy and structure, but that’s not for us.
For us we’re really looking for a model view controller style development experience.
It’s going to make our code a little bit more portable if it’s ever going into
other systems or from other systems, and give us a typical development
experience even for people who aren’t used to working with WordPress. So, our
goal with developing the system was to abstract out the WordPress-yness and have
code that looks more like a generic MVC application: and that’s
Philosophy. So, here in page.php, which any WordPress developer will recognize,
you’re used to seeing lots of stuff here: “get header,” “get footer” the loop in
the middle, your normal page template stuff — and we don’t have that here.
Instead, what we do is we call our global application object and we have a special
method on that object which which serves a page, and when a page is served
essentially what we’re doing is calling a controller and we’re calling that
specific method inside that controller. So, if you’re not familiar with MVC
concepts, you can do some research — background research — on that to
understand that terminology but essentially the controller is
responsible for determining what’s going to be shown on a given page and for
calling the right view to actually show that data. So, I’ll go back
through this request to see — to show you how it’s working. Over here is our
fake home page that’s actually running through this template which is a normal
WordPress page.php template except instead of having regular WordPress
stuff, it has this single call that is an entry point into our full
application. And all of our application code
is stored in the app directory. So, outside of that we have other things that are affecting different parts of
the WordPress theme. You’ll notice
that this is in the normal traditional WordPress themes location. At least for
now, that’s still our model, but all of our custom application code is in here.
And all the working code — the things that our developers are using
on a day-to-day basis — is going to go in this folder. And within that we have a
controllers folder and that controllers folder contains a file page controller,
which is the one in question here. When we’re looking at this page
controller, you’ll see: right now it just has one method. On more complex
applications, page controller can contain all sorts of methods ranging from normal,
restful routing methods like show index, update, etc. to customized
functionality that has to do with that controller and what’s going on
there. If you’re not familiar with an MVC system, as I mentioned, that’s a great
thing to research in the background; but if you are, this structure here
will look very familiar to you if you’ve worked with Laravel namely, or Cough PHP,
or any of the other prominent PHP MVC frameworks. So, even if you’ve just worked
with another MVC framework like Ruby, you might see some similarities
here in the way that this works. So, here’s our show method. And
as in most MVC systems, the controller’s responsibility is really to figure
out what data needs to be included on the page and send it out to a view. And
that’s exactly what’s going on here. All of our controllers
automatically come with a model which is going to come from the database, and
it will be automatically delivered to the controller method in many
cases as this model. It’s going to do some manipulation on that
and create what we call a context, which is the data that’s going
to eventually be sent to a view. Then, it’s going to call a render method that actually performs that action. We’ll do future videos and resources that
explain the nuances of each of these things, but what I want to show
right now is the model layer. When we’re looking at this .model,
when it comes to a page like our home page, the model in
question is a page model. The way we have our models defined,
they’re also done in a very simple PHP-class style. And what the models need to do is
intermediate between the WordPress side of the application and the Philosophy
side. So, we have our custom code: our custom code expects things to be
formatted in a certain way, but as we all if you’ve dealt with WordPress,
WordPress has a very peculiar ORM or method of getting data
from the database. So, the model layer in our application is where we
perform those actions so that the rest of the codebase isn’t doing stuff like
“get field,” or “WP query,” or any of the other methods that are available to
actually get database information. That’s all handled in the model layer: it’s
contained and the rest of the application can act as if WordPress
wasn’t even the source of this data. So, you can see some examples of
that here. In this case, we’re using advanced custom
fields. Advanced custom fields contains or comes with several utility
functions for fetching the ACF data. If we were to look at some of our other
models including, the base model from which all models come, you would see that
the first thing that we’re doing is looking at a WordPress post object.
So, when we’re creating a model, the first thing that we’re doing is using the data
that WordPress naturally delivers for that object. So, one thing I could do here
is — we know that this page model is being generated as part of rendering the page,
so what I’ll do is just dump this out so that you can see kind of what it looks
like initially. Actually, what I’ll do is this. If you’re not familiar this is a
little utility function: “dump and die,” which is something that we
snagged from the Laravel-side of things. You’ll notice some other very
Laravel-inspired — or even directly pulled from the Laravel code base — code within our system as well. So, here is the WordPress post that
this model originally comes in with. If you’ve worked with WordPress, you’d
be very familiar with how this looks. It has ID, title, status — all that stuff. This stuff is very WordPress-y
and useful to a lot of more typical WordPress
in applications or situations. But for us, we don’t really need it. We don’t really care about “ping status,” or “post modified date” a lot of the time,
or anything like that. So, what our model layer does is it takes
this data and it processes it, and turns it into a cleaner final format. So, what I’ll do is I’ll take away this dump,
and I’ll show you how things look at the very end after we’ve done all of
our processing within a model. So, that’s the old one.
I’ve just loaded a new tab here. And this is the new one. The old WordPress post data stays in
here as a key, but what our views and controllers are going to be dealing with
is the cleaner, pure data that we’ve pulled out. So, these are all the things that we really
actually need in order to render the page. They’re pulled out into this nice, clean format
that doesn’t contain any of these keys that we don’t actually need from
the old WordPress post format. So, that’s really the crux of
why Philosophy works. It’s a normal MVC structure for building a page,
but what really powers it is the fact that the model layer can intermediate between
WordPress and our custom code base to create models that the rest of the
code base is going to very easily work with while retaining the power
of the WordPress CMS and interface — and the comfort level that a lot of our
clients have with it. So, yeah! Look forward to much more
to come on Philosophy. We plan to do a lot more content related to it, sharing some of the things that
we’ve learned while while building it. This is just a brief introduction. I would love
any feedback or questions in the comments, and yeah! See you next time.
Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *