Installation

Prérequis

Installer UWiKiCMS nécessite impérativement de disposer d'un serveur Apache 1.3 / PHP 4.3 et d'une base MySQL 3.23. Ces versions sont les versions minimales nécessaires, il est possible et vraisemblable que cela fonctionne avec des versions plus récentes (Apache 2, PHP 5, MySQL 4), mais ceci n'a pas été réellement testé.

L'installation par défaut suppose que le serveur Apache prend en compte les fichiers .htaccess placé dans le DocumentRoot, et que la directive ErrorDocument y est acceptée.

Un accès PhpMyAdmin ou à défaut une bonne habitude à manier les requêtes SQL "à la main" sont un plus appréciable, car certaines opérations nécessitent des manipulations directement en base de données.

Le script de configuration ne fonctionne qu'en environnement UNIX, ceci risque de ne pas être pratique pour les utilisateurs Windows. Réponse au lance-pierre: le jour où Windows disposera d'un système de script digne de ce nom on pourra peut-être trouver une solution, en attendant Cygwin et GNU/Linux sont tes amis.

Téléchargement

Les versions officielles d'UWiKiCMS sont disponibles sur:

• http://www.ufoot.org/uwikicms/download
• http://download.savannah.nongnu.org/releases/uwikicms/

Il n'y a pas de serveur CVS pour UWiKiCMS, mais il est aussi possible d'accéder à un dépôt GNU Arch sur http://arch.sv.gnu.org/archives/uwikicms/ . Pour récupérer la dernière version de développement, utiliser des commandes du type:

 tla register-archive http://arch.sv.gnu.org/archives/uwikicms/
 tla get -A uwikicms@sv.gnu.org uwikicms--stable

Procédure d'installation

Code PHP

Le script ./configure appelle ./configure.php. Pour s'exécuter ce script php doit être disponible en ligne de commande dans /usr/bin ou équivalent (package php4-cli sous Debian par exemple).

./configure.php se contente en fait de:

• copier les fichiers .htaccess-dist en .htaccess
• copier les fichiers config.php-dist en config.php
• modifier ces fichiers à la volée si nécessaire

Donc si le script de fonctionne pas, pas de panique, il suffit de copier les fichiers "avec le -dist" dans des fichiers "sans le -dist", et de les éditer à la main.

./configure accepte des options du type --key="value", voir les différents scripts dans le répertoire ./misc, que j'utilise pour paramétrer mes sites et qui sont AMHA d'excellents exemples. Copiez un de ces scripts et modifiez-le, l'avantage de cette technique est que comme ces scripts sont régulièrement exécutés et utilisés par moi, ils sont à jour, à l'inverse de toute documentation 8-)

Les options acceptées sont:

• --siteurl=... : le protocole (http ou https) + le nom de domaine, par exemple http://www.ufoot.org .
• --htprefix=... : le chemin racine du site UWiKiCMS, sans le nom de domaine, par exemple si la cible est http://www.ufoot.org/uwikicms, utiliser --htprefix=/uwikicms
• --dbprefix=... : permet de gérer des sous-sites. Typiquement j'utilise cela pour faire en sorte que http://ufo.ufoot.org corresponde à http://www.ufoot.org/perso/ufo . Dans ce cas on paramètre --dbprefix=/perso/ufo pour que le site spécialisé n'affiche qu'une sous-arborescence du site complet.
• --dbhost=... : le nom du serveur de base de données (nom de machine au sens DNS)
• --dbname=... : le nom de la base MySQL
• --dbuser=... : l'utilisateur pour se connecter à MySQL
• --dbpasswd=... : le mot de passe pour se connecter à MySQL
• --images_dir=... : le chemin pour accéder aux différents boutons et autres fonds d'écrans, par défaut "/_uwikicms/template/images/default" (permet de gérer les thèmes).
• --css_dir=... : le chemin pour accéder aux CSS, par défaut "/_uwikicms/template/css/default" (idem, permet de gérer les thèmes).
• --copyright_holder=... : un nom de personne qui sera utilisé dans les copyrights (copyleft!) par défaut.
• --debug : active le mode "debug". Essentiellement PHP renvoie des messages d'erreur plus verbeux. C'est le mode par défaut.
• --release : active le mode "release". Pas très pratique en test car PHP ne dit rien en cas d'erreur, mais pertinent en production.

Une fois la configuration effectuée, poser les fichiers sur le serveur PHP, via ftp par exemple.

Noter qu'il y a un peu de magie noire dans UWiKiCMS, et qu'il est très important que le fichier .htaccess à la racine du site existe et contienne la bonne valeur au niveau de la directive ErrorDocument. Sinon rien ne marche.

Base de données

UWiKiCMS ne dispose d'aucun moyen (type "back-office" par exemple) d'éditer la liste des utilisateurs du système. La raison fondamentale est que PhpMyAdmin fait AMHA ça aussi bien que n'importe quelle interface bancale que j'aurais pu bricoler. Dont acte.

Donc il s'agit d'éditer le script ./sql/mysql.sql et:

• soit supprimer les lignes commençant par "INSERT INTO uwikicms_user..." et reporter le problème de la gestion des utilisateurs à plus tard.
• soit modifier directement les lignes en question, en remplaçant par des valeurs qui vous conviennent. Ce sont essentiellement les mots de passe (les valeurs passées dans la fonction MD5) qu'il s'agit de modifier, car sinon n'importe qui pourra se loguer sur votre site en utilisant le couple user/passwd "admin/admin".

Passer ensuite ce script sur le serveur MySQL.

Laisser le charme agir.

Première connexion

Essayez d'accéder à l'URL du site, qui est en fait la concaténation de $siteurl et $htprefix (rappelez-vous, les valeurs passées à ./configure...)

Normalement vous devriez avoir une erreur de type "Erreur 404", habillée à la sauce UWiKiCMS (vérifiez qu'UWiKiCMS est mentionné en bas de page par exemple). Cette erreur est normale, il n'y a pas encore de contenu dans votre site. Cliquez sur "Se connecter", une mire de login apparaît. Taper le couple user/passwd correspondant au profil administrateur (par défaut admin/admin, hautement sécurisé). "Continuer". Et normalement vous obtenez une page de création de document "Sans titre". Vous pouvez éditer ce document, ce sera la page d'accueil de votre site.

Dernier test, essayez d'accéder à la page $siteurl$htprefix/titi/toto. Concrètement si votre site est installé sur "localhost/foo", essayez d'accéder à "localhost/foo/titi/toto". Si vous obtenez la même page que tout à l'heure (l'erreur 404 habillée "à la" UWiKiCMS), c'est gagné. Sinon, si vous avez la page d'erreur 404 par défaut d'Apache, il y a un problème avec le fichier "localhost/foo/.htaccess".

Voilà, logiquement c'est terminé, à ce stade ça fonctionne.

Suivez votre intuition, bidouillez sans lire le manuel utilisateur (j'aurais fait pareil), UWiKiCMS est assez pauvre en fonctionnalités pour qu'on en fasse vite le tour.

Gestion des utilisateurs

Pas de "back-office", pourquoi?

Simplement parce qu'en codant une interface "ajouter un utilisateur, le modifier, etc." j'aurais eu l'impression (et pour cause!) de réinventer la roue.

D'autant que l'esprit d'UWiKiCMS, c'est deux ou trois contributeurs qui saisissent et c'est tout. UWiKiCMS met très peu l'accent sur le collaboratif et le multi-utilisateurs.

Dans ce contexte manipuler les utilisateurs via PhpMyAdmin me paraît acceptable, voire préférable.

Structure de la table uwikicms_user

user_id

le login utilisé pour se connecter

user_passwd

le mot de passe associé, crypté via l'algrithme md5

user_label

le libellé de l'utilisateur (prénom + nom par exemple)

user_copyright_holder

le détenteur du copyright des contenus saisis par cet utilisateur. Noter qu'UWiKiCMS fait apparaître en bas de chaque page un message qui dit en substance que le document est "copylefté" (via la GNU FDL) et que le copyright appartient donc à ce fameux "copyright holder". Pour changer ce comportement, il faut modifier le code, ce qui est évidemment parfaitement autorisé et possible.

user_email

l'email de l'utilisateur, il n'est pas nécessaire de le préciser, surtout si on veut éviter de recevoir 500 tonnes de spam, car cet email apparaîtra en bas de chaque page saisie

user_status

le statut de l'utilisateur, entre 0 et 3.

user_domain_regex

pour les contributeurs de statut 2, définit les zones qu'ils peuvent éditer

La signification du champ user_status est la suivante:

"0"

anonyme, créer un tel utilisateur n'a pas de sens

"1"

visiteur, invité. Ce type d'utilisateur ne peut pas saisir de contenu, mais il peut lire tous les documents "protégés par un mot de passe". Typiquement je me sers de ce profil pour donner accès à des informations dont je ne veux pas qu'elles soient lues par n'importe qui ni n'importe quel robot d'indexation, mais qui n'ont pas un caractère privé très fort. Si quelqu'un arrivait à trouver le mot de passe sans que je sois au courant, ce n'est pas très grave.

"2"

contributeur. Ces utilisateurs peuvent saisir du contenu. Il est possible de restreindre la zone sur laquelle ils peuvent éditer grâce à une regex (expression rationnelle). Par exemple pour limiter l'édition à la zone toto, la regex "/toto" convient.

"3"

administrateur. A le droit de tout faire. Peut entre autres saisir du contenu "confidentiel", que personne hormis un administrateur ne peut lire.

Exemples pratiques

Voici quelques requêtes SQL qui permettent de manipuler des utilisateurs.

Création d'un contributeur:

 INSERT INTO uwikicms_user 
 (user_id, user_passwd, user_label, user_copyright_holder, user_email, user_status, user_domain_regex)
 VALUES ('toto',MD5('0+0=0'),'Mr Toto','Toto','toto@ufoot.org',2,'/toto');

Changement de mot de passe:

 UPDATE uwikicms_user 
 SET user_passwd=MD5('lateteatoto') 
 WHERE user_id='toto';
 

Suppression d'un utilisateur:

 DELETE FROM uwikicms_user
 WHERE user_id='toto';