Ilmari Karonen wrote:
On 02/06/2011 12:42 AM, Krinkle wrote:
So I was thinking :
- upload a mediawiki install (the same version that WMF runs, ie.
1.16wmf4 or 1.17wmf1)
- make it not publically accessable (we don't want people actually
browsing the wiki)
- Configure it in a special way so that one can use the same code for
any wiki (ie. a $lang and $family variable of some kind)
So you basically want to set up an internal copy of MediaWiki core so that it can run on the Toolserver databases in read-only mode, and provide a wrapper so that it can be conveniently accessed from PHP code?
That sounds potentially very useful, at least for people who write their tools in PHP.
Then one can include includes/WebStart.php, and use the API (ie. using the huge library of quiries already in the MediaWiki core (ie. action=query&list=categorymembers, using generators and getting properties, you name it) like this:
<source> $site = 'wikipedia'; $lang = 'en'; require( $mw_root . '/includes/WebStart.php' ); // loads all common code including LocalSettings.php // LocalSettings contains extra code to check for $site and $lang figuring out the correct $wgDBname, // $wgDBserver etc. a tiny bit like wmf's CommonSettings.php
$apiRequest = array( 'action' => 'query', 'list' => '...', /* etc. */ ); /* etc. */
</source>
On the other hand, I'm not sure why you'd want to do that. Calling the API internally via FauxRequest is basically a huge kluge. I suppose it may sometimes be the easiest way to get a particular job done, but it's not really the first (or even second or third) solution I'd consider.
Most of the time, if you have direct access to the MediaWiki core classes, you really should just use them directly.
-- Ilmari Karonen
Yes indeed. FauxRequest is just one of the examples possible when having a internally working version of wmf-deployment on Toolserver.
Ofcourse using any other classes is just as easy and is probably a better idea.
-- Krinkle