Last modified: 2007-02-05 19:10:54 UTC
I've been having problems with "UserCan" extensions. Digging in the SVN (and my install v1.8.2), I have found that the "null" return code from an extension (i.e. continue processing) is not handled correctly. The code below is from the phase 3 SVN and shows the line "if (!$retval)" whereas both "false" and "null" return codes are handled the same way. From http://www.mediawiki.org/wiki/Manual:MediaWiki_hooks/userCan: "if null is returned then the other things in the hook chain are checked, the result is still undetermined if true is returned then can the user do want he want to do, the result is true if false is returned then the evaluation is aborted and the result is false " Code snippet from Hooks.php --------------------------- /* Call the hook. */ wfProfileIn( $func ); $retval = call_user_func_array( $callback, $hook_args ); wfProfileOut( $func ); /* String return is an error; false return means stop processing. */ if (is_string($retval)) { global $wgOut; $wgOut->showFatalError($retval); return false; } else if (!$retval) { return false; } } return true;
Only true and false are valid return values for hooks, not null.
Then how do you chain extensions that hook themselves on the same trigger point as so they do not step on each others toes too much? A "null" return value would at least enable another state "undetermined" and this would be helpful.
True means "keep running down the chain", false means "cancel further processing". A hook isn't really appropriate for returning a yes/no _answer_, but modifying a passed-by-reference parameter is used for such things.
I see what you mean: the 'userCan' hook chain call in Title.php captures your point. I'll update the documentation on Mediawiki.org. Thanks for your time.
