Difference between revisions of "MediaWikiLite"

From Organic Design wiki
(re-word)
m (See also)
Line 82: Line 82:
  
 
== See also ==
 
== See also ==
*[[DatabaseSqlite.php]]
+
*[http://www.mediawikilite.org www.mediawikilite.org] ''- example of MediaWiki 1.13 installed with SQLite''
 
*[[MW:SQLite]]
 
*[[MW:SQLite]]
 
*[[Wikipedia:SQLite]]
 
*[[Wikipedia:SQLite]]

Revision as of 10:23, 9 September 2008

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.

SQLite support for MediaWiki is 90% functional but still very much in development. As of MediaWiki version 1.13 the SQLite support is part of the main code-base. A running instance of MediaWiki 1.13 using the SQLite database can be seen at mediawikilite.org to test the current functionality.

Installing SQLite as an Extension (for MediaWiki < 1.12)

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.

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.
  • Check your phpinfo() to see if pdo_sqlite is listed, if not, try adding extension=php_pdo_sqlite.so into the dynamic extensions section of your php.ini
  • 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:

{{{1}}}

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:

{{{1}}}

The setup_database method is done and is successfully creating all the tables as the following output from SQLite3 on the comman line shows:

sqlite> .tables
archive            job                querycache         text             
categorylinks      langlinks          querycache_info    trackbacks       
externallinks      logging            querycachetwo      transcache       
filearchive        math               recentchanges      user             
hitcounter         objectcache        redirect           user_groups      
image              oldimage           revision           user_newtalk     
imagelinks         page               searchindex        watchlist        
interwiki          page_restrictions  site_stats       
ipblocks           pagelinks          templatelinks   

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.

sqlite> select * from text;
1|<big>'''MediaWiki has been successfully installed.'''</big>
Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.
== Getting started ==
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]|utf-8

sqlite> select * from revision;
1||||0|MediaWiki default|20080109065800|0|0|449|

PDO Statement Iterator

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

See also