Stung by Drupal's Filter Caching, Again

I just changed the syntax highlighter on this site from GESHI to SyntaxHighlighter 2.0 as it allows for better copying/printing of the raw code and moves the work from PHP on the server to JavaScript on the client. However, because I use quite a few different languages here, the Drupal wrapper project appears to include all enabled ‘brush’ classes in the page header irrespective of whether they are actually used on the page or not. Whilst this is not a huge problem, I’m a bit conservative and that’s quite a few keyword and function arrays to process for typically no benefit.

Thus, I just spent the last three hours modifying the module to parse out the ‘brush’ types used in the current page and making sure it only includes the core JavaScript header files and associated brush classes when they are actually needed.

Problem is, Drupal 6 now caches all filtered content but doesn’t cache the associated JavaScript header files. Thus, if it has filtered any part of a page previously, it simply pulls the already filtered content from the temporary cache and never actually calls the filter module functions. Thus, the filter module never gets the chance to parse that page content ever again so, as I tried to be smart and only add the header files if the module actually processed something on the page, the headers are never included in any subsequent page view.

Of course, when you are an idiot like me, during the development process it all appears fine because you typically make some code changes, clear the cache and then refresh the page you are working on to see the results. That all works - until you view the page again without first clearing the cache. I only did that three hours in…

There doesn’t seem to be any way around it so the original author of the Drupal module was probably right to include everything just in case it’s needed. It’s now a bit clearer to me why he’s adding everything in the module’s initialisation function with only a few simple checks for user-specific pages to exclude.

Obviously I could do something like adding a ‘/scripts/’ prefix to the url of all pages with embedded code in them, and then add code to the module initialisation to include the headers only when that is detected in the node path. However this starts to be a management nightmare and means it can’t be used by other modules or in teasers.

Having tried this site on a couple of my older machines, it doesn’t seem to be unreasonably slower to render with the extra unused header files so, at least for the moment, I’ve given up all attempts to streamline it.

Though if anyone out there has an idea for a nice clean method of doing this, I’m all ears…

Comments