Blog of Auzigog

I’m in the process of writing mediawiki2wordpress—a plugin to allow WordPress to access and display content from a MediaWiki installation. I spent a bit of the evening figuring out how to get MediaWiki to let me trick it into thinking I was making a standard request.

The method I explain here gives you access to the MediaWiki API class as opposed to the standard MediaWiki rendering class. Most of this code came from MediaWiki’s api.php which you can find in MediaWiki 1.13.

Here’s what the API output will look like for the Foobar page on Wikipedia (in XML).

I spent quite a bit of time poking around in the MediaWiki /includes directory and trying different hack-ish methods before this page that had exactly what I needed! It did need updating, but I was happy to oblige. I even had this whole post written up using a sloppier approach before finding the FauxRequest class that I explain below.

The code

Let’s start with the sample code, then go over the details.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$mediawiki_root = '/Users/eyeRmonkey/www/mediawiki-test';
putenv("MW_INSTALL_PATH=$mediawiki_root");
// Initialise common code
require ($mediawiki_root . '/includes/WebStart.php');
 
class MediaWikiAPIWrapper {
	public function make_fake_request($params) {
		$request = new FauxRequest($params, true);
 
		$api = new ApiMain($request);
 
		// Process data & use an output buffer to capture the resutls
		$api->execute();
		$result = $api->getResult();
		$data = &$result->getData();
 
		return $data;
	}
}

Initializing

The first matter of business is lines 1 through 4. These need to be called outside of any function or class. I spent some time trying to figure out why none of MediaWiki’s global variables were showing up in print_r($GLOBALS) before thinking to require_once() it outside of any functions. Duh. Make sure you get the path to your MediaWiki installation root correct (no trailing slash, obviously).

Most of the work get’s done on line 4. This get’s all the code ready for a standard API call from the web. This whole approach is meant to be used by an extension, so we need to play catchup by initializing the core MediaWiki code.

Faking the Request

The good folks at MediaWiki were are kind enough to provide us with a class specifically meant for faking an API request! Joy! It’s called FauxRequest and it extends the WebRequest object that is used by default for API calls. The FauxRequest class takes an array of keys and values that represent what would’ve been passed in the URL.

The API manual has more information on formats and different queries you can make to the API.

Here is what your $params array might look like to grab the Main Page:

$data = array(
		'action' => 'parse',
		'page' => 'Main_Page'
	);

Running the API

Lines 10 through 15 create an instance of the API and pass in our FauxRequest object to get things rolling!

The $data array will hold all of the information that you would get from a format=php API call. As always, you could use print_r() to display the Array for debugging purposes.

That’s it!

mod_rewrite Issues

On my wiki, the .htaccess mod_rewrite rules that I have seem to be preventing the API from functioning totally correctly. A workaround I discovered is to use the following API call: /api.php?action=parse&title=Main_Page&text={{:Main_Page}}. This works by asking the API to translate the text parameter into rendered text. The {{:Main_Page}} says that the text is actually a transclusion-ed page. It’s definitely a hack, but it works on servers with weird rewrite rules for pretty URLs.

Further reading

• API: Query Properties
• API: Expanding templates and rendering - Relevant to the transclusion workaround.

Featured, Guides, Photography, Programming, Wordpress api, code, guide, mediawiki, plugin, Wordpress