Last modified: 2011-03-13 18:04:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 11420 - Think of ways to reduce annoyance of the unregistered purge confirmation screen
Think of ways to reduce annoyance of the unregistered purge confirmation screen
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-21 17:19 UTC by Gurch
Modified: 2011-03-13 18:04 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Gurch 2007-09-21 17:19:21 UTC
Logged-in users can purge pages simply by clicking a link. Anonymous users have to go through a confirmation screen, the default text of which doesn't give much indication of what it is they are doing.

This confirmation screen is at best annoying and at worst confusing.

If purging was a sufficiently significant operation for this two-step process to be necessary, presumably it would be necessary for logged-in users too.

Is there a good reason for retaining it, or can it be made optional/done away with completely?
Comment 1 Platonides 2007-09-21 17:24:36 UTC
You can configure which users don't need to pass that screen (from nobody to only admins).
The reason for having it is that it's an expensive task for the server. For instance, it prevents people (hot)-linking a ?action=purge version
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-09-21 17:39:59 UTC
According to the HTTP standard, GET URLs -- i.e., those not submitted from a form like the "OK" button is -- should not generally cause a change in the server's state at all.  We bend that rule for users here, but spiders rely on it.  If anonymous users could GET a URL and automatically purge the page, spiders would start purging pages all over the place, which is undesired.

If you have a better idea that allows any HTTP client to purge the page but prevents bots/prefetchers/etc. from doing so, please share it.  The intermediate page will not simply be removed with no substitute put in its place.
Comment 3 Gurch 2007-09-21 17:56:36 UTC
Hmm, thought there might be a reason.

What about robots.txt? I suppose there are too many crawlers that ignore that...
Comment 4 Gurch 2007-09-21 18:00:57 UTC
And as for not hot-linking an "action=purge" version, that's one of the reasons it's so annoying.

Right now on http://en.wikinews.org/wiki/Main_Page the "latest stories - full list" link is a purging one. Since the only people experienced enough to know what purging is and how to edit Main Page templates are registered users, nobody ever notices. But anonymous users who click on that link expecting to see a full list of stories are presented with a black page with "Clear the cache of this page?" and an "OK" button on it. No doubt many of them hit the "back" button on their browser thinking they've done something wrong. I've requested that this particular link be removed, but that will probably take days, and there are many more.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-09-21 18:22:52 UTC
(In reply to comment #3)
> What about robots.txt? I suppose there are too many crawlers that ignore
> that...

There are quite a few, yes.  Not everyone has access to their robots.txt, either.

(In reply to comment #4)
> Right now on http://en.wikinews.org/wiki/Main_Page the "latest stories - full
> list" link is a purging one.

There's no reason I can think of for why that would be necessary or useful.  Page views are always going to be up-to-date, whether or not you purge, minus several seconds or (rarely, I hope) a few minutes of replication lag.  The only reason you'd ever want to purge is if the cache is corrupted somehow, which sometimes happens -- especially for images -- but never commonly enough to merit purging on *every* page view that I've heard of.  Viewing a page all the time with action=purge will do nothing but slow down the page load time.
Comment 6 Platonides 2007-09-21 20:48:43 UTC
The link (added via JavaScript http://en.wikinews.org/w/index.php?title=User:Matt/public/ticker.js&diff=477943&oldid=477931 ) uses purge because the target page uses {{#time}} to render the pages, but
a) The rendering lag won't be too important (unless you're watching it at midnight)
b) The querying JavaScript (thanksfully) uses the cached version.
c) The code could be using JavaScript to generate the pages. 

PS: The wikinews {{esoteric}} equivalent template -used at the top of http://en.wikinews.org/wiki/Wikinews:Ticker -  is nicely named 
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-09-21 20:56:42 UTC
(In reply to comment #6)
> The link (added via JavaScript
> http://en.wikinews.org/w/index.php?title=User:Matt/public/ticker.js&diff=477943&oldid=477931
> ) uses purge because the target page uses {{#time}} to render the pages

I believe enwiki has a bot to rotate templates instead.  Getting hundreds of readers to purge the page every minute is a bad way to go about it even if you need it purged every minute, which I don't think is the case here.  Get a bot to purge it once every minute, or hour, or day, or whatever.
Comment 8 Gurch 2007-09-21 22:51:54 UTC
No bot is necessary; a couple of hours lag is not a problem.

The point I was trying to make was not whether the purge link was necessary - merely that, for better or for worse, such links are frequently added to prominent pages, no logged-in user thinks twice about it, and that this is undesirable from an anonymous user's point of view, quite apart from any performance issues.

Use of (clearly-labelled as such) purge links in places such as the speedy deletion category on the English Wikipedia is quite justified, but if the current situation for anonymous users is going to persist, work needs to be done to eliminate any frivolously-appended "&action=purge" strings. That's off-topic here, of course, but the more people bear it in mind, the better. :)
Comment 9 Platonides 2007-09-22 13:34:00 UTC
Some of these problems could be fixed by improving Mediawiki:confirm_purge
If instead of saying "Clear the cache of this page?" it said "You're going to clear the cache of this page, forcing it to display the latest version, are you sure?" at leat anons wouldn't be so annoyed.
Comment 10 ais523 2007-09-24 13:32:49 UTC
(In reply to comment #2)
> If you have a better idea that allows any HTTP client to purge the page but
> prevents bots/prefetchers/etc. from doing so, please share it.  The
> intermediate page will not simply be removed with no substitute put in its
> place.

What about putting some JavaScript on the intermediate page to automatically submit the POST request? That will 'remove' the intermediate page for most browser users, but leave it as a barrier to bots because they don't run JavaScript on pages. (For users with JavaScript turned off, it would behave just as it does currently.)
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-09-25 00:25:05 UTC
A reasonable thought.
Comment 12 Gurch 2009-07-06 09:08:57 UTC
Bug 19541, basically same thing as this, wontfix'd with note that requiring confirmation on the purge screen is a feature not a bug, so JavaScript wouldn't be an option. Making the purge message more intelligible would be but that can be done by individual projects, so marking this as wontfix also.

Reminder to everyone not to use "action=purge" in your links if you expect readers of your wiki to be able to follow them.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links