19 May
2010
19 May
'10
12:12 p.m.
On May 19, 2010, at 12:03 PM, Sergiu Dumitriu wrote:
On 05/19/2010 10:47 AM, Guillaume Lerouge wrote:
hmm if this is a good thing to have why don't we have it by default in XE (it seems to
me like a bug if when you add a new version of an attachment you get the old cached
version)?
Thanks
-Vincent
Hi Felix,
On Wed, May 19, 2010 at 00:42, Meng Wu<mengxwu(a)yahoo.com> wrote:
This has the advantage that it still allows caching while the document
version is the same, which is good for performance, but it has the
disadvantage that it needs template changes, which is problematic for
upgrades. The best way to prevent problems is to attach the modified
template to the skin document (XWiki.DefaultSkin by default).
Another option is to configure this in the front-end (Apache HTTPD
settings, if you use such a front-end). Hey all,
We've been having browser caching problems for attachments where users have
had to wait hours before their data would be updated in xwiki.For IE, for
example, killing all instances of IE, restarting the browser, and then
visiting the attachment is a solution to this problem. We basically need a
way to add a Cache-Control header when the server responds to the attachment
link. Is there a way to prevent caching of the URL for attachments in the
web browser by changing the config files, or by changing something in the
xwiki code?
A solution I've implemented is to change the template that serves
attachments to add the revision number at the end of the attached file
download link (in attachmentsinline.vm
):
<span class="name"><a
href="$doc.getAttachmentRevisionURL(${attach.filename},
${attach.getVersion()})"
title="$msg.get('core.viewers.attachments.download')">#packName($attach.filename)</a></span>
Guillaume