* 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)

Hi all, I'm finding myself making calls to the live api on the wmf wikis and thinking: Writing the query from scratch for every detail (or copying it from the bits and pieces in mw source code) for every time I need the data is nonsense since it was already done..... in mediawiki core. MediaWiki uses the API internally as well in some places (more in extensions) with a FauxRequest (which is calling the api without a real http request). From a server hosting a live MediaWiki-site it's very easy (php include includes/WebStart.php anad make a FauxRequest() - one can make several requests all without making a http request ). However from the toolserver it's a little trickier since we're not on the same server. 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) 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> This should basically be includable by anyone so that not everybody has to re-do this. ie. it could be in /home/somebody/wmf-api/includes/WebStart.php which would be a checkout of the wmf-branch in SVN and (maybe) the same extensions etc. This will make it a lot easier to interact with the database when you need certain information, this will also prevent us from hardcoding names all the time (which I'm sure happends a lot and this is one of the causes some tools brake over time when just small details changed). I believe some of the toolserver users already have parts of mediawiki in their home (I imagine stuff like GlobalFunctions.php can be very handy at times). Basically I'm asking three things: * Has this been done already ? If so, we should document this better as I spent time looking for it but came up empty * Do we want this ? Are there potential problems here, what do we need to tackle or fix on our side ? * Who would want to do this ? (If nobody has plans for this already, I would like to do this) -- Krinkle _______________________________________________ Toolserver-l mailing list (Toolserver-l(a)lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette

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)

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>