What I'm currently doing with TWiki
At work ( Fujitsu
our department is using a wiki for internal communication since 2005.
After some feature comparison back then, TWiki won the race.
And, by the way: TWiki has been easier to install than I had expected from
Our project's TWiki is running on Ubuntu's server edition with long term support (LTS),
on a virtual machine with 512MB of RAM, with mod_perl as performance booster. Authentication is done as single-sign-on against our corporate (Windows) Active Directory server with mod_auth_kerb and some tweakings in the TWiki code to accomodate for that. My TWiki hacking is done using a Linux system during quiet hours at home.
Currently on my mind
I am considering updating our rather old (4.0 + security patches, where applicable) installation to 6.0. The motivation is the WYSIWYG editor, which has become really good over time, and the improved query for TWiki apps. However, to get it working, I'd need to re-apply some patches I had made for 4.0 to a modified source base. Therefore, after several years of absence, I had a look at the code and found that my own coding habits have changed even more than TWiki's code. So here's a couple of thoughts on this.
For source control, I've moved from SVN to Git
, for various reasons. I'm far from being a Git expert, but as far as TWiki is concerned, it would have a very obvious benefit: Git doesn't clutter the file system with hidden directories, there's but one directory
in the "root" of the repository. I recall that the number of non-TWiki-files and directories often got in the way when running tests and benchmarks from a SVN checkout, both in the
folders. I'm glad that others also have this on their radar.
TWiki deployment is also something that might need to be adapted to current datacenter practice. Today when I want a server to run an application, then I get a virtual machine, and everything up to and including the operating system is up to the datacenter operations team. If you stick to packages from Linux distributions, they take care for updates, too, without extra charge. If you stick to the Linux file system hierarchy standard, they run backups for you, too, without extra charge. Every special software and every special backup routine needs to be maintained either by myself or they charge for it, because they need to run an extra step and monitor an extra service. Right now I run a post-install script after installation to move things around, set permissions, create files in the appropriate places so that they fit together, but I might need to adapt this script for every new release.
Finally, I've come to love the testing infrastructure which comes with Perl: The
command, the TAP (Test Anything Protocol), and the like. I know that TWiki's unit tests have a different philosophy, which is well-justified, but that will be yet another thing to again get accustomed to.
I'll see how much time I'll spend on this
My Personal Preferences
- Preference for the editor, default is the WYSIWYG editor. The options are raw, wysiwyg:
- Show tool-tip topic info on mouse-over of WikiWord links, on or off:
- Set LINKTOOLTIPINFO = off
- More preferences TWiki has system wide preferences settings defined in TWikiPreferences. You can customize preferences settings to your needs: To overload a system setting, (1) do a "raw view" on TWikiPreferences, (2) copy a
Set VARIABLE = value bullet, (3) do a "raw edit" of your user profile page, (4) add the bullet to the bullet list above, and (5) customize the value as needed. Make sure the settings render as real bullets (in "raw edit", a bullet requires 3 or 6 spaces before the asterisk).