omeka / Omeka

A flexible web publishing platform for the display of library, museum and scholarly collections, archives and exhibitions.
http://omeka.org
GNU General Public License v3.0
487 stars 194 forks source link

Cache-busting and queue_css_file() #613

Open ebellempire opened 10 years ago

ebellempire commented 10 years ago

I think it would be pretty useful if queue_css_file() and/or queue_css_url() allowed theme developers to add a version string for purposes of cache-busting, e.g. "style.css?version=1.1"

zerocrates commented 10 years ago

Cachebusting seems like something the queue or display family could handle, but do you see this happening automatically, like reading from the version strings for Omeka and the plugin or theme? That seems like the easiest way to go (though we'd have to figure out some way to actually handle it, since we've got issues telling which files come from a plugin, a theme, or the core, and we'd need to inform the theme system about the versions of things), but it also seems like it'd leave out a common use-case for something like this: cachebusting for development reasons. Presumably, theme or plugin authors wouldn't want to be incrementing their version constantly to get the cachebusting effect.

Alternatively, we could have something like a global cache-bust value that Omeka reads out of somewhere like config.ini, but that puts the onus on people running an individual site to actually make use of it.

ebellempire commented 10 years ago

I think the simplest implementation would be to just add an optional string parameter to one of the queue or display functions, eg:

queue_css_file(..., string $ver=null)

If a developer wants to tie it to the theme version or some other programmatic value, that should be easy enough so long as the parameter accepts any arbitrary string. I'd think this would cover pretty much every scenario:

queue_css_file(... $ver="1.0" ); // integer/float queue_css_file(... $ver="1.01b" ); // version queue_css_file(... $ver="new" ); // string queue_css_file(... $ver=$something ); // variable queue_css_file(... $ver=option('something') ); // function queue_css_file(... $ver=time() ); // unix time for unsetting cache during dev if unable to use other methods

This would mirror how cache-busting tends to work in most "real world" scenarios I've encountered, is really easy to implement for all parties, can be easily understood and overridden by novices (theme hackers, etc), and is totally optional. It also is helpfully similar to the way WordPress' wp_register_style function works.