https://bugzilla.wikimedia.org/show_bug.cgi?id=56874
--- Comment #6 from Bawolff (Brian Wolff) <[email protected]> --- I should clarify my comment above wasn't to say its less important of an issue, its just important to clarify which bugs are we intend that x does y, but that doesn't happen, and which bugs are it would be nice if x does y but no one has made that happen yet. (In reply to comment #4) > 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. Well it does something, just not what you want it to do... It clears cache of things viewed through normal web view. The dialog is primarily to stop people from linking directly to the purge page Instead of via a normal url. > 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. I don't think you are having the caching issue you think you are. The squid/varnish cache for non-rl js *only applies to logged out users *would last about 30 days not ten minutes. You description makes it maybe sound like something to do with local browser cache maybe. Would need more investigation. > 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. I don't disagree. (In certain cases anyhow) > 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? Perhaps an unideal design, but per above I don't think this is related to the issue you are seeing > > [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
