Topic on Project:Support desk

Upload new file version: getting old version unless browser cache refresh

16 (talkcontribs)

We're using [[Media:Example.jpg]] to include versioned pdf files. New versions of the file are uploaded via "Upload new file version" on the file description page.

After having uploaded a new file version, the browser keeps returning the old version until the browser cache is being flushed with "Ctrl+F5".

Question: Is there a way to ensure the newest file version is being displayed without having to hard refresh the page manually? Shouldn't mediawiki pass some kind of "expired flag" when a new file version is available?

Software Version
MediaWiki 1.22.1
PHP 5.3.17 (apache2handler)
MySQL 5.5.33
2A02:C7F:963F:BA00:F497:3E00:4BDD:A80A (talkcontribs)

Please upgrade your MediaWiki version and then get help.

Ciencia Al Poder (talkcontribs)

There's no way to send an "expired flag" to the browser, because the browser is not requesting the URL to see if the file has been updated.

You should configure your server, the path that contains all your uploads, to send files with a Cache-Control: must-revalidate header, that will make the browser check every time if a new version of the file exists, and if not retrieve the cached version.

2A02:C7F:963F:BA00:C4B8:9875:F37D:899E (talkcontribs)
Ciencia Al Poder (talkcontribs)

You already said that. I'm free to help people even if they use an unsupported MediaWiki version, specially if the problem is not with MediaWiki itself. (talkcontribs)

Thank you for your lucid explanation. I have asked our administrator to configure our server according to your recommendation and will then report the result here.

Revansx (talkcontribs)
Waffle2019 (talkcontribs)

Hi there,

I am experiencing the same issue.

I have to ask all users to manually purge the cache before opening a reupload of a file version.

Is there any other way to avoid this? I can edit all mediawiki files on the server, including .htaccess, but I don't have access to the server configuration.

Mediawiki Version 1.31.3

PHP Version 7.1.32

MariaDB Version 5.5.64-MariaDB

Ciencia Al Poder (talkcontribs)

You may try setting a Cache-Control header in .htaccess with a short age and "must-revalidate", to cause browsers to check if a new version is available before returning the cached one:

# 10 minutes
Header set Cache-Control "max-age=600, must-revalidate"

See examples in

Waffle2019 (talkcontribs)

Thanks for the tip, I made this edit! I will follow up with my users in the next few weeks to see if it solved our problem.

Bruceillest (talkcontribs)

I had the same issue and thanks to Science is Power @Ciencia Al Poder :-) guidance I was able to get this working for my instance in Windows Server 2012 R2 with IIS 8.5.

Make sure you have IIS 6 Scripting Tools and IIS 6 WMI Compatibility installed through Server Manager.

I basically opened IIS Manager and navigated to my website folder right clicked and selected "Add Virtual Directory". In the Alias field I put the same name as the folder in my case I customized wiki to use "uploads" folder so I put uploads in the field. For Physical path just hit the 3 dots and select your folder by navigating to it then hit OK.

Open command prompt as admin and enter the following commands please enter in your values in the bold words.

cd C:\inetpub\AdminScripts

cscript adsutil.vbs SET W3SVC/1/ROOT/YOUR WIKI SITE/YOUR UPLOAD_IMAGES FOLDER/CacheControlCustom "no-cache"

Then just test it out.

Ciencia Al Poder (talkcontribs)

Note that disallowing browsers to cache images will cause a lot of more traffic to your server, and slowness on the wiki (because of the need to redonwload all images on every request).

It's better if you set the Cache-Control to "max-age=600, must-revalidate", (you can adjust the time) to allow images to be cached for 10 minutes, and then browsers will query the server to see if the image has changed, and if not, it will continue to use the cache without the need to download the image again.

Bruceillest (talkcontribs)

Thanks for that info luckily my site is for a small group of folks but, I did notice that PHP's FastCGI process does eat up a bit of CPU when this happens and in my situation its not too bad.

If my site grows then I will most likely go down the max-age route.

Bruceillest (talkcontribs)

One thing I wanted to add that upon more testing I figured out that by doing the CacheControlCustom to no-cache it messes with indexing the folder using Cirrus search where I can't search for any media that I added. So the max-age route is a better option to avoid messing Cirrus search.

Ciencia Al Poder (talkcontribs)

I don't see how it can affect Cirrus Search, since Cirrus Search gets updated directly by MediaWiki (using php), whereas your CacheControlCustom property is applied directly to IIS and php is not involved at all. Your issue must be coming from somewhere else

Bruceillest (talkcontribs)

Your right that was not messing with indexing I figured out that Cirrus Search takes a good amount of time to index so I need to try to figure out how to speed that up.