Manual:Writing maintenance scripts

This is a step-by-step tutorial on writing a maintenance script based on the   class (see ) which was introduced in MediaWiki 1.16 to make it easier to write command-line MediaWiki maintenance scripts.

Example script
We'll walk through a  maintenance script that simply prints “Hello, World”. This program contains the minimum amount of code needed to run as well as the expected copyright header (for alternative headers, see headers>Special:MyLanguage/copyright headers|copyright headers):

The program will just print out “Hello, World!” but already has a  (and other command line options). Sample output:

 $ php helloWorld.php Hello, World! $ php helloWorld.php --help

Usage: php helloWorld.php [--conf|--dbgroupdefault|--dbpass|--dbuser|--globals|--help|--memory-limit|--mwdebug|--profiler|--quiet|--server|--wiki]

Generic maintenance parameters: --help (-h): Display this help message --quiet (-q): Whether to suppress non-error output --conf: Location of LocalSettings.php, if not default --wiki: For specifying the wiki ID   --globals: Output globals at the end of processing for debugging --memory-limit: Set a specific memory limit for the script, "max" for no limit or "default" to avoid changing it   --server: The protocol and server name to use in URLs, e.g.        https://en.wikipedia.org. This is sometimes necessary because server name detection may fail in command line scripts. --profiler: Profiler output format (usually "text") --mwdebug: Enable built-in MediaWiki development settings

Script dependant parameters: --dbuser: The DB user to use for this script --dbpass: The password to use for this script --dbgroupdefault: The default DB group to use.

$

An overview:


 * We include .  This defines the   which has method to parse arguments, read the console, get the database, etc.  It is best to use the full path to.


 * We extend the Maintenance class and then, with


 * tell the Maintenance class to run the script using our  class, only if being executed from the command line.  Internally,   loads another file  which autoloads MediaWiki classes and configuration, and then


 * The  function that we've defined is executed, and our script does its work.

Adding a description
"But what is this maintenance script for?" I can hear you asking.

We can put a description at the top of the " " output by using the   method in our constructor:

The output now gives us the description:

$ php helloWorld.php --help

Say hello.

Usage: php helloWorld.php [--conf|--dbgroupdefault|--dbpass|--dbuser|--globals|--help|--memory-limit|--mwdebug|--profiler|--quiet|--server|--wiki] …

Option and argument parsing
Greeting the world is all well and good, but we want to be able to greet individuals, too.

To add a command-line option, add a constructor to  that calls  's   and update the   method to use the new option. 's parameters are, so:

This time, when executed, the output of the  script changes depending on the argument provided:

 $ php helloWorld.php Hello, World! $ php helloWorld.php --name=Mark Hello, Mark! $ php helloWorld.php --help

Say hello.

Usage: php helloWorld.php [--conf|--dbgroupdefault|--dbpass|--dbuser|--globals|--help|--memory-limit|--mwdebug|--name|--profiler|--quiet|--server|--wiki] … Script specific parameters: --name: Who to say Hello to

Extensions
If your maintenance script is for an extension, then you should add a requirement that the extension is installed:

Mostly this provides a nice error message when the extension is not enabled on that wiki (likely on wiki farms). This will only work for extensions that use </>.

Be aware that classes defined by your extension will not be available until hitting the execute-function. Attempts to create instances prior to this, e.g. in the constructor, will cause class not found exceptions.

Writing tests
It's recommended to write tests for your maintenance scripts, like with any other class. See the 1>Manual:PHP unit testing/Writing unit tests#Maintenance scripts</>|Maintenance scripts guide for help and examples.