PHP, Zend Framework and Other Crazy Stuff
Archive for May, 2004
Wiki’s – the perfect way to manage documentation?
May 19th
Well, I always knew this was going to be a problem. It usually is the area to suffer most in a project. QS for example uses a slightly modified help file from SE – but it’s very very (I mean very!) out of date. At least QS has a decent installation guide!
To try and solve this problem in some way, I decided yesterday to give a Wiki application a go. Seemed like the best solution. Rather than struggling with documentation and leaving it all to the last minute, a wiki allows all users to update a document online whenever they wish. Also allows new pages, and links to be created online by any user. It’s the ultimate world editable document
. But very easy to use.
So I spent yesterday searching for a good Wiki app, preferably GPL. Turns out there are quite a number – many seemed new, or else intermittantly developed. So I settled on two popular ones from SourceForge, namely PhpWiki and WikkiTikkiTavi.
I tested Tavi first of all. For those unaware of this, the main Smarty Templating website () uses an installation of Tavi as it’s base. The great thing about Tavi is that it is both simple to install and then modify to look anyway you feel. I really felt this was a great app for those looking for a simple Wiki to implement quickly. Its chief problems was a requirement to Perl to install the database schema and configure the installation. There are alternate PHP scripts for MySQL databases, but configure Perl was required. This means using telnet/ssh.
Second I attempted to install PhpWiki. What a nightmare! The installation is actually very simple however the documentation of this is in a very bad state – it’s fragmented into pages which are not apparently linked to a single easy to scan contents page (actually I did find a contents page through a Google search by accident
). Instead each page contains a few links – each leading to another page with a few extra links. A crazy place to try navigating for help. There was nothing wrong with the actual documents (once found) but the organisation is a bit too vague to easily navigate.
The main problem with PhpWiki was its configuration file. PhpWiki is very impressive – and more complicated than Tavi as a result. It’s based on the original Wiki, so it supports everything from MySQL to db for *nix. Getting through the configuration file was the most difficult area – especially user authentication if you want it – the options are many and can be confusing unless you commit to some careful reading of the documentation.
Overall, I though PhpWiki the most impressive – more complicated than Tavi to install, but worth it in the end. Unlike Tavi PhpWiki also has some pre-installed themes to choose from – Tavi had none I could see, and custom theme’s were nigh on impossible to locate without a thorough search of Google.
Anyway the result is here to see:
http://shadows.quantum-star.com/wiki
Moving auth to Sessions
May 17th
Finally I’ve gotten around to getting Q_Lib (i.e. a standard game backend for QS and SR) up and going. I spent some time moving the authentication and signup processes to a Class structure which employs Sessions rather than Cookies. I also removed the PHP Redirects and replaced them all with javascript versions. I’m well aware that Sessions add only a little obscurity to security but at least now the bugs in Internet Explorer will have no header redirects to get wrong. Also moving the cookie data to Sessions will prevent any possible bugs in prior PHP versions from stripping cookie data and disrupting logins.
I’ll be updating the Quantum Star SE directory structure once again to treat Q_Lib as a drop in directory in the backend.
As for Shadows Rising all these problems stemmed from cookie usage and zero OOP. I’ll remember to use OOP where possible in SR. For example the old login process reset cookies at least four times – they were also reset in location.php with every page request. Seems a bit too much just to pass a few simple variables to identify a user to the game. Sessions need only be set once – or unset if the authentication checks fail.
On a side note I also noticed once again that superglobals were being replaced by simple variables – no doubt this was easier when superglobals were not being used – e.g. $login_id rather than $_COOKIE['login_id'] but it’s one area which now is not required and should be removed for consistency.
Quantum Star SE Beta2 will be released tomorrow with a little luck.

Recent Comments