One of the most common sources of problems for new MediaWiki developers is the cache. Typically, a developer makes a change to some code and then goes to view it in the browser and doesn't see the changes just made. Whenever something is not doing what it is supposed to do, it's a good idea to suspect a cache problem. Developers have two caches to worry about: the browser cache and the MediaWiki cache.

To purge the browser cache, do the following:

To purge the MediaWiki cache, add the purge action to the end of the URL of a file:

/wiki/index.php/Main_Page?action=purge

You can also purge all caches, both browser caches and server-side caches, by setting the value of $wgCacheEpoch in LocalSettings.php to the current date, as illustrated in the following example:

/**
 * Set this to current time to invalidate all prior cached pages. Affects both
 * client- and server-side caching.
 * You can get the current date on your server by using the command:
 *   date +%Y%m%d%H%M%S
 */
$wgCacheEpoch = '20070822000000';

You just learned there are two caches, a browser cache and the MediaWiki cache. That is only partly true. MediaWiki has an aggressive and far-reaching caching strategy embedded in the application and actually has several different kinds of caches caching different things.

In addition to the browser cache, there is a file cache and a collection of object caches.

The HTTP specification defines HTTP headers that are to be used by clients (browsers) to manage their cache. In order to enable client-side caching, the $wgCachePages variable must be set to true (the default):

# Client-side caching:

/** Allow client-side caching of pages */
$wgCachePages       = true;

In order to understand how this changes MediaWiki's behavior, it's helpful to understand how HTTP 1.1 handles caching. What follows is a brief, and not complete, description of the caching process used by browsers so that you will understand how MediaWiki changes response headers when this value is set.

When a browser requests a page, the server's response includes HTTP headers, as well as the page that was requested. The HTTP headers that are sent back to the browser, called the response headers, can contain information that the browser uses to cache the page.

The Expires header is optional; it tells the browser explicitly when to stop caching a page. When a browser makes a request, it first checks to see whether the page is in the cache and if it has an expiration date. If it has expired, then it will check to see whether the page has been modified since the last download. If it has been modified, then it will download a new copy; otherwise, it displays the page in the cache. The following example shows the Expires header:

Expires: Thu, 23 Aug 2007 14:19:41 GMT

The next two response headers are called validators because they are used to determine whether a page has changed and needs to be retrieved from the server, rather than the cache. These response headers are Last-Modified and Etag (shown here):

Last-Modified: Wed, 30 May 2007 01:01:53 GMT
Etag: "655194-9f2f-465ccd01"

When a browser caches a page, it stores this information along with it. The next time it requests the same page, it includes the following request headers, which are used to validate the cache based on the Last-Modified time or the Etag:

If-Modified-Since: Wed, 30 May 2007 01:01:53 GMT
If-None-Match: "655194-9f2f-465ccd01"

In the preceding example, these headers tell the server that if the page has been modified since May 30, 2007 at 1:01:53 GMT, or if the Etag as generated by the server does not match the Etag sent in the If-None-Match header, then a new instance of the page should be sent. Otherwise, it returns a header with the following message:

HTTP/1.x 304 Not Modified

ETags (or entity tags) were introduced in the HTTP 1.1, and they are used in cache management. They are a unique value (or hash) normally created using a file's inode, size, and last modified time. They can be customized using the FileEtag directive (see the Apache HTTPD documentation for more information); and in MediaWiki, the MediaWiki application creates the Etag, using its own formula.

When $wgCachePages is set to True, ETags are used in non-dynamically generated pages, which allows the client to cache those files. If the $wgUseETag variable is set to True in LocalSettings.php, then an ETag is used on dynamically generated pages, too.

In the following request/response example, MediaWiki has been configured to cache files, but has not been configured to use ETags. This is a request for a static file, called SampleImageUpload.png:

GET /mysql/images/b/b5/SampleImageUpload.png HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6)
   Gecko/20070725 Firefox/2.0.0.6
Accept: image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://127.0.0.1/mysql/index.php/Image_links

Despite the fact that MediaWiki has not been configured to use ETags, the response returns an ETag. That's because ETags are generated and sent automatically for static pages. At the most basic level, a file is cached by a browser as long as the Last-Modified value does not change. When this page is requested again, the browser will send an If-Modified-Since request header to the server. If the file has been modified since the modification in the cache, then a new file will be sent:

HTTP/1.x 200 OK
Date: Wed, 22 Aug 2007 23:10:01 GMT
Server: Apache/1.3.33 (Darwin) PHP/5.2.0
Last-Modified: Wed, 30 May 2007 01:01:53 GMT
Etag: "655194-9f2f-465ccd01"
Accept-Ranges: bytes
Content-Length: 40751
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
Content-Type: image/png

In this example, MediaWiki has been configured to cache pages, as well as to use ETags. Because ETags are automatic on static files, our expectation is that ETags will not be used on dynamic pages, such as articles, as well. This is a new page that the browser has not visited before, so the request headers are standard:

http://127.0.0.1/mysql/index.php/A_new_page

GET /mysql/index.php/A_new_page HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6)
   Gecko/20070725 Firefox/2.0.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/
   plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://127.0.0.1/mysql/index.php/Main_Page

When the response headers are returned, however, you see several new header tags, including Etag, Expires, Cache-Control, in addition to the familiar Last-Modified:

HTTP/1.x 200 OK
Date: Wed, 22 Aug 2007 23:11:44 GMT
Server: Apache/1.3.33 (Darwin) PHP/5.2.0
X-Powered-By: PHP/5.2.0
Content-Language: en
Etag: W/"wikidb-profwiki_:pcache:idhash:28-0!1!0!!en!2--20070604224328"
Vary: Accept-Encoding,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
Last-Modified: Wed, 22 Aug 2007 23:11:18 GMT
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

The two items we are most concerned with now are the Etag and Cache-Control response headers. Earlier, this section mentioned the Last-Modified and If-Modified-Since headers. These are examples of validators. When HTTP 1.1 was released, it contained a specification for a new kind of validator called an ETag, which is what we see in this example:

Etag: W/"wikidb-profwiki_:pcache:idhash:28-0!1!0!!en!2--20070604224328"
Cache-Control: private, must-revalidate, max-age=0

It works like this: When the browser requests a file, it is sent back with an ETag, which is stored in the cache along with the file. The Cache-Control header says must-revalidate, which means that it must check the ETag stored in the cache with the new ETag that is sent. If they are the same, then the file hasn't changed and the complete file is transferred. If it has not changed, then HTTP returns with a "304 Not Modified" response.

In the following example, the same page is requested again. The page has already been requested once, so it is in the browser cache. Because caching has been enabled, the If-Modified-Since header, plus a new one, If-None-Match, which you can see in the following example, references the ETag of the file that was just received:

GET /mysql/index.php/A_new_page HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6)
   Gecko/20070725 Firefox/2.0.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/
   plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://127.0.0.1/mysql/index.php/Main_Page
If-Modified-Since: Wed, 22 Aug 2007 23:11:18 GMT
If-None-Match: W/"wikidb-profwiki_:pcache:idhash:28-0!1!0!!en!2--20070604224328"
Cache-Control: max-age=0

Compare the If-None-Match value in the request header with the Etag value in the previous response header—they are both the same. This means the file hasn't changed, so the HTTP server dutifully sends back the appropriate HTTP response:

HTTP/1.x 304 Not Modified
Date: Wed, 22 Aug 2007 23:12:52 GMT
Server: Apache/1.3.33 (Darwin) PHP/5.2.0
Connection: Keep-Alive
Keep-Alive: timeout=15, max=93
Etag: W/"wikidb-profwiki_:pcache:idhash:28-0!1!0!!en!2--20070604224328"
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
Vary: Accept-Encoding, Cookie

The file cache is used only for non-logged in users. It works by caching the contents of the HTML file that MediaWiki produces in response to a request. In order for it to work, you must set the $wgUseFileCache variable to true in LocalSettings.php, and set the $wgShowIPinHeader variable to false. Setting the $wgFileCacheDirectory setting is optional; if it is not set, then MediaWiki will use the default value of {$wgUploadDirectory}/cache. When you do configure the cache directory yourself, you must include a full path to the directory, and you must ensure that the directory is writeable by the Web server:

$wgUseFileCache = true;
$wgFileCacheDirectory = "/tmp/yourcache";
// Setting $wgShowIPinHeader to false removes the
// personal tool links at the top of the page for
// anonymous users, who are identified by their
// IP address. This improves caching by showing
// all anonymous users the same page.
$wgShowIPinHeader = false;

You can also configure MediaWiki to compress the cached files in order to save bandwidth when they are requested. If you do this, you need to disable the ob_gzhandler in LocalSettings.php, like so:

if ( $wgCommandLineMode ) {
 if ( isset( $_SERVER ) && array_key_exists( 'REQUEST_METHOD', $_SERVER ) ) {
         die( "This script must be run from the command line
" );
}
} elseif ( empty( $wgNoOutputBuffer ) ) {
 ## I have commented out the following line to disable it
 #if( !ini_get( 'zlib.output_compression' ) ) @ob_start( 'ob_gzhandler' );
}
$wgUseGzip = false;

More information about the file cache can be found at http://meta.wikimedia.org/wiki/Help:File_cache.

Memcached is a distributed object store that you can run on any number of servers. The primary benefit of being distributed is that it is highly scalable. If you need more caching, just add another memcached server. You do incur some additional overhead because the cached data is retrieved through a TCP/IP connection, but the benefit of having multiple servers, and the ability to share things such as session data across servers, more than makes up for this deficit.

MediaWiki comes with a Memcached client. It is the Memcached client that saves objects into the store and retrieves them using a unique key. Internally, the client knows which of the available memcached servers a given object is stored in, so it can request it directly.

/**
 * Object cache settings
 * See Defines.php for types
 */
$wgMainCacheType = CACHE_NONE;
$wgMessageCacheType = CACHE_ANYTHING;
$wgParserCacheType = CACHE_ANYTHING;

/**#@+
 * Cache type
 */
define( 'CACHE_ANYTHING', −1 );  // Use anything, as long as it works
define( 'CACHE_NONE', 0 );       // Do not cache
define( 'CACHE_DB', 1 );         // Store cache objects in the DB
define( 'CACHE_MEMCACHED', 2 );  // MemCached, must specify servers in
                                 // $wgMemCacheServers
define( 'CACHE_ACCEL', 3 );      // APC, eAccelerator or Turck, whichever is
                                 //available
define( 'CACHE_DBA', 4 );        // Use PHP's DBA extension to store in a DBM-style
                                 //database
/**#@-*/

$wgMainCacheType = CACHE_MEMCACHED;

$wgParserCacheExpireTime = 86400;
$wgSessionsInMemcached = false;
$wgLinkCacheMemcached = false; # Not fully tested

/**
 * Memcached-specific settings
 * See docs/memcached.txt
 */
$wgMemCachedDebug   = false; # Will be set to false in Setup.php,
  if the server isn't working

$wgMemCachedServers = array( '127.0.0.1:11000' );
$wgMemCachedPersistent = false;

$wgMemCachedServers = array( "127.0.0.1:11000" );

$wgMemCachedServers = array(
    "127.0.0.1:11000", # one gig on this box
    array("192.168.0.1:11000", 2 ) # two gigs on the other box
  );

memcached -d -l 127.0.0.1 -p 11000 -m 64

Like Memcached, Alternative PHP Cache (APC) caches PHP objects in memory. The primary distinction is that Memcached is a distributed object store, whereas APC is local to the machine. This means that if you are running a single-server wiki, then APC is probably your best choice. In that context, APC outperforms Memcached because you make Memcached requests through TCP/IP, which is naturally slower than accessing the APC cache.

MediaWiki also supports eAccelerator and Turck MMCache, but this chapter does not cover them in detail. While Turck MMCache is still in use, the open-source project itself is no longer actively maintained. eAccelerator is based on Turck MMCache and is still an actively maintained project, but recent versions have had problems working with PHP. eAccelerator version 0.9.4 doesn't work with PHP 5.1. Version 0.9.5 does work with 5.1, but requires a patch to work with PHP 5.2 in order to avoid a segmentation fault. By all reports, version 0.9.5.1 appears to work fine. Because eAccelerator is finicky about which versions of PHP it runs on, this discussion focuses on Alternative PHP Cache. Not only is it actively maintained, but it works with a variety of versions of PHP so there does not seem to be a compelling reason not to use APC.

More information on the other alternatives can be found here:

$ pecl install AP

;;;;;;;;;;;;;;;;;;;;;;;;;
; Paths and Directories ;
;;;;;;;;;;;;;;;;;;;;;;;;;


; Directory in which the loadable extensions (modules) reside.
extension_dir = "/usr/local/php5/lib/php/extensions/no-debug-non-zts-20060613/"

;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;
;
; If you wish to have an extension loaded automatically, use the following
; syntax:
;
;   extension=modulename.extension
;
; For example, on Windows:
;
;   extension=msql.dll
;

; ... or under UNIX:
;
;   extension=msql.so
;
; Note that it should be the name of the module only; no directory information
; needs to go here.  Specify the location of the extension with the
; extension_dir directive above.

extension=apc.so

$wgMainCacheType = CACHE_ACCEL;
$wgMessageCacheType = CACHE_ ACCEL;
$wgParserCacheType = CACHE_ACCEL G;

$wgParserCacheExpireTime = 86400;

Monitoring APC

When you downloaded APC, the distribution should have included a file called apc.php. Copy this file into the main directory of your MediaWiki installation and configure it. At the very least, you need to assign a new admin password—as long as it is "password," the apc.php script will not return any information. The other configuration options are, as they should be, optional:

////////// BEGIN OF DEFAULT CONFIG AREA //////////////////////////////////////
   /////////////////////

defaults('USE_AUTHENTICATION',1);// Use (internal) authentication - best choice if
                                // no other authentication is available
                                // If set to 0:
                                //  There will be no further authentication. You
                                //  will have to handle this by yourself!
                                // If set to 1:
                                //  You need to change ADMIN_PASSWORD to make
                                //  this work!
defaults('ADMIN_USERNAME','apc'); // Admin Username
defaults('ADMIN_PASSWORD','password'); // Admin Password - CHANGE THIS TO ENABLE!!!
//defaults('DATE_FORMAT', "d.m.Y H:i:s");      // German
defaults('DATE_FORMAT', 'Y/m/d H:i:s');        // US

defaults('GRAPH_SIZE',200);    // Image size

Save the changes you made, and then you can use apc.php to monitor caching (see Figure 11-1). This particular configuration is fine for testing, but you should probably not have this file exposed on a production server.

Figure 11.1. View the apc.php script to monitor APC's caching

Message files are located in the Languages folder of your MediaWiki distribution. According to the MediaWiki developers, they decided that it is faster to load serialized message files from the file system than it is to load it from APC or Memcached. Therefore, they've provided a way to serialize all the message files in the serialized folder.

In order to do this, you need to have GNU make installed. Simply change directories into the serialized folder and type the following at the command line:

make

After running this on OS X, the serialized directory took up 19.8 MB of space.

If true, $wgMiserMode disables database-intensive features. This includes reading special pages marked as expensive from the cache instead of regenerating them every time they are requested:

/** Disable database-intensive features */
$wgMiserMode = false;
$wgAllowSlowParserFunctions = false;

Figures 11-2 and 11-3 show the Special:Statistics page when marked as false and true, respectively.

Figure 11.2. The Special:Statistics page when $wgMiserMode is set to false

Figure 11.3. The Special:Statistics page when $wgMiserMode is set to true

One source of strain on any Web server is spiders. Spiders are software applications that crawl a site in order to make copies of the content on the site, or to index it for a search engine. In many cases you will be more than happy to have your site crawled, but there are also many spiders that you want to block as well.

# robots.txt for http://www.wikipedia.org/ and friends
#
# Please note: There are a lot of pages on this site, and there are
# some misbehaved spiders out there that go _way_ too fast. If you're
# irresponsible, your access to the site may be blocked.
#
# advertising-related bots:
User-agent: Mediapartners-Google*
Disallow: /


#
# Sorry, wget in its recursive mode is a frequent problem.
# Please read the man page and use it properly; there is a
# --wait option you can use to set the delay between hits,
# for instance.
#
User-agent: wget
Disallow: /


# Don't allow the wayback-maschine to index user-pages
#User-agent: ia_archiver
#Disallow: /wiki/User
#Disallow: /wiki/Benutzer

# Friendly, low-speed bots are welcome viewing article pages, but not
# dynamically-generated pages please.
#
# Inktomi's "Slurp" can read a minimum delay between hits; if your
# bot supports such a thing using the 'Crawl-delay' or another
# instruction, please let us know.
#
User-agent: *
Disallow: /w/
Disallow: /trap/
Disallow: /wiki/Special:Random
Disallow: /wiki/Special%3ARandom
Disallow: /wiki/Special:Search
Disallow: /wiki/Special%3ASearch
Disallow: /wiki/Spesial:Search
#ar
Disallow: /wiki/%D8%AE%D8%A7%D8%B5:Search
Disallow: /wiki/%D8%AE%D8%A7%D8%B5%3ASearch
## <snip>
## *at least* 1 second please. preferably more :D
## we're disabling this experimentally 11-09-2006
#Crawl-delay: 1

<meta name="robots" content="noindex">

<meta name="robots" content="index">

<meta name="robots" content="index,follow">
<meta name="robots" content="noindex,follow">
<meta name="robots" content="index,nofollow">
<meta name="robots" content="noindex,nofollow">

<meta name="robots" content="all">
<meta name="robots" content="none">

$wgArticleRobotPolicies = array( 'Main Page' => 'noindex' );

$wgNamespaceRobotPolicies = array( NS_TALK => 'noindex' );

/**
 * If true, external URL links in wiki text will be given the
 * rel="nofollow" attribute as a hint to search engines that
 * they should not be followed for ranking purposes as they
 * are user-supplied and thus subject to spamming.
 */
$wgNoFollowLinks = true;

/**
 * Namespaces in which $wgNoFollowLinks doesn't apply.
 * See Language.php for a list of namespaces.
 */
$wgNoFollowNsExceptions = array();

0 ()
        sitemap-wikidb-profwiki_-NS_0-0.xml.gz
1 (Talk)
        sitemap-wikidb-profwiki_-NS_1-0.xml.gz
6 (Image)
        sitemap-wikidb-profwiki_-NS_6-0.xml.gz
10 (Template)
        sitemap-wikidb-profwiki_-NS_10-0.xml.gz
14 (Category)
        sitemap-wikidb-profwiki_-NS_14-0.xml.gz

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.google.com/schemas/sitemap/0.84">
 <sitemap>
         <loc>sitemap-wikidb-profwiki_-NS_0-0.xml.gz</loc>
         <lastmod>2007-08-22T20:10:21Z</lastmod>
 </sitemap>
 <sitemap>
         <loc>sitemap-wikidb-profwiki_-NS_1-0.xml.gz</loc>
         <lastmod>2007-08-22T20:10:21Z</lastmod>
 </sitemap>
 <sitemap>
         <loc>sitemap-wikidb-profwiki_-NS_6-0.xml.gz</loc>
         <lastmod>2007-08-22T20:10:21Z</lastmod>
 </sitemap>
 <sitemap>
         <loc>sitemap-wikidb-profwiki_-NS_10-0.xml.gz</loc>
         <lastmod>2007-08-22T20:10:21Z</lastmod>
 </sitemap>
 <sitemap>
         <loc>sitemap-wikidb-profwiki_-NS_14-0.xml.gz</loc>
         <lastmod>2007-08-22T20:10:21Z</lastmod>
 </sitemap>
</sitemapindex>

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.google.com/schemas/sitemap/0.84">
 <url>
         <loc>http://localhost/mysql/index.php/ASamplePage</loc>
         <lastmod>2007-07-12T19:30:33Z</lastmod>
         <priority>1.0</priority>
 </url>
 <url>
         <loc>http://localhost/mysql/index.php/A_new_page</loc>
         <lastmod>2007-06-04T22:43:28Z</lastmod>
         <priority>1.0</priority>
 </url>
</urlset>

php generateSitemap.php choate.info

?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.google.com/schemas/sitemap/0.84">
 <url>
         <loc>http://choate.info/mysql/index.php/ASamplePage</loc>
         <lastmod>2007-07-12T19:30:33Z</lastmod>
         <priority>1.0</priority>
 </url>
 <url>
         <loc>http://choate.info/mysql/index.php/A_new_page</loc>
         <lastmod>2007-06-04T22:43:28Z</lastmod>
         <priority>1.0</priority>
 </url>
</urlset>

php generateSitemap.php --help

Usage: php generateSitemap.php [host] [options]
        host = hostname
        options:
                --help  show this message
                --fspath        The file system path to save to, e.g /tmp/sitemap/
                --path  The http path to use, e.g. /wiki
                --compress=[yes|no]     compress the sitemap files, default yes

Sitemap: sitemap.xml

You should first configure AdminSettings.php before running any maintenance scripts. It can be found in the base directory of your MediaWiki installation.

<?php
/**
 * This file should be copied to AdminSettings.php, and modified
 * to reflect local settings. It is required for the maintenance
 * scripts which run on the command line, as an extra security
 * measure to allow using a separate user account with higher
 * privileges to do maintenance work.
 *
 * Developers: Do not check AdminSettings.php into Subversion
 *
 * @package MediaWiki
 */

/*
 * This data is used by all database maintenance scripts
 * (see directory maintenance/). The SQL user MUST BE
 * MANUALLY CREATED or set to an existing user with
 * necessary permissions.
 *
 * This is not to be confused with sysop accounts for the
 * wiki.
 */
$wgDBadminuser      = 'wikiadmin';
$wgDBadminpassword  = 'adminpass';
/*
 * Whether to enable the profileinfo.php script.
 */
$wgEnableProfileInfo = false;

?>

While you can perform backups of data in MySQL or Postgres, just as you would any other database, MediaWiki also provides an XML dump of the data in the database, which has the advantage of not containing any kind of user passwords or other sensitive data that a database dump would have. It also can be used to import into future versions of MediaWiki. While the database tables may change, the MediaWiki developers intend to support the XML format into the future.

The schema for the XML format can be found at www.mediawiki.org/xml/export-0.3.xsd, and this is the same format used by the Special:Export and Special:Import pages.

The dumpBackup.php script takes the following options:

This script dumps the wiki page database into an XML interchange wrapper
format for export or backup.

XML output is sent to stdout; progress reports are sent to stderr.

Usage: php dumpBackup.php <action> [<options>]
Actions:
  --full      Dump complete history of every page.
  --current   Includes only the latest revision of each page.
Options:
  --quiet     Don't dump status reports to stderr.
  --report=n  Report position and speed after every n pages processed.
              (Default: 100)
  --server=h  Force reading from MySQL server h
  --start=n   Start from page_id n
  --end=n     Stop before page_id n (exclusive)
  --skip-header Don't output the <mediawiki> header
  --skip-footer Don't output the </mediawiki> footer
  --stub      Don't perform old_text lookups; for 2-pass dump

Fancy stuff:
  --plugin=<class>[:<file>]   Load a dump plugin class
  --output=<type>:<file>      Begin a filtered output stream;
                              <type>s: file, gzip, bzip2, 7zip
  --filter=<type>[:<options>] Add a filter on an output branch

To get a full dump of the data, enter the following command (on Unix-like systems). The data is sent to standard output, so you can redirect standard output into a file test-xml-dump.xml:

php ./dumpBackup.php --full > test-xml-dump.xml

The root element in the XML document is <mediawiki>:

<mediawiki xmlns="http://www.mediawiki.org/xml/export-0.3/"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.mediawiki.org/xml/export-0.3/
   http://www.mediawiki.org/xml/export-0.3.xsd" version="0.3" xml:lang="en">
<!-- Body goes here-->
</mediawiki>

The rest of the XML output is divided into two sections. The first section, which is wrapped in the <siteinfo> tag, contains basic information about the site, including the list of namespaces:

<siteinfo>
    <sitename>ProfWikis - MySQL</sitename>
    <base>http://localhost/mysql/index.php/Main_Page</base>
    <generator>MediaWiki 1.9.3</generator>
    <case>first-letter</case>
      <namespaces>
      <namespace key="-2">Media</namespace>
      <namespace key="-1">Special</namespace>
      <namespace key="0" />
      <namespace key="1">Talk</namespace>
      <namespace key="2">User</namespace>
      <namespace key="3">User talk</namespace>
      <namespace key="4">ProfWikis - MySQL</namespace>

<namespace key="5">ProfWikis - MySQL talk</namespace>
      <namespace key="6">Image</namespace>
      <namespace key="7">Image talk</namespace>
      <namespace key="8">MediaWiki</namespace>
      <namespace key="9">MediaWiki talk</namespace>
      <namespace key="10">Template</namespace>
      <namespace key="11">Template talk</namespace>
      <namespace key="12">Help</namespace>
      <namespace key="13">Help talk</namespace>
      <namespace key="14">Category</namespace>
      <namespace key="15">Category talk</namespace>
    </namespaces>
  </siteinfo>

The rest of the document is a series of <page> tags. Each <page> tag contains all the revisions of that page if the --full option was used, or only the most recent revision if --current was used. The following sample shows output for a page with two revisions:

<page>
    <title>Main Page</title>
    <id>1</id>
    <restrictions>edit=autoconfirmed:move=autoconfirmed</restrictions>
    <revision>
      <id>1</id>
      <timestamp>2007-04-10T14:37:02Z</timestamp>
      <contributor>
        <ip>MediaWiki default</ip>
      </contributor>
      <text xml:space="preserve">&lt;big&gt;'''MediaWiki has been
   successfully installed.'''&lt;/big&gt;

Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for
   information on using the wiki software.

      </text>
    </revision>
    <revision>
      <id>2</id>
      <timestamp>2007-04-10T14:39:17Z</timestamp>
      <contributor>
        <ip>192.168.1.10</ip>
      </contributor>
      <comment>/* Getting started */</comment>
      <text xml:space="preserve">&lt;big&gt;'''MediaWiki has been
   successfully installed.'''&lt;/big&gt;

Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for
   information on using the wiki software.

Welcome to my new wiki, for my book [[Professional Wikis]].</text>
    </revision>
</page>

Files in this XML format can be imported using the importDump.php script in the maintenance directory. The best way to run it is to test it with the --dry-run option, as shown in the following example:

./importDump.php --dry-run test-xml-dump.xml

This will tell you whether there are any problems importing the data, but it won't actually import the data. Once you are sure you want to import it, you execute the script without the --dry-run option:

./importDump.php test-xml-dump.xml