Last modified: 2010-05-15 15:59:48 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 13414 - ArticleSave Hook does not return messages Message if article is new
ArticleSave Hook does not return messages Message if article is new
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2008-03-18 14:20 UTC by joshua bacher
Modified: 2010-05-15 15:59 UTC (History)
1 user (show)

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


Description joshua bacher 2008-03-18 14:20:58 UTC
If you use the ArticleSave hook like follows:


$wgHooks['ArticleSave'][]               = 'test'; // validates the truth of an inline query
function test($text,$user,$text,$summary,$flags, $null, $null2, &$realFlag){      
        return 'fubar';                                            

with the LocalSettings.php enhanced with 


this hook normally prevents that a page will be saved. it will redirect you to the edit page of the article, and 
show up the message 'fubar'. Just try with Sandbox, it should not let you save any page.

But this does not occur if you are triing to save a page that formerly did not exists. On pressing the save button the ArticleSave Hook is triggered in doEdit, but the message that was returned will not show up. Not even the edit form will show up, it will just view a blank not existing Wiki Page that you may edit again then.

I only tested it with MW 1.11
Comment 1 Brion Vibber 2008-03-18 18:30:34 UTC
The return value of a hook must be one of the following:

true -- continue processing

false -- abort processing

Returning a non-empty, non-'0' string will evaluate to true in boolean context, meaning that processing should continue as normal. It will not display a message anywhere.
Comment 2 joshua bacher 2008-03-18 19:15:49 UTC
But then it does behave extremely different in the both cases, right? In one case it prints out a message, the string returned bu the function called through the hook, in the other case it does not return the message and redirect us to the page. 

Comment 3 joshua bacher 2008-03-18 19:22:38 UTC
i made a proof of concept for the but. it's placed at
edit the Sandbox and click save, you will see the message.

after that try:
edit it and click save: No message returned and not redirected to the edit form.

Comment 4 Brion Vibber 2008-03-18 20:29:56 UTC
Ugh, there's some fundamental breakage in how this appears to be handled in the low-level hook code... it seems to be trying to integrate some UI reporting in, which is *WRONG WRONG WRONG*. I strongly recommend against attempting to use that, as it looks like some BADLY obsolete code.

Anyway, you're hooking into low-level page save code which is not guaranteed to be in any useful user interface area in the first place.

You probably want to be hooking into 'EditPage::attemptSave' or 'EditFilter' hooks if you want to be able to interact with a user and abort editing operations at a user-interface level.
Comment 5 joshua bacher 2008-03-18 21:14:29 UTC
Cool, i have tested the EditFilter and it worked just like we need it. Many thanks for the fast reply brion!

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