Sascha Nemecek <[email protected]> writes: > Hi Michael,
Hi Sascha; A note, I usually go by "MAP". > Am 2016-12-14 um 05:30 schrieb Michael A. Patton: >> I've been trying to debug a new set of code in a file referenced with >> <use/>. As far as I can determine, the only way to get the server to >> load the new file is to use the "Flush all caches" button in the admin >> interface. > > I have had similar experiences with the <use/> tag and can therefore > confirm your observation. And you haven't found any smaller hammers than I did? >> This seems like rather a big hammer, it affects all the >> sites on the server, not just the one I'm working on. Is there >> something lighter that I could be using? > > Docs[1] for <use/> indicate that it caches the results quite heavily and > mentions the attribute nocache='1'. Might be worth a try. The heavy caching is why I use <use/>, it's more efficient and lowers server load. Using nocache='1' requires changing ALL the html files that reference it, and then changing them back afterwards to get the efficiency from the heavy caching that I want from <use/>. One of the features I get out of having a file of standard definitions is these kinds of global changes are easier to do. That is, everywhere but the line that gets the definitions! >> One reason I'm worried about that is I have some pages with lots of >> business graphics images (e.g. http://MAP.MAP-NE.com/Mail/stats.html). >> Those go in the cache, right? If at about the same time as I flush the >> cache someone is loading such a page, it seems like they may end up >> getting some broken images that got flushed out of the cache after they >> were generated in the server parse of the file and before the browser >> loads the referenced image. > > Don't know if this could really happen. I would assume there is some > kind of locking mechanism that prevents such situations. Maybe it does, maybe it doesn't Which is why I brought it up. There can't be a lock, though, since that would require cooperation between the browser and server, which isn't in the HTTP spec. I guess there could be a minimum retention that doesn't get flushed. >> There are also a lot of <cimg/> generated images, they have this problem >> as well, I suspect. If you want to see lots of those, they are in the >> photo gallery on that same site. > > According to the <cimg/> docs[2] you can set a timeout. But that's for the normal case, to set how long it's held in the cache. I would expect the "Flush all caches" to flush regardless. Well, failing any other input, I'll probably keep doing it the way I am, and put it on my ToDo list to separate the production and development web sites to separate servers (it was actually already there :-). That will help isolate client's production sites from the debugging of new features. -MAP
