https://bugzilla.wikimedia.org/show_bug.cgi?id=56874
TMg <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal --- Comment #4 from TMg <[email protected]> --- I'm sorry, but it's at least a normal priority bug and not an "enhancement" if the purge feature pretends to do something (there is even an "are you sure" question when calling [1] while not being logged in) but in reality does not what it's expected to do. If the servers still deliver old versions after a purge something is broken. I have to ask why it got worse yesterday if "its always been" that way. I edit my .js files very regularly. I never had to wait ten minutes before. The URL I'm using is the one created by importScript in wikibits.js[2] which still lacks an adequate, equally user-friendly replacement. If that's how it works you should add these (still) official URLs to the purge request. The root cause is the same as for media files not being purged. From what I understood purging is done based on URLs instead of the original page name. Because of that it's impossible to simply "purge a page". There is no "page" on that level. You don't keep track of the URLs used to call a page (different image sizes, dummy parameters and what not) and you have no way to find out. I called this "broken by design" in some previous reports. Do the users simply have to live with this, accepting that it gets worse when the servers have to deal with heavier page load and caching becomes more aggressive in the next years? [1]https://de.wikipedia.org/wiki/Benutzer:TMg/autoFormatter.js/Beta.js?action=purge [2]https://git.wikimedia.org/blob/mediawiki%2Fcore.git/HEAD/skins%2Fcommon%2Fwikibits.js#L210 -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
