page is saved. A wiki page is deleted. Often there are two events
associated with a single action: one before the code is run to make the
event happen, and one after. Each event has a name, preferably in
- CamelCase. For example, 'UserLogin', 'ArticleSave', 'ArticleSaveComplete',
- 'ArticleDelete'.
+ CamelCase. For example, 'UserLogin', 'PageContentSave',
+ 'PageContentSaveComplete', 'ArticleDelete'.
hook
A clump of code and data that should be run when an event happens. This can
The extra data is useful if we want to use the same function or object for
different purposes. For example:
- $wgHooks['ArticleSaveComplete'][] = array( 'ircNotify', 'TimStarling' );
- $wgHooks['ArticleSaveComplete'][] = array( 'ircNotify', 'brion' );
+ $wgHooks['PageContentSaveComplete'][] = array( 'ircNotify', 'TimStarling' );
+ $wgHooks['PageContentSaveComplete'][] = array( 'ircNotify', 'brion' );
This code would result in ircNotify being run twice when an article is saved:
once for 'TimStarling', and once for 'brion'.
'getUserPermissionsErrors': Add a permissions error when permissions errors are
checked for. Use instead of userCan for most cases. Return false if the user
can't do it, and populate $result with the reason in the form of
-array( messagename, param1, param2, ... ). For consistency, error messages
+array( messagename, param1, param2, ... ) or a MessageSpecifier instance (you
+might want to use ApiMessage to provide machine-readable details for the API).
+For consistency, error messages
should be plain text with no special coloring, bolding, etc. to show that
they're errors; presenting them properly to the user as errors is done by the
caller.
called only if expensive checks are enabled. Add a permissions error when
permissions errors are checked for. Return false if the user can't do it, and
populate $result with the reason in the form of array( messagename, param1,
-param2, ... ). For consistency, error messages should be plain text with no
+param2, ... ) or a MessageSpecifier instance (you might want to use ApiMessage
+to provide machine-readable details for the API). For consistency, error
+messages should be plain text with no
special coloring, bolding, etc. to show that they're errors; presenting them
properly to the user as errors is done by the caller.
$title: Title object being checked against