This page is intended for wiki builders.
I am myself very grateful to Pierre ROUZEAU for building a similar page
This page was first written in 2006
This site is running on Linux / Appache 1.3.37 server. It is hosted in Germany by 1&1
- Powered by pmwiki-2.2.133
- Config file: Attach:config_php.txt
The skin is derived from the pmwiki-responsive with only minor style sheet changes.
- Skin CSS file: Attach:skin_css.txt
List of added Cookbooks
- Mini.php simple gallery with thumbnails
- autotoc.php page table of content
- sectionedit.php "Edit by sections"
- footnote.php & addfootnote.php "enables footnotes in the text.
- tabtable.php this cookbook is slightly hacked: the table style is defined in the CSS file.
- grouptitle.php Define a title for an entire WikiGroup
This wiki is indented for a small community of "railfan". I estimate that the core is 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.
- 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.
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.
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)
At the beginning, I stuck to the wiki spirit by not requiring user accounts or password to edit the content. The whole security was based around the concept of quick repair in case of attack rather than preventing an attack altogether. However, I had to frequently repair pages defaced by was appeared to be robots. I set a wiki wide simple password and gave away the password on the logon page itself. This solved 100% of the problem and it has been years now I had a page defaced.
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.
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 performed customization of the various templates used in the wiki:
- uploading template to display the max file size
- edit template to display 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.
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 migrated from HTML to Wikistyle one by one. I did make some tools on Excel to improve the productivity of this process.
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. I dropped this after a few year and migrated the picture galleries back into PMwiki leveraging the Mini Cookbook. This was easier than integrating PMwiki and Menalto. Menalto is very powerful but it turned out I did not need all that fire power and Mini was quite enough.
This set up using a limited set of cookbooks and some minimal changes to the default skin enabled the wiki to go live very quickly. I upgrade the engine on average twice a year to keep the technology current and avoid pitfalls linked to obsolescence. I did a few additional tweaks to the skin to keep current with the responsive skin. In all, this is perhaps 2h of system admin time a year. The site has been running trouble free for more than 10 years now and the wiki engine fulfilled its mission.