Last modified: 2010-05-15 15:59:48 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T15414, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 13414 - ArticleSave Hook does not return messages Message if article is new
ArticleSave Hook does not return messages Message if article is new
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.11.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  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: ---


Attachments

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

extensions/test.php

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

with the LocalSettings.php enhanced with 

include('extensions/test.php');

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 
http://jemb.eu/mediawiki/index.php?title=Sandbox
edit the Sandbox and click save, you will see the message.

after that try:
http://jemb.eu/mediawiki/index.php?title=IAmANotExistingPage
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.


Navigation
Links