Dokuwiki Revival -*-org-*- Date: 2011/9/12 In the process of evaluating some wiki engines (see ToTry) as candidates for my personal CMS, I thought of Dokuwiki, the system I have set-up in my MOTD root and used actively for a month or so back two years ago. I'm not sure now why I abandonned Dokuwiki, though it may have been because I didn't see a way to integrate it with my gopherhole, and the trouble with getting all my desired navigation parts and pages set-up in wiki format. I remember back then being impressed, as I am now, with Dokuwiki's rich feature set, and I have now discovered a way to make Dokuwiki use my gopherhole file subtree as its database, so I think it's worthwhile giving Dokuwiki another look as my web-side content manager. DW's biggest charm points for me: - Documents are plain text files. - Document content formatted for easy reading and manipulation with tools outside DW. - Subdirectories supported as "namespaces". DW has had many releases since I let my wiki languish, so rather than upgrade the current installation I've made a separate installation with the latest version. I'll delete the old installation when I've completed migration. Actually, migration is mostly done since I used the gopherhole-serving trick to copy all DW content into green dataset. * Gopherhole-serving trick I renamed the DW "data" directory for safety, then created a "data" smbolic link to the green dataset root (gopherhole root). The DW security page lists the above as one method of securing the data directory if .htaccess can't be used. It also indicates there is a configuration variable that can be set any directory as the DW DB. (Will likely use latter method for permanent installation.) * Functional issues Out-of-the-box DW doesn't do everything I want to do in the way I want to do it. But it's closer than I thought it was a couple of years ago. I feel like I can get the essential functions with just a little hacking of plugins and/or the DW core (I'm feeling a little more programming adventurous than before). - Need way to bypass std. DW markup parser in favor of my ultra-simple text file format (first line is title (supress "-*-org-*-"), remainder is preformatted text). + DW has an interface for customizing parsing. It's so complex I was ready to dismiss it with, "my vision is too different from DW's assumptions: it will be easier to implement from scratch than to learn DW customization." However, programming experience sggests that the latter opinion is probably incorrect: even if it takes a while to learn DW customization, implementing a CMS on my own is not a trivial task. I owe it to myself to make an earnest attempt at learning DW technology since it has the potential to serve as a platform for everything I wanted in TIR. If I can figure it out, it will be a lot faster than programming everything myself. - Multiple file extensions: txt, html, org, images, script/source ... - Blog/RSS draws from multiple (all) namespaces. - Integrate version control system. - Autogenerate navigation pages and parts (nexus, room display, nav bar, ...) - Comments open to non-registered users? RSS for comments? - Port retro-green theme.