Continuing my ongoing efforts to simplify the middle-end, this post will focus on a high-level discussion of how you might start to adjust and adapt the middle-end concepts (CVC pattern) for use in a CMS environment, for instance a WordPress blog.

As with everything else I’ve presented so far, I have no cleanly packaged “install” you can grab to solve your woes. On the contrary, I believe that pre-packaged frameworks and modules usually lead us to the mess we’re already in — that is, they tend to hide from the developer the very details we so critically need to get our brains wrapped around and our hands in control of.

Re-architecting the middle-end of your site/application will never be as easy or as sexy as just dropping in a new module/framework, because the point is to tailor your middle-end specifically to your own needs, which is opposite of the goal of most turn-key frameworks that “do it for you”.

Whenever I talk about code or about possible ways to address these concerns, that talk is nothing more than presenting reference implementations as starting points for what your system will need. The middle-end is a pattern, not a package.

Steep mountain

I consider myself pretty well-versed in PHP and application coding, from the UI down to the database. But when I started thinking about these ideas for the middle-end, I admit the most daunting task I could come up with is how to apply them to a CMS like WordPress.

What I know from the few times I’ve tried to customize WordPress is this: it’s great and easy if there’s already a plugin available, but otherwise, you’re in for some long head-scratching nights. It’s not that WordPress isn’t flexible — there’s lots of hooks in there and you can do a lot of stuff if you know how — it’s that the knowing how is quite a challenge because of how sophisticated the system is and how many different flexibilities it needs to accommodate for.

So, how might we take our first steps to climb this challenging mountain of a task?

Preparation

First, let’s make sure we are clear on what it is we want to do with WordPress CMS to adapt it to be “CVC-friendly” (that is, properly architected for a well-formed middle-end).

As I’ve mentioned before, a proper middle-end will give you complete and custom control over things like templating, URL routing, data validation, data formatting, etc. Moreover, I’ve posited that the middle-end is this interesting beast in that it straddles the fence between browser and server — many middle-end tasks need to be performed in both places.

And because there are many of these shared tasks between both environments, having to code solutions twice (once in JavaScript for the browser, a second time in your back-end language of choice… PHP in this case) is both time consuming and brittle. For many middle-end tasks, it would sure be nice if we could DRY (don’t repeat yourself) code the tasks once and use them in both places. That’s a big motivation for all my middle-end rattling.

But, does a WordPress blog really need to do all that? In some respects, no it doesn’t. A typical WordPress blog is not necessarily what I’d characterize as a full-blown web application. By far, the most important thing for a WordPress blog is usually the content, not necessarily the intricate user-interactions with that content.

But that doesn’t mean a good middle-end is unimportant to your WordPress blog. In this case, the ability to control certain middle-end tasks for web performance optimization efforts is likely going to be our primary motivating factor.

For instance, let’s say we just want to gain more custom control over how resources (JS, CSS, etc) are packaged together and delivered to the browser. The reason this is so common a frustration in CMS’s like WordPress is the tendency of many individual separate plugins to all add their own script/css dependencies to the document in various strewn-about ways. There is a central system in WordPress that should make this easier, but many plugins don’t use it well. And even the central system itself is not quite good enough for what we really need.

So, rather than focusing so much on creating a server-side JavaScript driven middle-end whose code can run in server and browser alike, we’re going to take a step back and think about how we could architect our WordPress blog so that these tasks we want to do are easy enough to be practical and efficient without knowing all the intricate details of a very complex “hooks” and plugins system. Server-side JavaScript is one option we could choose for that task, but by no means required. Much more importantly will be that we focus on the easiest path to achieve a well-formed and flexible middle-end.

Option 1

Our first option is to get really familiar with how the internals of WordPress work. I know from personal experience that such a task can be both a blessing and a curse, both fruitful and frustrating. As I said before, my strong preference would be to find an existing plugin that does exactly what I want it to do. But with the overwhelming popularity of something like WordPress, that can truly be like finding the needle in the haystack.

Usually, when I decide I want to do something new on my WordPress blog, I go spend several hours searching and researching various plugins. Then I’ll pick one or two to download and try out. I install them, start messing with configuration, and usually find that it’s almost what I want but not quite. Could I settle? Sure. But I’m a coder, that’s not likely to happen!

So then, I may try a couple of other options, only to be similarly frustrated. I may then start trying to google and dig through WordPress documentation, comparing what I see in the code for the plugin to what I read about on the web. And, being a decently confident PHP coder (by no means an expert!), I may start trying to tinker with the code to tweak it to what I want.

And sometimes this will work out. But now I have a problem (that I won’t realize until a month later). I’ve customized a plugin’s code for my own needs, and I’ve now forever damned myself to having to remember those customization patches and re-apply them every single time that plugin notifies me of a new release. A number of my plugins update themselves quite regularly, so this becomes a real pain.

For instance, right now, I have 2 plugins that have notified me of an update, but I’ve resisted doing the update because I don’t want to spend the 10 minutes to go back in and refresh myself on what customizations I did. I know in this case the customizations I did referred specifically to our task of customizing how JS and CSS resources are packaged and loaded. But it’s still time and hassle that I don’t want to spend. And so I miss out on the benefits of the update until I pay that price.

I am not going to sugar coat it: this process sucks. Even if I do figure out how to customize a plugin for my own needs, which in and of itself takes a lot of effort, then I have to keep spending that effort over and over again every time an update comes out.

Bottom line: option 1 is possible, and it’s quite likely that for most middle-end tasks, you could figure out a way to hack around existing plugins to bend WordPress to your will. But unless you’re a WordPress guru (I clearly am not) and have the time and inclination to regularly hack on it, the benefits of doing so are probably not worth it.

Option 2

Out next option would be to go to the other end of the spectrum entirely, and not do anything inside of WordPress. We could, for instance, set up a “proxy” server (of sorts) which all browser-initiated web requests get sent to first, and that “proxy” would then make a sub-request to WordPress to get the desired page/content.

What this approach would allow us to do is basically “post-filter” all the content before it actually goes out to the browser. For example, we could take the HTML of the page response, and parse through it looking for our <script> and <link> tags. When we find them, we could remove them from the HTML stream (just text at this point!), and then append to the HTML document a more optimized set of resource loading commands.

Basically, we could find all script tag references, open the .js files they refer to, concat them all together into a single .js file which we cache ourselves in our proxy’s control, and then add a single <script> tag back to the HTML document referencing that new concatenated file. A similar process could be done for all our CSS resources.

You may even want to get more elaborate (as I would advocate) and instead of compiling like resources into a single file, compile them into 2 or 3 files, and use dynamic loading techniques in the browser to load them in parallel, even further speeding up the page-load optimization. One such dynamic loader you could use would be LABjs, the performance script loader that I built.

But let’s not kid ourselves: this is a drastic approach. Setting up an entirely separate web server (or web server instance/VM) just so we can post-process some HTML markup!? I’m not saying this wouldn’t work for some people, but I am thinking that it’s probably something that has its own set of daunting challenges and extra “costs” (especially maintenance) involved.

Not only is it drastic, it’s also more brittle. No matter how good your coding skills are, parsing through arbitrarily generated and complex HTML markup and modifying it on the fly is going to be difficult to do, at best. And it’s quite easy for it to break if your HTML generation routines (your blog) change how they do things in a way your “proxy” was not expecting.

Bottom line: option 2 is also possible, but probably not exactly what we want or need.

Option 3

For our last option, let’s dial things back just a little bit and be a little more realistic. Let’s not try to fight against WordPress, but to work with it. What I mean is this: WordPress is very capable at doing what it does, and if someone has already built a plugin that suits your needs, by all means use it. But the other thing that WordPress does (and I think decently well) is let us completely control the ultimate output of our blog engine using the Themes (templating) system.

So maybe we could try this: let WordPress do what it does best, as a good solid CMS. But run it as essentially a “headless” black box application and practically ignore any presentational stuff that it wants to do. We can ask WordPress for content/data, but we can let the middle-end layer do what it is best suited for, which is handling these various middle-end tasks.

What I’m about to suggest may seem radical… but read the sentence a few times and let it sink in. Make a theme for your WordPress blog which does nothing of generating HTML markup, and only formats necessary data/content into JSON.

That’s right! Reduce the templating/themeing system of WordPress to nothing more than a JSON serializer for the relevant content and data to construct your page. What data? How about an array of all the scripts and css files. How about meta data like the page title, etc. How about the raw content for the blog post the page displays.

What would we do with that data and content in JSON form? We could have a separate middle-end layer that took the JSON and did something useful with it. That middle-end layer could be server-side JavaScript. But it also could just as easily be more PHP (outside of and strictly separate from your WordPress blog engine). Or it could be some other language you are more comfortable with.

But whatever language your middle-end is written in, you would do some very basic things:

  1. Take the list of .js and .css resources in the JSON array properties, and perform the above suggested logic like concatenation, caching, etc.
  2. Take any meta-data and properly “format” it for HTML use, such as converting special characters to HTML entities, etc. Or, perform “internationalization” formatting on your data/content.
  3. Perform any other middle-end suitable tasks on the data and content as necessary.
  4. Lastly, pass that data/content into your templating engine of choice, and then send the output directly to the browser.

You see, we don’t have to change much about how WordPress does its magic to start having more proper control over the middle-end. And we don’t even have to venture into server-side JavaScript to do it. All we have to do is trick WordPress into giving us data and content in a friendly way that allows us to do what we want with it.

And the Theme/template system makes that really easy. Nothing about the state or complexity logic that WordPress is doing can’t be somehow down-formatted into data/content in JSON form, and so we’d practically lose nothing of the functionality of WordPress, but gain lots of control in the areas we need it most.

Conclusion

CMS’s are a fact of life on the web. They sit somewhere between a full web application and a basic content web site. As such, there are reasons why we can benefit from a more well-formed and properly architected middle-end. But it doesn’t have to take wholesale hackery on our blog engine to do so. There are ways to work with it to massage the content/data in such a way that we can layer in a middle-end without too much of a radical change to the architecture.

This entry was written by getify , posted on Thursday July 15 2010at 09:07 am , filed under UI Architecture and tagged , , , , . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

4 Responses to “Middle-end your CMS”

  • Hi getify.
    Being reading your articles about the middle-end layer, and they present a very interesting concept that already exists in both the code and our minds, but that it’s very difficult to identify and manage separately (from front and back-end stuff), as you clearly state.

    I like your pattern/conceptual approach to this topics, instead of giving a packaged solution that only leads to bring people asking “I’ve drop the file in my server and it just doesn’t work, help me, please, it’s broken, fix it”.
    Although it would be also cool to see some of that server-side JS (Node.js based?) you mentioned but refuse to show. I know, I know, you probably don’t want to get people too excited ;)

    Well, I’m more of a front-ender, but I can also hack my way into back-end/server-side basic stuff for creating websites that, as you said, “sit somewhere between a full web application and a basic content web site.”.

    I know we are talking about conceptual patterns, intangible code here, and I may go off on a tangent here, but I wonder why such a clever developer like you is using that WP-thing, being that in this world, there exists something called TXP, which surpass the hyped WP-thing by much, imho.

    You know (alert: conspiracy theory ahead), TXP, the thing that would have just made WP run away into the shadows if it wasn’t for some secret agreement between Dean Allen and Matt Mullenweg. Thankfully Matt gave some credit to Dean and TXP in the About section of WP.org, “for ideas and inspiration”.

    Sorry, I’ve finally gone off the tangent.
    What I wanted to say is that a middle-end approach seems something very doable in TXP, being that it is, in its front-end output, just a blank canvas, and its tags (TXP superiority: its tags, its tag parser, its tags-in-tags parser’s superpowers, and its plugins) are very flexible on terms of the markup they can generate.
    I’ll experimenting whenever I find the time with this middle-end concepts.

    Thanks.

  • getify says:

    Thanks for your comment. I’ve honestly never heard of TXP before, but I’ll certainly take a look. I don’t necesarily love WordPress, but it’s been pretty good for my needs thus far. I’m definitely not a hard-core blogger like some people are. :)

    I know I talked mostly about WordPress in this post, but I believe the ideas and approach I’ve presented are really true for most CMS’s and blog engines. My hope is that people will see this as the pattern/approach, regardless of which particular implementation they may currently have running.

  • Julián Landerreche says:

    You are welcome.
    Funny that you never heard of TXP before. It’s a well kept secret amongst frond-end developers ;)
    But there were and still are some really good talented coders in core dev team (in fact, Automattic kidnapped Alex Shiels from TXP code dev team).

    Trying to avoid hijacking the main topic of this article and comments thread, let me add that if for some reason you are curious and feel tempted to play with Textpattern, please, feel free to contact me if there is anything I could do to help you make it easier to grasp its concepts and climb its not-so-stepped learning curve, and get directly on some hardcore TXP coding.
    Would love to see some middle-end concepts applied over a proxy-Node.js-Apache-TXP-powered website :)
    Yeah, a fanboy encountered you, deal with it. But the community is lovely too.

  • Dan Tocchini says:

    Man, I’ve been pondering this same exact WordPress – Node.js setup… Thanks for the confirmation that I’m not crazy!

    I wish Heroku would hurry up and open up Node.js hosting…

Leave a Reply

Consider Registering or Logging in before commenting.

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notify me of followup comments via e-mail. You can also subscribe without commenting.

 

Switch to our mobile site