NOTE: This post refers to CMS technology no longer used on this site.
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…
UPDATE 05 January, 2016
The latest version uses a static site generator, so all syntax highlighting is pre-done in the actual HTML, so requires no local resources and should 'just work' across all devices.
9 July, 2010 - 23:51epsi
Does this caching problem solved in Drupal 7?
19 July, 2010 - 02:41Dr. Andrew Marsh
It’s not that it hasn’t been solved as it’s really the intended behaviour of a fast CMS. However the answer is essentially yes. Drupal 7 does the same thing, if not even a little more aggressively.