De spiller et stærkt holdspil, har masser af gå-på mod og arbejder serjøst.

Alle sammen ting vi elsker at opleve.

Vai vai vai, FC-Roskilde!

FCR U15

You can use the method presented on this post only if you have installed dokuwiki on Debian, with Aptitude/apt-get as described in the post linked to above, and you have followed those instructions,  in order to continue upgrading Dokuwiki manually instead.

When all this is said and done it is easy to upgrade (however no promises made here, backup all your files and dirs or you’ll lose data as by Murphy’s law and a couple of others), just do the following:

1. Download and save the new release into your private installations directory, so you have:

/usr/local/mypackages/dokuwiki-2008-06-05

2. Link your existing conf dir into the new location

ln -sTf /etc/dokuwiki   /usr/local/mypackages/dokuwiki-2008-06-05/conf

3. Link your exisiting data directory into the new release

ln -sTf /var/lib/dokuwiki/data /usr/local/mypackages/dokuwiki-2008-06-05/data

4.  Link the new dokuwiki package into where a normal Aptitude intallation would do

ln -sTf /usr/local/mypackages/dokuwiki-2008-06-05 /usr/share/dokuwiki

You’re done!

… er. Don’t you like the result?

Just roll back:

ln -sTf /usr/local/mypackages/dokuwiki-2008-05-05 /usr/share/dokuwiki

Do you see my point?

Then you copy a chunk of Apache conf into your site’s configuration and that’s it. The various directories are placed the right place and everything’s pink.

Yes, but, one day you realize that

aptitude update
aptitude upgrade

doesn’t give you any of the latest upgrades to dokuwiki and when you log-in as an admin you see:

New release available: 2008-05-05. upgrade now! [14]
New release candidate available: 2008-04-11. upgrade now! [12]
New release candidate available: 2008-03-31. upgrade now! [11]
An XSS vulnerability was discovered, read the bug report for manual fixing or upgrading [10]
New release available: 2007-06-26. upgrade now! [9]
New release candidate available: 2007-05-24. upgrade now! [8]

This is too much even for a lazy dog like me, so I had to do something, and that something was to install the latest dokuwiki release by hand, as if it was Aptitude (or apt-get) to do it. You can do it too, follow me step by step.

The advantage of following the Debian way by hand is that if the mantainer will feel like upgrading the package and you’ll feel like upgrading again via Debian/Aptitude, nothing will  get broken (and though, read the fine print: no warranties given here, I don’t know what the mantainer will do next time. However, that this method is safe is only a tiny bit less sure then taxes and death, read ahead for the why).

Furthermore, you stick to the same file structure/logic that all other packages have in your Debian system.

How is that structure for the Debian Dokuwiki installation?

Debian will give you:

/usr/share/dokuwiki/bin
       -''-        /conf -> /etc/dokuwiki
       -''-        /data -> /var/lib/dokuwiki/data
       -''-        /doku.php
       -''-        /feed.php
       -''-        /.htaccess
       -''-        /inc
       -''-        /index.php
       -''-        /install.php
       -''-        /lib
       -''-        /prepend.php

For this to work of course your Apache configuration will have something like the chunck below for the pages to be served from /usr/share/dokuwiki

Alias /dokuwiki         /usr/share/dokuwiki
<Directory /usr/share/dokuwiki/>
Options +FollowSymLinks
AllowOverride All
order allow,deny
allow from all
</Directory>

Note that the above is different from the default Dokuwiki installation (non Debian): a normal dokuwiki foresees dropping all the files in one folder inside your server tree.
Now, we will do the same as Debian/Aptitude but with some extra symlinking to be able to upgrade dokuwiki easily when the new release is available.  And besides, the extra step we introduce will secure our installation against dokuwiki being retrograded by an accidental upgrade done via Aptitude.

Finally this is a logic we can use with many other PHP (and javascript) packages

How do we do it?

We will save the new release inside /usr/local/mypackages (mypackages being your name of choice for your “hand-made” installations) for instance you’ll have all the files inside:

/usr/local/mypackages/dokuwiki-2008-05-05

(Aptitude won’t never touch it there, as by the Debian guidelines)

Then we will move the Dokuwiki’s /data directory out of this directory because we want to be able to manage that separately from later upgrades, it is the directory that keeps all our current and future dokuwiki pages – it must grow with you, indipendently from the dokuwiki version.

So we want something like, say,

/usr/local/mypackages/dokuwiki-data

and instead of having it inside the package dir, we will link to this directory, and in this way we are ready to upgrade without needing to be afraid of overwriting the data directory: in case of an upgrade the link is wiped out and you can just relink the new release files and the original data directory is intact, no need to move,  or save files prior the upgrade, the dir stays there out of the way.

The final complete setup of our dokuwiki package is therefore like shown below:

Apache finds dokuwiki inside:

/usr/share/dokuwiki

This is a:

/usr/share/dokuwiki -> /usr/local/mypackages/dokuwiki-2008-05-05
That in turn is made up of the directories and symlinks as shown below:

/usr/local/mypackages/dokuwiki-2008-05-05/bin
                  -''-                    /conf -> /etc/dokuwiki
                  -''-                    /data -> /var/lib/dokuwiki/data
                  -''-                    /doku.php
                  -''-                    /feed.php
                  -''-                    /.htaccess
                  -''-                    /inc
                  -''-                    /index.php
                  -''-                    /install.php
                  -''-                    /lib
                  -''-                    /prepend.php

/var/lib/dokuwiki/data is also a simlink:
/var/lib/dokuwiki/data ->  /usr/local/mypackages/dokuwiki-data

How do we reach this point? Step by step it is like so:

1. Download and save the whole package into your private installations directory:

/usr/local/mypackages/dokuwiki-2008-05-05

(do this as you wish)

2. copy the data directory as a separate directory inside your personal installations directory

cp /usr/local/mypackages/dokuwiki-2008-05-05/data /usr/local/mypackages/dokuwiki-data

2.1 If this is an upgrade and not a first installation you have a previous Aptitude Dokuwiki installation, so save your existing data dir (Debian places it inside /var/lib/ and calls it “dokuwiki”

rsync -av /var/lib/dokuwiki/data/ /usr/local/mypackages/dokuwiki-data/

3. [SKIP THIS  if upgrading from previous Aptitude Dokuwiki] Create a dokuwiki dir in /var/lib/ . As root do:

mkdir /var/lib/dokuwiki/

3.1 [FOR UPGRADING from previous Debian Dokuwiki installation]
Remove the Debian-made data dir:

rm -rf /var/lib/dokuwiki/data

4. Link your private data dir into the usual location for an Aptitude dokuwiki installation

ln -sT /usr/local/mypackages/dokuwiki-data  /var/lib/dokuwiki/data

5. [SKIP THIS  if upgrading from previous Aptitude Dokuwiki]  Copy the original conf dir where possible future Aptitude installations will find it. As root:

cp /usr/local/mypackages/dokuwiki-2008-05-05/conf  /etc/dokuwiki

6. [SKIP THIS  if upgrading from previous Aptitude Dokuwiki] Remove the original conf dir

rm -rf /usr/local/mypackages/dokuwiki-2008-05-05/conf

7. Link to the conf dir in the new location

ln -sT /etc/dokuwiki   /usr/local/mypackages/dokuwiki-2008-05-05/conf

8.  Link to the whole dokuwiki package into where a normal Aptitude intallation would do

ln -sT /usr/local/mypackages/dokuwiki-2008-05-05 /usr/share/dokuwiki

9. [SKIP THIS  if upgrading from previous Aptitude Dokuwiki] Then remember to configure apache to serve dokuwiki from the

/usr/share/dokuwiki

directory and you’re done.

And click here for a quick step by step tutorial for when the time has come to upgrade your Wordpress to the next release.

Happy dokuwiking!

You can see it in action here.

Why a new widget?

The Ajax style of application has removed the typical browser behavior of posting to the server and reload of a new page. It was a nuisance for many reasons and we love the fact that it is no longer there, however this behavior also provided the user with several clues about what was going on. At least two:

1. something has been sent
2. something has come back

In an Ajax application we usually provide a spinner, or a time glass cursor, to signal that we’re waiting a response from the server. When the action has updated something some other visual clue must also be provided to notify the user of what has actually happened:

1. If you delete an item, that item might have to be greyed out on the screen, or removed in a noticeable way.
2. If you edit an item you edit it on the screen, and to be sure that the server actually has received and saved your changes something more than just your changes on the screen must be sent back and shown to the user, whether it be an “OK”, “item saved” or a color transition of some fixed item on the screen.

Ok, we do this, what’s the problem then, one could say? The problem is that in a complex application the user receives:

1. A great quantity of feedback messages
2. A great variety of feedback messages

1. Great quantity

The sheer amount of situations in which the user needs to get a simple ”OK” from the application requires that you have a dedicated area on the screen for this kind of messages. Pop up messages that require a click or enter by the user are of course a no go. However your “OK” must disappear or change colour after they have been displayed, otherwise the user won’t know which “OK” is which. 

2. Great variety

In my experience the application needs to send to the user a fair amount of different kind of information, in many different situations and to different purposes.

The first instinct of the developer (er.. well, my first instinct)  is usually to device something specific for each of these situations, but one ends up with the “usual” mix of good and not so good solutions for each individual case. This disadvantage is, that no matter how perfect each of these solutions is in each particular case, they are different from what happens in any other case, and this, for the user, is in itself a very bad thing:  the user needs to know what to expect in different situations that, by the way, might not seem so different to her/him after all.

Especially this second aspect urged me to device something that:

1. did not take up too much space on the viewport;
2. could easily and always be noticed by the user;
3. did not necessarily require an action from the user;
4. could be controlled in a way to enforce some action from the user, in situations where this is mandatory;
5. could display any amount of information;
6. could keep this information available for the user to retreive it at her/his convenience;
7. had a fairly predictable behaviour;
8. should be working with YUI.

 I believe that with the SliderWindow I have reached these goals.

How to use it

When the SliderWindow is installed (see the easy installation instructions and examples ) you can always call it from the application and publish a message inside it, whereby the SliderWindow :

1. will slide open and close within approx. 1 sec, OR
2. will slide open and remain open until the user closes it
3. can be clicked open by the user, clicking on its 5 px thin, visible right border, OR
4. can be opened by the user, hitting Ctrl-right arrow
5. can be closed by clicking the close icon or by hitting Ctrl-right arrow

If your message is just a “OK” or “Order xxx is updated” or even kind of “The new order has got no. xxx. ” you probably will want to open and close the window right away. It’s routine messages.

However if your message is something like: “The added student has has no available allotment and won’t be able to receive books, unless the allotment is updated”, where this might be an unusual situation and still a legal one, you will probably send the message and leave the window open, to be sure the user has seen the message.

In the end your users will tell you which messages they want to be forced to acknowledge. In general they will want to be forced to acknowledge messages, that require them to do some physical action, ie. checking something on a paper file, verifying the functionality of some machine, retriving some item from a depot  or similar things. What specifically will depend on the company business routines and level of on-line integration/automation.

For system errors or user errors we don’t use the SliderWindow and make use of a YUI dialogue with a red header. This requires always a click to be closed, and marks a clear difference from this kind of messages.

Well, thinking about this, a possible improvement could be to add a method to control the color of the window and send error messages to the SliderWindow too, taking care to change the color of it, and leaving the window open. What do you think?

Requirements and some tech info

SliderWindow requires some YUI files, and only one .js and one .css additional file (plus assets directory for the  3 images). It is an extension of the YUI module that has pre-applied a container effect object to create the sliding movement. It is released under a BSD licence.

If you want to change the color of the window just add 3 new images for header, handle and footer and add your css file to override the paths for these 3 images. Currently you need to respect the same size though.

 Go to the installation and example page and/or leave a message.

Stor tak til Victor Pedersen www.designfaktor.dk for sit arbejde med den nye identity og webdesignet. Han formåede at kunne udfordre mig, samtidigt med at han selv accepterede at blive udfordret af mine krav. Kreativitet og fleksibilitet går ikke altid hånd i hånden, derfor er det så meget desto mere glædeligt, når man får en samarbejdspartner, som er forsynet med dem begge.

Jeg håber han også vil bære over med et valg af billeder som ikke helt overholder visse farvesammensætninger .

Og hvad skulle logoet forestille? Jo, det udspringer af en familieklenodie, som for mig udtrykker vilje og snilde til at springe de givne rammer. I dag hedder det at tænke “out of the box”, skønt denne genstand blev lavet en gang i den første halvdel af sidste århundrede. Altså på et tidspunkt, hvor begrebet ikke var formuleret endnu. Og i hvert fald ikke blandt stenbrudsarbejdere som min bedstefar var. Når jeg kan komme til det, skal jeg publicere et billede af det her.