MediaWikiLite
The idea of MediaWikiLite is to allow the current MediaWiki codebase to run as a standalone server without requiring a database server or web-server. This forms the foundation for a number of alternative uses for the MediaWiki software in enviroments where the current LAMP architecture is too resource intensive.
- Personal wiki: Personal desktop wiki's are becoming very popular, but they do not use the MediaWiki parser, and making a fork of the parser code defeats the purpose.
- Embedded devices such as PDA's, iPod's and iPhone's can only run lite applications effectively and getting MediaWiki onto them would be very useful, especially if it's designed to synchronise with a web-based mirror when an internet connection is available.
- PeerPedia: A lite version of MediaWiki is required to make it a possible candidate for a client side wiki interface to a P2P article space.
This extension creates a new database subclass which allows a MediaWiki to work from an SQLite database instead of MySQL. MySQL is good for large centralised sites serving many clients, but we'd like MediaWiki to be able to run on small local systems such as iPods or iPhones. MySQL is the main obstacle preventing us from creating a light-weight MediaWiki install which would also be a big step towards our Peerpedia idea.
Contents
Replacing the Web Server
This may require FastCGI or a similar alternative because there is problems with functions such as header() which have no effect when running from command line but the function still exists so it can't be replaced. Unless there's some way of overriding built-in functions, this may not be possible.
NanoWeb looks like a good solution for the this. It's a web-server entirely written in PHP and comes with a number of modules such as a ReWrite clone. It can execute CGI scripts using a normal CGI module or a FastCGI module. Also the modules looks very easy to write so a module specifically designed to maintain a MediaWiki instance in memory could be written.
SQLite Installation
It's important to have this working with SQLite3 rather than 2 because version 3 supports more similar syntax for some SQL such as table creation than version 2. Aside from that, version 3 uses more compact files and executes more efficiently. SQLite3 works via PHP's PDO functions.
- To install SQLite3 on a Debian based system, use apt-get install php5-sqlite3.
- Installer script needs to be patched to allow SQLite to work for a wiki installation since extensions are added from LocalSettings.php
Development Notes
The main include is Extension:MediaWikiLite.php which is added to LocalSettings.php as usual. This then uses the $wgAutoloadClasses array to load DatabaseSqlite.php when required by the LoadBalancer.
I've created a local MediaWiki-1.11 codebase copy that I can modify without affecting other local wikia. The config/index.php MediaWiki install script needs to be hacked to add an SQLite option. I added the following to the end of the $ourdb array:
Further down in the config/index.php installer script there is more database specific code for creating an initial MediaWiki database. In the case of MySQL it reads in tables.sql and interwiki.sql from the maintenance dir using the dbsource global function, but if it's PostgreSQL it executes the DatabasePostgresql::setup_database method, and if it's neither it raises an error saying it doesn't know how to handle the database type. I adjusted that code (around line 1000) to make it execute setup_database for all database types that are not MySQL as follows:
The setup_database method is done and is successfully creating all the tables as the following output from SQLite3 on the comman line shows:
Currently all the INDEX and KEY definitions in the CREATE TABLE statements have been removed, so this may cause problems down the track and need revising by adding CREATE INDEX statements etc.
The tables are being populated with the correct data during the installation as can be seen from the output of the following SELECT queries done from the command line.
Current State
The ResultWrapper iterator problem was the last and most difficult bug. It was fixed today (13:11, 16 January 2008 (NZDT)) by doing an initial fetchAll in the doQuery method and using the resulting array of all rows as the result object instead of the PDO::Statement object which doesn't implement a full iterator interface like a proper array does. Using an array rather than an object had some additional difficulties involving references since the iterator operators such as reset and next were actually operating on copies since arrays used passed as function parameters or in assignments do not use references by default.
Bugs
- After moving a page (move still worked though): Call to undefined method SearchEngineDummy::updateTitle() in /var/www/mwlite/includes/SearchUpdate.php on line 39
- SMW: Could not edit a system message when SMW enabled
- Special:Mostcategories? -possibly more categories are required
- Special:Movepage is failing
- Special:Ancientpages --See SQL error
- Special:Allmessages -- nothing returned
- Special:Prefixindex --see http://www.mediawikilite.org/wiki/index.php?title=Special%3APrefixindex&from=*&namespace=0
MediaWiki 1.12 Implementation
We'll change the www.mediawikilite.org site to a 1.12 and make this functionality into part of the codebase instead of being an extension. This means adjusting the config/index.php to accept the new database type. Being based on PHP's PDO abstraction layer we can easily implement the MSSQL version as well which there has been a fair bit of demand for in the mediawiki community.
See also
- DatabaseSqlite.php
- Extension talk:P2P.php
- NanoWeb - webserver with rewrite and other modules written in PHP
- DevZone PHP socket server example
- LinuxFormatWiki PHP socket server example
- SQL as understood by SQLite
- Tutorial: Convert MySQL Tables to SQLite Tables
- mysql2sqlite.pl
- mysql2sqlite.sh
- Iterators in OOP



