Last modified: 2010-05-15 15:54:53 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 13689 - Add a new parameter to Article::purge() to prevent output
Add a new parameter to Article::purge() to prevent output
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.12.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Brion Vibber
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-11 04:18 UTC by John Smith
Modified: 2010-05-15 15:54 UTC (History)
3 users (show)

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


Attachments

Description John Smith 2008-04-11 04:18:48 UTC
This is low priority. I have already fixed this on my wiki.

Basically what I am suggesting is to add a new parameter to functions purge and doPurge in class Article in Article.php.

The problem is:
By default, the purge function outputs the article text to the page, because it was designed to be called directly on the page it's purging.

But, if one wants to purge certain pages from an extension using $articleobj->purge(), it isn't possible with the current set up without adding to the output.

Technically, someone could just use the MessageCache directly, but what if someone changes any code in the MessageCache? It would break extensions relying on this. Article::Purge() is a much better way to go for extensions.

This is what needs to be changed:

at the purge function definition:
	function purge($show=true) {
and then at the "doPurge()" call inside the first IF:
	$this->doPurge($show);
and then at the "} else {" where it adds the confirmation button:
	} elseif($show) {
and then at the doPurge definition:
	function doPurge($show=true) {
and then at the "view()" call at the end of doPurge:
	if($show) $this->view();
Comment 1 Roan Kattouw 2008-04-11 09:59:22 UTC
Why don't you call $wgOut->disable(); just before the purge() call and re-enable it afterwards?
Comment 2 Brion Vibber 2008-04-11 19:31:50 UTC
Article::purge() is a wiki action handler, which handles action=purge.

What's probably the right thing to do here is to move the $this->view() call from Article::doPurge() back a level to Article::purge().
Comment 3 Siebrand Mazeland 2008-08-18 22:11:49 UTC
Assigned: brion, as he appears to have a quick solution and the overview.
Comment 4 Chad H. 2008-08-18 22:21:37 UTC
Done in r39619. Used Brion's suggestion to move $this->view() up a level. Passing false to Article::purge() suppresses said output.
Comment 5 Brion Vibber 2008-08-19 19:00:26 UTC
Reverted in r39654.

Article::purge() is a UI action entry point, not a backend method. Backend-only parameters aren't appropriate here; instead a method suitable for backend usage should be created (and/or in an ideal world, we should finish splitting Article backend stuff from UI frontend as separate classes)
Comment 6 Chad H. 2008-08-19 19:17:51 UTC
Refixed in r39656.

Calling Article::doPurge() now lets the backend do a purge without output (and doesn't turn Article::purge() into a UI and backend entry, which is good)

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


Navigation
Links