Table of Contents

WackoWiki est le wikiwikiweb que j'utilisais avant de migrer vers dokuwiki (de 2003 je crois à décembre 2011).

Ce wiki tournait WackoWiki R4.2 (migré de R4 ver R4.2 le 4 mai 2005), puis R4.3. Ensuite, il n'y a plus eu de développements pendant longtemps. La version R4.3 ne fonctionnait pas avec PHP > 5.2. Fin 2011, vu que Debian arrêtait les mises à jour de sécurité pour 5.0 (lenny, qui utilise PHP 5.2.6), il fallait changer. J'ai essayé de migrer vers R5.0.beta et R5.0.rc, mais ça ne fonctionnait pas (problème dans la mise à jour des tables mysql). Donc, je suis passé à dokuwiki avec un script perl wikka2doku.pl trouvé sur le site de dokuwiki.

Installation

J'ai d'abord installé la version R3, puis je suis passé à la R4: WackoWikiR3ToR4Migration

Ensuite, j'ai réinstallé mon serveur: je suis passé de woody à sarge. J'en ai profité pour passer à apache2.

Pour migrer, il a suffit de

Pour que ça fonctionne en http et en https:

Ajouter au début de wakka.config.php

if ($_SERVER["HTTPS"] == 'on') {
  $protocole="https";
} else {
  $protocole="http";
}

Et changer la ligne:

"base_url" => "http://callendor.zongo.be/wiki/",

en

"base_url" => "$protocole://callendor.zongo.be/wiki/",

Problème

Content Encoding Error

The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

C'était parce que je n'avais pas créé et alimenté la base de données dans MySql

Anti-spam

CapTcha Hack

I was spammed twice over 100 pages in less than a month. That's too much.

So, I looked around for a solution and the best thing I could find was a Wikipedia:Captcha.

There is a feature request in the bug tracking system, but it hasn't been assigned so I guess I'll have to do it myself.

For PHP (since WackoWiki is coded in PHP), the best implementation of captcha I could find seems to be freecap (v1.3 at the time of writing).

The following will display a picture with letters that the anonymous user will have to type in a textbox to save his modifications.

It's a dirty hack.

Problem with powerpc

I moved my wiki to a G4 server (powerpc CPU).

Since then, the letters don't display on the picture :(

Found on http://www.puremango.co.uk/cm_freecap_support_133.php

1.4.1 - The fonts don't display
First, make -sure- you've uploaded them; some FTP clients, including Dreamweaver, don't 'see' files beginning with '.' - try a different FTP client (like WS_FTP LE). You should be able to see “.ht_freecap_font1.gdf”, “.ht_freecap_font2.gdf” and so on in your freecap directory.

If you are sure that you have uploaded the files, and you're not using an intel processor (in other words your server is not Linux or Windows, it is mac, sparc, aix, motorola, etc), then I'm afraid this is a bastard problem from hell for which I have no fix yet.

GD fonts are architecture-dependant, which means that for your big-endian processors I need to produce special font files.
Try to get hold of some big-endian GD fonts and PLEASE let me know if you find some. I'm sorry but I don't have the resources to fix this. If you manage to get freeCap working on your processor please let me know so I can publish your findings and help other big-endians.
The only workaround I can suggest is to either:
-hack the included fonts and send me copies
-use an older version of freeCap that didn't use GD fonts and hack in the security updates from earlier versions (bad idea)
-use a different CAPTCHA system :-(

so, font.gdf has to be rebuilt…

Looking for a solution.

Solution on http://www.puremango.co.uk/cm_freecap_support_133.php (comment from 10/05/2006)

The remark the fonts might have something to do with this particular problem lead me on the right track. After googleing a bit I found out that similar problems had been reported before. They had to do with the endianness of the GD font files. Most GD font files are created on PC architecture Machines. The x86 family of processors and their clones are little-endian. I try to use FreeCap on an ~UltraSPArc machine, which is (like Macintosh PowerPCs and some IBMs and other machines) big-endian. (For more information on endianness in general read the article in the wikipedia).

This difference leads to wrong values calculated for the font sizes which - in turn doesn't display. I solved this problem by loading the font files into a Hex-Editor (Hex Fiend for the Mac is quite cool!) and reverted the Byte order of the first 4 32-bit words (the rest may be left untouched, it is not prone to endianness), which are the header data of the GD font file. So, if the original byte order in .ht_freecap_font1.gdf reads:

1A 00 00 00 | 61 00 00 00 | 22 00 00 00 | 32 00 00 00

The resulting file should read:

00 00 00 1A | 00 00 00 61 | 00 00 00 22 | 00 00 00 32

This revealed a second problem: The fonts still showed not up, even after converting the fonts. The reason for this is the number of bytes read in the line

$c_wid = fread($handle,11);

Since you read only 11 bytes, in a big-endian scheme the last byte of the 3rd quadruplet (in the example from above: 22) will be missing. I didn't go too deep into the GD font file format but the byte seems to be significant for your calculations so after changeing the read from 11 to 12 bytes:

$c_wid = fread($handle,12);

everything worked fine. For all of the people experiencing this problem (background shows, letters do not) check the endianness of your architecture and modify the font files if needed.

Pour la version 1.3, il n'y a que le fichier font.gdf à changer, rien dans le code.

Modification des meta-tags

C'est dans le thème qu'on trouve ça: wiki/themes/default/appearance/header.php