I’ve been hard at work on a dynamic navigation system for an ExpressionEngine project this last week. The project has been a lot of fun in all the right ways; complicated, technical and way outside my comfort zone. Basically, the project was to build a suckerfish style navigation bar using jQuery, superfish (a jQuery implementation of suckerfist) and ExpressionEngine. And therein lies the issue…

I had anticipated making the nav all efficient-like with a single query to pull out all the items and build the nav using unordered lists. I started doubting this as a good idea though when I came to learn how complicated the data model was for this particular project. Now, don’t get me wrong, ExpressionEngine by itself is a blank slate when it comes to the data model for a project and, technically, they have a good and normalized structure for everything. Which was the problem.

An ExpressionEngine site is traditionally (at least as far as the sites I’ve seen and learned from) broken up like the below:

Weblogs
    Categories
        Entries
            Sub-Entries…

So, weblogs have categories which have entries attached to them which, in turn, can have sub-entries. Pretty straightforward I think but when you consider that this all represents around 6 tables that would require some pretty complex joins it’s one of those cases where the “right” way isn’t the ideal way. On the other hand, breaking the SQL up into multiple queries done in a loop is usually a pretty bad idea especially when you don’t know how many times the loop is going to occur.

So, I was fucked with 2 crappy choices and needed to pick the least evil; I settled on looping queries with the caveat of caching. This was ideal because the cache could be set to a pretty large interval so the nasty SQL wouldn’t execute but once a week or so. Having never worked with the native caching mechanism within ExpressionEngine learning about it became the new problem.

To be honest, I’m a little embarrassed that I didn’t delve into learning about this sooner; it turns out ExpressionEngine has a few different caching options available built right in. I’m pretty new to ExpressionEngine, having only been developing with it for a few months, but it was pretty lame that I didn’t immediately look into this option. There are so many problems the built in caching would have solved :/

Query Caching in ExpressionEngine stores the output of certain database queries to a flat file (in fact, all the caching mechanisms store the cache as a flat file). It has to be manually turned on in the administration panel but once it is turned on you’re good; all the queries that can be cached will be cached in (what else?) the cache directory. It should be noted that EllisLab doesn’t recommend using Query Caching because it’s much more effective to just turn on the native caching in MySQL itself.

Tag Caching is useful for storing the output of ExpressionEngine tags on a tag by tag basis. Tag Caching allows for very granular caching so you can have certain portions of a page cached while leaving others completely dynamic. It should noted that Tag Caching only works on ExpressionEngine tags and, unless it’s coded for caching, won’t have any effect on plugins or extensions.

To enable Tag Caching all you have to do is add “caching=‘true’ refresh=‘60’” to any ExpressionEngine tag like the below:

{exp:channel:entries cache="yes" refresh="30"}

The first parameter just tells ExpressionEngine to turn caching on for the tag; the second is the amount of time, in minutes, to keep the cache active before it is refreshed. Pretty simple really though depending on how many tags you’re trying to cache it could be a bitch to implement I think.

Template Caching is what I think of as the most effective caching mechanism ExpressionEngine has to offer. Essentially, ExpressionEngine saves the entire output of a template to a flat file. The really cool thing is that ExpressionEngine caches not only most of the output for most EE Tags used (like the above) but also any php you may have added as well.

It’s a little misleading to say that it’s perfect though; there are a quirk to how it works. The entire, processed, template doesn’t get cached just the heavy database or PHP stuff does; any EE Tag for conditional logic and URLs are still processed after the fact. Not a thing that’s initially worrisome though that may depend on the circumstances of the project.