Arthus Erea wrote: > > Furthermore, there should be an option to disable the cache somewhere > in the UI. That would give tinkerers the ability to work on the theme, > then re-enable the cache when they're done. > Where should such an option be? In the theme config or in the main > settings page? (I'm leaning towards main settings.)
Sounds fine to me. >> There really isn't a need to use that one directory, but it would make >> it easier to route requests. I imagine a rewrite rule that resolves >> to >> a single hook, where the file that the request asks for is passed in. >> Plugins/Themes that can resolve the file simply return it, and the >> system takes care of putting the file where it belongs and managing >> versioning. The plugin would call a specific function to clear a file >> from the build cache. Also, some logic for versioning and appending a >> querystring to the URL (like .../style.css?6) would be handled by the >> system. > > What would the benefit of the querystring be? Shouldn't there really > just be one version regardless? If the CSS is served properly, it will come with headers that set a long client-side cache life. This is a benefit because it will avoid the client from continuously requesting updates of the CSS from the server. The downside is that if the CSS is actually updated on the server, there's no way the client would know, since its cache settings tell it not to request updates. The remedy is to add a simple querystring with a version number. The querystring is ignored by Apache, but the browser sees it as a new URL, which circumvents its previous cache settings for that file. The same file is served, but by adding the querystring, the client behaves as though the cache must be refreshed. Upon receiving the new file, it is once again cached, hopefully using the same settings as before, and will subsequently not be requested again until that querystring number is updated. This is a fairly standard method for implementing a solid client-side caching strategy, while still enabling server-side changes to propagate to the client. > In terms of HiEngine, I wonder if we could actually run both PHP and > HiEngine at once on the generation. I'd see it working like this: > 1) We open a buffer to catch the output > 2) The stylesheet is included > 3) We run the resultant css through the HiEngine > 4) We output/cache the CSS > > Since most requests will be served from the cache, this shouldn't be > too much of a hassle. I'm not sure what this is meant to accomplish, but it seems unnecessary. Owen --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to habari-dev@googlegroups.com To unsubscribe from this group, send email to habari-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
