Personal Blog Post:

Stung by Drupal's Filter Caching, Again

When will I ever learn? I just lost another few hours of my life because - again - I didn't properly understand Drupal's filter cache system.

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 (Matthew Young) 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 the 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...

Your rating: None Average: 2.6 (38 votes)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

You bring up a very important

You bring up a very important information regarding Drupal filter.

You absolutely right, the filter content is cached by Drupal but the javascript header files are not execute or included.

Here's an example: I want to filter the "!drag" and replaced by "", so the jquery drag and drop will convert it to a drag and drop text. However, if the filter header script is not executed, then the filter is completely raw of data.

I think this issue, is important to fix in the next Drupal release.

Thanks for spending the time

Thanks for spending the time to debate this, I really feel strongly about it and love reading extra on this topic. It is highly useful for me. Massive thumbs up for this weblog!

How 'bout 7

Does this caching problem solved in Drupal 7?