Reproduce: - edit a document with BXE - save&exit - the changes are not reflected on the document Thanks for a hint, Renaud
Page is most likely being cached by your browser, try refreshing. We should set the cache control for the authoring area to not cache. I have noticed this too since the last modified date was formated properly. This is good for the live area, not so good for authoring.
Thanks Doug, This is a caching problem indeed (refreshing the page did the trick). BTW Oneform works without refreshing. It is very strange, because I cannot reproduce this bug every time... > We should set the cache control for the authoring area to not cache. Yes, makes sense. I am not sure where to do that, so that it affects the authoring area only. I guess you are thinking about the publication sitemap, because all pipelines in the sitemap.xmap of the BXE module are of type noncaching.
(In reply to comment #2) > Thanks Doug, > > This is a caching problem indeed (refreshing the page did the trick). BTW > Oneform works without refreshing. > > It is very strange, because I cannot reproduce this bug every time... > > > We should set the cache control for the authoring area to not cache. > Yes, makes sense. I am not sure where to do that, so that it affects the > authoring area only. I guess you are thinking about the publication sitemap, > because all pipelines in the sitemap.xmap of the BXE module are of type noncaching. Caching needs to be disabled in the response headers or in the <head> for documents accessed in the authoring area. I don't believe that the sitemaps are caching, just the browser (client side caching).
Isn't it already done within the publication sitemap? <map:act type="set-header"> <map:parameter name="Last-Modified" value="{date-iso8601-rfc822:{page-envelope:document-lastmodified}}" />
(In reply to comment #4) > Isn't it already done within the publication sitemap? > <map:act type="set-header"> > <map:parameter name="Last-Modified" > value="{date-iso8601-rfc822:{page-envelope:document-lastmodified}}" /> > actually, I think that the addition of this header (correct formatting) is when I started to notice the browser caching. Anyway, I added a Cache-Control: no-cache header to documents served from the authoring area (default pub sitemap). It seems to have resolved my caching problems, please test ;)
Found out now that a web browser calculates an expiry-time for a web page, using the last modified date (if present). If a document has not expired, the browser will not reload it from the server. (See http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html) The heuristic algorithm is something like expires = now + (date header - last modified header) / 10 This explains why the problem started when the last modified header was set correctly, and also why it only happened sometimes (when the last-modified date was "old"). So Doug's solution seems to be the right one, and it worked in my tests.
what's the cleanest way to overcome this problem? my current approach is to add some cache-control meta tags to src/webapp/lenya/xslt/menu/menu2xslt.xsl (see attached patch). i believe this is the correct way to do it. please review and, if it's ok, apply asap, since the current situation is absolutely mystifying to users :-D
Created attachment 18322 [details] disables browser and proxy caching in the authoring area, so that users see their changes immediately.
it appears that the meta tags for cache control will not disable caching in firefox in all cases: when leaving an editor or creating a new document, the changes are visible immediately, but when you submit or publish etc., the browser still caches and you don't see the current workflow state until after a reload. i suspect that if you select http 1.1 support, firefox expects 1.1 conformant cache-control headers. after adding the following action to my publication sitemap, firefox no longer caches: <map:act type="set-header"> <map:parameter name="Cache-Control" value="no-cache" /> </map:act> the question is: where do i add this in a clean way? i tried to find a global sitemap matcher that handles all requests in the authoring area, but couldn't find one. please help!
AFAIK there is no specific "authoring" pipeline. But you could use a ParameterSelector to check for {page-envelope:area} and invoke the action only if the area is "authoring".
(In reply to comment #10) > AFAIK there is no specific "authoring" pipeline. But you could use a > ParameterSelector to check for {page-envelope:area} and invoke the action only > if the area is "authoring". sorry, it appears that this bug has been fixed a while ago: http://svn.apache.org/viewvc/lenya/trunk/src/pubs/default/sitemap.xmap?revision=379396&view=markup i had not synced my custom sitemap to the trunk... this fix solves the problem for me. sorry for the noise. btw: the fix is in a part of the pipeline that is actually specific to the authoring area.
(In reply to comment #11) [...] > btw: the fix is in a part of the pipeline that is actually specific to the > authoring area. Yes, because it's applied to the default publication's sitemap. The fix won't work in other publications, unless they use the default pub as a template :(
(In reply to comment #12) > Yes, because it's applied to the default publication's sitemap. The fix won't > work in other publications, unless they use the default pub as a template :( true. we need to move more functionality out of the default template and into the core, but i think for now the recommended practice should be to sync one's custom sitemaps with the default one regularly, so as not to miss important fixes (which happened to me in the case of this bug). i have since taken to maintaining my own sitemap as a diff against the default one.
Renaming Lenya 1.4 to 2.0