Manual:RequestContext.php

Details
As of MediaWiki 1.18 the context of a request is encapsulated inside of a "RequestContext" instance.

The RequestContext contains the following members:
 * the WebRequest to fetch request variables from.
 * the Title instance for the page being outputted.
 * a OutputPage tied to the RequestContext for sending page output to.
 * the Skin class instance being used to render the page.
 * the instance of User for the user the page is rendered for.
 * the Language instance of the user language the page is rendered in.

The output and lang are read-only, the rest of the RequestContext may be set. You can access and modify the RequestContext using properties, property setting , get methods , and set methods.

Working with Request Contexts
You can access the main request context using  however this should be a last resort. Most cases where you plan to do something with request context data should have access to it's own context data, you should use that, not the main RequestContext instance or $wg globals.


 * When writing a SpecialPage
 * You have access to the context through
 * SpecialPage also implements a number of helpers:
 * You can use  for the title of the SpecialPage and   for the title of the special page and any $par data.
 * SpecialPages are meant to be executable in alternate contexts so extensions should start moving away from the use of $wg's. We may drop support for includable special pages using $wg request context related variables around MW 1.20.
 * You can use  for the title of the SpecialPage and   for the title of the special page and any $par data.
 * SpecialPages are meant to be executable in alternate contexts so extensions should start moving away from the use of $wg's. We may drop support for includable special pages using $wg request context related variables around MW 1.20.
 * You can use  for the title of the SpecialPage and   for the title of the special page and any $par data.
 * SpecialPages are meant to be executable in alternate contexts so extensions should start moving away from the use of $wg's. We may drop support for includable special pages using $wg request context related variables around MW 1.20.


 * When writing skin code
 * You have access to the context through
 * Skin also implements a number of helpers:
 * The skin context is entered by  which is called by   external access to context sensitive method calls should be avoided.
 * The skin context is entered by  which is called by   external access to context sensitive method calls should be avoided.
 * The skin context is entered by  which is called by   external access to context sensitive method calls should be avoided.


 * When using hooks
 * If your hook provides a OutputPage make use of the context provided by it.
 * If your hook is executed within the  page outputting context, and is provided a Skin instance, make use of the context provided by it.
 * If your hook provides a Title instance, use it as a preference to other context.
 * Same goes for any WebRequest instances provided as arguments to hooks.
 * Make sure you are using the right hook, if proper context is not provided then you may be using a hook for the wrong purpose and may run into unrelated bugs.
 * However some hooks may be out of date and need to be provided with a proper context inside of their arguments.


 * When writing parser functions and hooks
 * Parser functions and hooks should not be accessing request context data.
 * Make use of the ParserOptions for anything you do need like the user lang.
 * Use the Linker:: class statically instead of accessing the Skin.

Creating new Request Contexts
There is still code making use of the global $wgOut, $wgTitle, and $wgUser variables, till those are eliminated we cannot expect custom contexts to work perfectly and will need to keep the same workarounds, however in the future if we fix code to stop using those globals something like this should be a possibility:

Using the linker alone
If your extension needs 1.18 compat and you want to use linker methods this trick can get you a linker instance you can use: Now instead of using a skin instance to access the linker just use $linker->, and you'll be able to update to Linker:: when you drop pre-1.18 compatibility.