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.
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?
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.
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.
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.
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.
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.
But whatever language your middle-end is written in, you would do some very basic things:
- Take the list of .js and .css resources in the JSON array properties, and perform the above suggested logic like concatenation, caching, etc.
- 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.
- Perform any other middle-end suitable tasks on the data and content as necessary.
- Lastly, pass that data/content into your templating engine of choice, and then send the output directly to the browser.
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.
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.