The WiLiKi source can be downloaded from SourceForge.
WiLiKi is written in the Gauche Scheme implementation. For the full features of WiLiKi-0.4 you will need Gauche-0.7.2 or later. Gauche can be found at http://practical-scheme.net/gauche/.
If you already have Gauche installed, the WiLiKi install is simple. After unpacking the tarball, just ./configure && make && make install.
% gzcat WiLiKi-0.4.tgz | tar xvf - % cd WiLiKi-0.4 % ./configure % make % make install
make install will copy wiliki.scm and the major WiLiKi modules into the Gauche site library directory (if Gauche is installed in /usr this would be /usr/share/gauche/site/lib). This directory won't change with upgrades to Gauche.
Next, edit src/wiliki.cgi to suit your site. For details see the "Customizing" section below.
After editing wiliki.cgi, copy it to your cgi directory. Take care to use a directory where you can run cgi scripts according to the HTTP server settings (e.g. in cgi-bin) and you have the proper permissions set. Also, if using a stylesheet be sure to copy it to the relevant path.
Site-specific information can be set in wiliki.cgi. Make sure the wiliki.cgi character encoding matches Gauche's internal encoding. You can see Gauche's internal encoding by running gosh -V.
Omitting comments, wiliki.cgi looks something like this:
#!/usr/bin/gosh (use wiliki) (define (main args) (wiliki-main (make <wiliki> :db-path "/home/shiro/data/wikidata.dbm" :log-file "wikidata.log" :top-page "WiLiKi" :title "MyWiliki" :description "Shiro's Wiliki Site" :style-sheet "wiliki-sample.css" :language 'jp :charsets '((jp . euc-jp) (en . utf-8)) :image-urls '((#/^http:\/\/sourceforge.net\/sflogo/ allow)) )))
Places you may need to make changes are the first #! line and the keyword parameters below "make <wiliki>".
Change the initial #! line to the installed path of gosh.
Keyword parameters have the following roles. At the minimum you will need to edit :db-path.
|:db-path||Specify the path to the database file.If it's relative, it's relative to the directory in which the CGI script exists.I recommend to put the database outside the directory tree accessible via http.The database is automatically created when accessed the first time(make sure the data directory is writable by the CGI script only for the first time).The database file format differs according to the database type,with the default being gdbm.|
|:log-file||Specify the path to the commit log when using the edit history feature.If a relative path is given, the path will be interpreted relative to the :db-path file.If this keyword is not specified, the edit history feature will be turned off.|
|:top-page||The name of the top page. If the named page doesn't exist, it is created the first time it accessed.|
|:title||The name of your WiLiKi site. The string given here is used in places like the title of the "Search results" or "Recent changes" pages.|
|:description||A short description of this Wiki site. This is used in RDF site summary.|
|:style-sheet||If a path to the css is given, it is used as a style sheet. #f to use the default style.|
|:language||Default language, either en (English) or jp (Japanese).|
|:charsets||Specify assoc list of character encodings to be used to generate pages.The defaults are euc-jp for Japanese and utf-8 for English.The original data must be convertable for the output encoding. Forexample, if you try to output iso-8859-1 data on a Japanese page you'll get an error.|
|:image-urls||Specify which URL is allowed as an in-line image. This is a listof lists of the form "(predicate action)", wherepredicateis applied to the URL to determine if the action should be takenaction is either the symboll allow or deny.(You can take advantage of Gauche's self-applying regexp feature to use a regexp for the predicate)This applies to images inlined with the $$img macro.|
|:editable?||If #f, editing is prohibited.|
|:debug-level||If more than 0, wiliki shows diagnostic messages whenit encounters an error during processing (including macroexpansion error). Useful while debugging, but should beturned off for the sites open to public.|
|:db-type||A class that implements database functions. Set this when you want to usesomething other than the default <gdbm>.See "Backend Database" below for details.|
Because wiliki.cgi is started up as a CGI script you can add other processing. For example, before entering wiliki-main you can look at a cookie and determine edit permissions or default language, etc.
WiLiKi does not require a specific database backend. Fundamentally you can use any database implementation with a Gauche dbm interface.
If you're using Gauche-0.7.2, the following backends are available in the main Gauche distribution.
|Module Name||dbm Implementation Class Name||Notes|
|dbm.gdbm||<gdbm>||Uses the gdbm library (default).The database is stored in the file specified by :db-path.|
|dbm.ndbm||<ndbm>||Uses the ndbm library.The database is stored in two files, the path from :db-path appended with ".dir"as well as ".pag" extensions.Depending on the library there may be a length limit per item,and you may have problems locking the database.|
|dbm.odbm||<odbm>||Uses the legacy dbm library.Filenames and limits are the same as for ndbm.|
|dbm.fsdbm||<fsdbm>||Stores each page separately in a file under the directory specified by the :db-path parameter (actually stores in a hashed subdirectory therein). As the number of pages increases, full text search will become slowcompared to the other dbm libraries, but in the case of simultaneous repeatedrequests the efficiency shouldn't vary much.|
For gdbm, ndbm, and odbm the corresponding required libraries must be installed on the machine WiLiKi will run on. If using fsdbm there are no additional library requirements.
When using something other than the default dbm backend, wiliki.cgi will look like the following:
#!/usr/bin/gosh (use wiliki) (use dbm.fsdbm) ;; pull in the dbm library we're using (define (main args) (wiliki-main (make <wiliki> :db-path "/home/shiro/data/wikidir" :log-file "wiki.log" :top-page "WiLiKi" :title "MyWiliki" :description "Shiro's Wiliki Site" :style-sheet "wiliki-sample.css" :language 'jp :charsets '((jp . euc-jp) (en . utf-8)) :db-type <fsdbm> ;; specify the dbm class we're using )))
Just by copying wiliki.cgi to a different path and editing it, you can use multiple WiLiKis on the same site.
Also, you can share a database between two wiliki.cgi's, setting one to :editable? #f and using .htaccess or similar to restrict access to certain users.
To reference multiple WiLiKis with extended WikiNames you can use InterWikiName.
Sharing update information between multiple WiLiKis is experimental at present (WiLiKi:RSSMix).
The backup method differs according to the database implementation. From the WiLiKi side no particular backup interface is provided. If using gdbm, periodically copying the dbm file is simple enough (Strictly speaking, if someone edits a page in the middle of the cp command there's a chance the database will be corrupted. If that seems to be a likely problem it would be good to write a script that locks the database and then copies the file. But if that sort of case occurs so often that update frequency is high it may be worth looking into a full-blown database.)
Every time a page is updated that information is added to the commit log file specified by the :log-file setting.
The WiLiKi database only stores the most recent page information. When you request the Edit History, the pages past states are retrieved from the contents of the commit log.
It's probably not a very common case, but if large pages are frequently created and deleted the commit log can become very large and searching the Edit History can take a very long time. In that case you can move or delete the log file and start over recording changes from that point in time (in which case you can no longer consult changes prior to that time).