I've been disecting, so to speak, Tikiwiki 1.9 in its cvs form as I'm very interested in its multilingual feature.
This page is meant to list my thoughts/suggestions concerning Tikiwiki:
Some improvements that could/should be made (IMO) are the following:
- The memory usage is HUGE. Logging in to a freshly installed Tiki (with absolutely no content or registered users at all), requires around 6 MB of memory. Given the fact that most servers use the default settings for PHP (memory limit=8MB) that means that the moment that your site becomes popular you'll find that it can't handle the load that you'd expect it to. And proposed changes to the PHP settings are simply not feasible as most providers will refuse to do them (especially on shared hosting, which is what most people use). And with pretty good reasons, since most other php applications will work fine with the same settings. Of course this argument may be countered by saying that you can use a tikifriendly host but that amounts to vendor lock-in, finally, which is never a good thing (what if said web-hosting provider's services begin to drop in quality or become too expensive). And that means if you want to make something serious of it, you have to shell out the cash for a dedicated server (where you can control the settings) which would most likely definitely prove impractical if that site is only a hobby and financially difficult if that site is a commercial enterprise.
- The features are too tightly integrated. It should be as easy as deleting a couple of files to remove a feature. Doing that should -ideally- automatically remove the permission checks and the like for said feature, thus saving on a huge number of queries (another problem in tikiwiki). Right now the only way of removing a feature is removing the calls to functions used by undesired features and deleting their libraries, templates and php files which may still leave some leftovers behind, and besides upgrading would probably overwrite your changes, meaning it would take hours of tedious work with diff tools to see what changed in what file, and making sure your site will still work after the upgrade. So much for making things optional.
- I think the translation file should be broken into separate files for each section, so that each feature (forum, wiki) would only include its slice of the language file instead of the whole thing, thus saving on the memory requirements. However that may not prove easy to do / feasible. I know I've haven't figured it out a way yet
- Adodb seems to be underexploited. DB access using an abstraction layer will never be as fast as the real thing, but still I think it is still slower than it could be. Reading the docs in the adodb folder I've found about adodb's ability to cache db queries to the filesytem for a specified time interval, which doesn't seem to be used right now.
- Wiki page names are not search engine friendly. Searching for Avatar on google/av/whatever would not return ))page=?PluginAvatar(( in the results because it would be treated as a single word. Also It would probably be better and more common to use underscores or dashes as separators in page names, instead of the currently used plus sign, for similar reasons.
- Some of the queries use select all which is slower than using specified columns (as far as I know). Perhaps an area to look into for performance improvement? Also compiling all the templates in advances seems to yield some performance improvement, although not by much (unfortunately).