Last modified: 2014-04-19 16:12:39 UTC
I'm not sure why the purge action exists in MediaWiki. From a design perspective and from a user experience perspective, it feels like an ugly hack. It has no user interface exposure currently, as far as I remember. I wonder if the purge action should continue to exist. Some part of me thinks that its continued existence simply obfuscates or marginalizes real, underlying issues.
Prior to the purge action users used null edits to perform the same act. Some additions like SMW, a Purge extension, and iirc user scripts do expose it in the UI. It can also be exposed by in-content links like those on most Forum:Index pages made by DPLForum users and Wikipedia template pages. The purge action has valid use in cases where the 'underlying [reason]' for the purge use has an explicit reason it won't be 'fixed'. Purge resets the parser cache for a single page. This has results like viewing the page with any template modifications. In this kind of situation the parser cache is not instantly purged for an explicit reason. The single page in question is actually one of potentially hundreds needing the exact same purge.
In some ways, I feel like the purge action is the red-headed step child of MediaWiki actions. Is it exposed anywhere in MediaWiki core currently? (In reply to comment #1) > Some additions like SMW, a Purge extension, and iirc user scripts do expose > it in the UI. It can also be exposed by in-content links like those on most > Forum:Index pages made by DPLForum users and Wikipedia template pages. Why is the action exposed? When/why does it become necessary? > The purge action has valid use in cases where the 'underlying [reason]' for > the purge use has an explicit reason it won't be 'fixed'. Purge resets the > parser cache for a single page. This has results like viewing the page with > any template modifications. In this kind of situation the parser cache is not > instantly purged for an explicit reason. Human effort is more costly, I promise, especially when you first have to figure out that purging is even an option (how would any typical user know that?) and then purge the page (giving you a page that looks like the current page is supposed to look). There's an overall design defect here, I think.
(In reply to comment #2) > In some ways, I feel like the purge action is the red-headed step child of > MediaWiki actions. Is it exposed anywhere in MediaWiki core currently? > > (In reply to comment #1) > > Some additions like SMW, a Purge extension, and iirc user scripts do expose > > it in the UI. It can also be exposed by in-content links like those on most > > Forum:Index pages made by DPLForum users and Wikipedia template pages. > > Why is the action exposed? When/why does it become necessary? It's exposed by DPLForum and SMW users due to outputting pattern-based lists of pages. Something which is extremely difficult to subscribe to updates for. We could create an event/subscribe system that would make it easier for extensions to listen for complex changes. But even if we do that it won't eliminate the job queue delay and users will still have a reason to use purge. > > The purge action has valid use in cases where the 'underlying [reason]' for > > the purge use has an explicit reason it won't be 'fixed'. Purge resets the > > parser cache for a single page. This has results like viewing the page with > > any template modifications. In this kind of situation the parser cache is not > > instantly purged for an explicit reason. > > Human effort is more costly, I promise, especially when you first have to > figure out that purging is even an option (how would any typical user know > that?) and then purge the page (giving you a page that looks like the current > page is supposed to look). Readers do not need to figure out how to purge. Serving slightly out of date templates to readers till the job queue catches up is fine. &action=purge on normal articles is used typically by template authors. Doing complex things with lots of in-knowledge about MW and purging the cache on a single page to test that their modifications look right after they've finished. > There's an overall design defect here, I think.
It *is* an ugly hack, and it's not meant to be exposed to end-users. Any time people feel the need to use action=purge, it's because MediaWiki failed to properly handle updates to page contents (usually because of some feature that's not compatible with the parser cache, sometimes because of software updates that don't clear the parser cache).
MZMcBride: When would this bug be "evaluated", so action could take place? So far it feels like this discussion should happen on a mailing list instead of a bugtracker, because this ticket is far from being actionable. If there's consensus a bug report could be filed that defines problems that were agreed on.
null edit is not the same than a simple purge. null edit also refreshed the database tables (like categorylinks and so on). With api purge and param forcelinkupdate you can reach that also. Along with the job queue and new features (core software update or a new installed extension), bug 18478 is also a reason to do a purge.
(In reply to comment #5) > MZMcBride: When would this bug be "evaluated", so action could take place? Looks like one of Wikimedia's (or MediaWiki's) architects confirmed that the purge action is a hack in comment 4. :-) Any hack should eventually be killed (I believe that's the nature of a hack). If we're not going to expose the purge action in the user interface, I think we should work toward deprecating it.
It would be nice if this purging wasn't needed at all. There's a gadget specifically for this at the english wikipedia [1] and probably several other wikipedias as well. IIRC, whenever a highly used template is changed at the english wikipedia, bots are used to purge all pages where the template was used. [1]: https://en.wikipedia.org/wiki/MediaWiki:Gadget-purgetab.js
I guess it needs some clarification that "purge action" here refers to index.php?action=purge and/or api.php?action=purge ?
(In reply to Liangent from comment #9) > I guess it needs some clarification that "purge action" here refers to > index.php?action=purge and/or api.php?action=purge ? Probably both. Is there a good reason to have either?
(In reply to MZMcBride from comment #10) > Probably both. Is there a good reason to have either? api.php?action=purge can do more than index.php?action=purge - the "force[recursive]linkupdate" parameter. Assume we have a page containing [[Category:{{CURRENTTIMESTAMP}}]]. Maybe we can deprecate the "parser cache clearing action" by postprocessing parser output or simply disabling parser cache, but I don't think we'll find a way to update the categorylinks row every second. In this case a "link updating action" is still needed. The equivalent thing on index.php is a null edit.
(In reply to Liangent from comment #11) > (In reply to MZMcBride from comment #10) >> Probably both. Is there a good reason to have either? > > api.php?action=purge can do more than index.php?action=purge - the > "force[recursive]linkupdate" parameter. Why are these options necessary? Which use-cases is the API purge action and its additional parameters solving? > Assume we have a page containing [[Category:{{CURRENTTIMESTAMP}}]]. Maybe we > can deprecate the "parser cache clearing action" by postprocessing parser > output or simply disabling parser cache, but I don't think we'll find a way > to update the categorylinks row every second. In this case a "link updating > action" is still needed. The equivalent thing on index.php is a null edit. Null edits should not be necessary. There are many ideas to explore here. For example, we could make purging more probabilistic by purging pages (including links updates0 every thousandth or millionth view.
(In reply to Liangent from comment #11) > api.php?action=purge can do more than index.php?action=purge - the > "force[recursive]linkupdate" parameter. This reminds of me the "don't leave a redirect" functionality when moving a page. The functionality was originally added only to the API's move action and eventually it was declared that API functionality and UI (index.php) functionality at Special:MovePage should not intentionally diverge like this. That is, index.php?action=purge should probably include the force[recursive]linkupdate parameter as well. Or that parameter should be removed from both, depending on its justification and utility.
Null edits shouldn't be needed but there are several bugs that have been open for a long time, in fact one that I ran into on my private wiki has been open and unresolved for over two years. Until such a time as the purge action is no longer needed it should remain.
(In reply to Betacommand from comment #14) > Null edits shouldn't be needed but there are several bugs that have been > open for a long time, in fact one that I ran into on my private wiki has > been open and unresolved for over two years. Until such a time as the purge > action is no longer needed it should remain. Yeah I can remember some of them. Is there a full list (a tracking bug?) somewhere?
(In reply to Betacommand from comment #14) > Until such a time as the purge action is no longer needed it should remain. Indeed. I think the focus should be slow deprecation and eventual removal. (In reply to Liangent from comment #15) > Yeah I can remember some of them. Is there a full list (a tracking bug?) > somewhere? This bug report may become a tracking bug.
In my experience, one of the most common reasons to use purge is post infrastructure failures (the purge feed between main and caching centers has been down), causing inconsistencies. In other cases, it's almost always cached 'time dependent' content. The category with speedy deletes not updating quick enough to the wikignomes liking (job queue). Or calculated ages of article subjects for instance, that are no longer up to date (because calculations are cached, which for time based content, is thus inherently broken). If we don't want to sacrifice flexibility and want to keep caching at the same time, I would say that calculations based on time could have cache invalidation timers associated with it. (more ugliness, but doable/manageable in Lua I think).
