Wiki Configuration

This page is intended for wiki builders.
I am myself very grateful to Pierre ROUZEAU for building a similar page

Present configuration

This site is running on Linux / Appache 1.3.37 server. It is hosted in Germany by 1&1

• Powered by pmwiki-2.2.35
• Config file: Attach:config_php.txt
• CSS file: Attach:pmwiki_css.txt

A special skin "tot1" is used to seamlessly integrate the wiki into an existing site. This skin is a variation of the default PmWiki skin.

List of added Cookbooks

• attachlistenhanced.php
• authorcontrib.php
• blocklist2.php
• e-protect.php emails obfuscation
• expirediff.php
• pagetoc2.php page table of content
• sectionedit.php this cookbook is slightly hacked to change the style of the "edit" command
• tabtable.php this cookbook is slightly hacked: the table style is defined in the CSS file.
• Mini.php simple gallery with thumbnails

Wiki specifications

General specs

This wiki is indented for a small community of "railfan". I estimate that the core will be less than 10 authors. This community may not be IT expert: site ease of use is a must. This wiki is really about text content. Very few features are actually required as long as the wiki is intuitive to understand and to use.

This wiki replaced an existing "traditional" websites made of fixed HTML pages. This site had already 6 years of existence and was already quite mature. Migration from the old site to the wiki has been done in 3 months. During the transition, the two parts (legacy & wiki) cohabited seamlessly. The wiki template must be easy to alter to blend into the existing site.

UTF8 support: this is a must for this site to render properly all the names in the various language, especially Turkish.

The existing website does have a lot of pictures. Some sort of solution has to be offered for that (more about this later).

I, as a webmaster, don't have a lot of time to invest in this project and certainly don't want to enter coding.

Technical specs

• My host contract does not support all technologies. ASP in particular is excluded. I choose PHP which now a mainstream proven technology.
• My host contract does not give me an admin access. The wiki is installed from a basic FTP access.
• This wiki, by nature, is specialized on a narrow subject and is edited only by hobbyist. It will never grow to a huge size. Hence, a database is not needed, a file system is good enough. Side benefit: I will save the time required by database management
• This is a public wiki: good security is needed (page history, password management, … )
• This wiki is for an international audience. It is (and remain) in English.
• Open source was a must for me although I understand it is a personal choice.

I wanted a wiki with WYSIWIG editing but I realized that was not practical with existing technology.

Design & Implementation Process

Choosing a wiki engine

I spend a lot of time evaluating the various offerings. There are currently a lot of wikis on the market and choosing might not be easy.

Pmwiki strong points:

• the right blend of features for me.
• The technology is sound.
• The community around this product quite active.
• A substantial installed base.
• A very good online documentation (also demonstrating the wiki)
• A support group
• Favorable review
• Success stories: I was able to visit a lot of websites alive with the sort of look and feel I was looking for
• I was able to install and run the wiki on my PC in a few minutes.

Draft Implementation

Once Pmwiki chosen, I set about to configure it. The most difficult task is to define all the add-ons needed (called Cookbooks) to achieve the desired features. I found the online documentation quite useful for this.

I performed a draft install of the product

• set-up UTF8 (my most desired feature)
• set-up section edit
• set-up table of content

These three are easy to do and gave me confidence to move forward. I prepared the config file and made all kind of testing to understand the wiki behavior.

Then I went to style sheet and skin. I created a skin by basically copying the Pmwiki skin and then tweaking it until I had the correct design. This is not really difficult because I already had all the styles already defined for my old site.

Security

The world is full of spammers and hackers. Even innocent subjects like mine attracts dysfunctional people. Pmwiki has some nice & effective features that requires only parameters in the config file:

• email notification
• depth of history file
• URL approval
• Upload file max size and file types
• password protection of pages and groups

And nice cookbooks:

• blocklist (blocking keywords and IP addresses)
• e-protect.php (obfuscating of email addresses)

On the other hand, I stuck to the wiki spirit by not requiring user accounts or password to edit the content. The whole security is based around the concept of quick repair in case of attack rather than preventing an attack altogether.

Moving to a wiki led me also to clarify the site content license, a thing that I had always left in the fog in the past. This could help sort out liabilities in case of a conflict with an author.

Final implementation

Once all of the above done, I started all-over with a clean install of Pmwiki, on which I applied the skin and the config file.

At this stage, I performmed customisation of the various templates used in the wiki:

• uploading template to display the max file size
• edit template to diplay the site license contract
• pagelist templates for various internal needs

I finalized the design & content of the left-side menu.

I also documented all the process using the wiki itself for the purpose: the documentation is placed in a password-protected section.

Content migration

This is a perhaps the most painful part of the process. Straight migration is not really an option: the content was reorganized to take advantage of the wiki structure. The numerous table of the site had to be transcoded from HTML to Wikistyle one by one. I did make some tools on Excel to improve the productivity of this process.

Pictures

I kept this topic for the end because it proved the most difficult.

The site had about 1200 pictures at the time of migration.

Looking back at my requirements, I realized that I had two types of pictures:

• pictures that are intimately connected to the text and must be inserted in the Wikipage. The Mini cookbook creating simple galleries works perfectly well for this. It can be seamlessly used in text and in tables just like the default Attach: command for pictures.
• pictures that have a remote connection to the text and can be on a different page. I set up a gallery program (Menalto-Gallery in this case) and built up a loose (but quick) connection based on hyperlinks

This set up using available tools enabled the wiki to go live very quickly. I realize this is far from perfect because the pictures are in two locations: the wiki and the gallery. The long-term solution would be to have all the pictures in the galley and embed some of then in the wikipage with a purpose built markup. I will report on this once done!