Choix techniques

Choix structurants

PHP/MySQL

Incontournable.

Pour moi le seul moyen économique d'avoir un site dynamique en ligne 24h/24 7j/7 avec une qualité de service correcte, c'est de m'offrir les services d'un hébergeur "petit budget". Et aucun de ces hébergeurs ne propose du Zope ou autres architectures J2EE.

Au passage, c'est je pense là qu'on trouve 90% des fondements du succès de PHP: sa simplicité d'administration et de mise en oeuvre a fait que les fournisseurs d'accès et hébergeurs ont pu fournir le service "j'héberge des pages PHP" quand mod_perl et les pages .asp sont restées sur la touche, malgré leur antériorité.

Donc la solution technique c'était PHP/MySQL, à cause de la facilité d'hébergement. Sinon j'aurais vraisemblablement choisi Zope.

Réécriture "from scratch"

Le choix constestable par excellence donc. Pourquoi ne pas avoir patché SPIP? Pourquoi ne pas s'appuyer complètement sur PhpWiki?

La réponse:

• vu la taille du code source d'UWiKiCMS et le peu d'envergure de ses fonctionnalités, SPIP ressemble à un mammouth à côté. Et de toutes façons la taille du patch aurait été au moins la même que celle d'une réécriture. C'est l'éternel problème du compromis entre réécriture complète ou adaptation d'une solution existante. Et j'ai vu des cas d'adaptation de l'existant (par exemple sur des ERP en milieu professionnel) ou la configuration d'un logiciel/progiciel était largement plus complexe et coûteuse que toute autre option.
• j'adore coder.

Les idées récupérées

Une liste d'idées que j'ai pêchées à droite à gauche et qui m'ont servi à structurer UWiKiCMS.

Le Zope traversal

Oui enfin, récupérer c'est un bien grand mot. UWiKiCMS ne fait que le quart de la moitié du douzième de ce que fait le traversal en question. Mais dans l'esprit c'est la même chose.

L'idée est que l'URL est interprétée non pas comme un nom de fichier, mais moulinée par le système, pour en déduire une action. Essentiellement, UWiKiCMS se contente de:

• déterminer si l'URL concerne une image ou pas
• simplifier l'URL (la débarasser de scories, vérifier sa syntaxe) pour obtenir l'identifiant de l'élément
• récupérer l'élément dans la base de donnéés, à l'aide du "path" précédemment calculé.

Dis comme ça ça a l'ai compliqué, en fait c'est très simple, quand vous accédez à http://www.ufoot.org/uwikicms c'est simplement l'élément "/uwikicms" de la base de données MySQL qui sera restitué à l'écran.

Il s'en suit que 100% (enfin pas tout à fait mais presque on le verra plus tard) du contenu d'un site UWiKiCMS est stocké en base de données. Y compris les images. Comme dans Zope d'ailleurs.

L'inclusion d'images "à la" SPIP

Plutôt que de monter une usine à gaz comme dans de nombreux CMS pour intercaler des images dans des blocs de texte et autres barbaries, UWiKiCMS utilise la stratégie de SPIP qui consiste à placer des marqueurs simples de type [ identifiant_image ] dans le texte.

Redoutablement efficace.

Wiki like

Du Wiki, j'ai gardé le concept "si un lien pointe vers un truc qui n'existe pas, alors proposer la création de ce truc".

Cela simplifie énormément le développement. Et l'utilisation.

Et ça explique donc en partie le nom "UWiKiCMS". Mais pas complètement.

Formattage du HTML façon PhpWiki

J'ai bêtement intégré quasi à 100% le système de rendu HTML de PhpWiki (copiage/collage de code brut et massif). D'autres candidats étaient en lice, notemment (re)structured text, mais je n'ai trouvé aucune implémentation en PHP vraiment fiable.

Idées originales

Interception de l'erreur 404

L'idée paraît simple mais elle fourmille de pièges techniques.

Au départ le concept est de dire: je met en place un ErrorDocument 404 qui pointe sur une page PHP, laquelle interprètera l'URL, calculera un "path", et restituera les informations ad hoc à partir du contenu de la base de données.

Jusqu'ici c'est simple.

Sauf qu'avec Apache (et pire, Apache 1.3 au lieu d'Apache 2.0, je ne maîtrise pas la plate-forme de mon hébergeur...) il se passe les choses suivantes:

• les paramètres de formulaire (POST) ne sont pas passés à la page "erreur 404".
• les sessions PHP ne fonctionnent pas lorsqu'on passe par cette erreur 404.
• les paramètres d'authentification HTTP, qu'on peut normalement récupérer en PHP, sont inaccessibles (ça c'est une spécialité de mon hébergeur, mais enfin...)

Bref, avec tout ça, j'ai été contraint:

1. de gérer les sessions à la main à coup de &session=un_truc_cryptique dans l'URL.
2. de passer par des "vraies" pages PHP (et pas une redirection) pour toutes les opérations qui traitent un résultat de formulaire.

Enfin au final, ça marche quand même, mais, si on peut me pardonner l'expression, j'en ai chié.

Et à ceux qui me diront que j'aurais pu faire un milliard de fois plus simple avec mod_rewrite et une simple réécriture d'URL, je réponds par avance "oui je suis au courant mais je ne PEUX PAS accéder au httpd.conf du serveur sur lequel j'héberge mes pages". Point final.

Cron sans cron

Certains appeleront ça de la bidouille, d'autres de l'astuce.

Pour faire tourner des programmes à intervalle régulier (ce qui normalement se fait avec cron mais encore une fois je n'ai pas la main sur le serveur...), la technique consiste donc à vérifier à chaque génération de page la date d'un fichier sur le filesystem, et lancer les opérations si le fichier est suffisamment ancien. Il suffit ensuite de changer la date du fichier et le tour est joué.

Cette ruse primaire est utilisée pour vider le cache régulièrement.

Domaine d'authentification par regex

Comment donner des droits à tel utilisateur sur telle ou telle zone du site sans tomber dans l'infernale complexité des modèles relationnels, lorsqu'on a juste 4 utilisateurs et 3 pauvres droits à donner?

La solution que j'ai adoptée est d'utiliser les expressions rationnelles. Si une URL "matche" la regex associé à un utilisateur, alors cet utilisateur a le droit de modifier le contenu correspondant.

D'autant plus simple à code que PHP aussi bien que MySQL savent traiter les expressions rationnelles de manière simple et sans module additionnel.

Insertion de code PHP via /_external

Idée toute simple mais très pratique: lorsqu'une page est affichée UWiKiCMS va automatiquement voir si la page /_external/chemin/complet/de/la/page.php n'existerait pas par hasard sur le système de fichier.

Ca permet de spécialiser comme on le désire certaines pages, tout en évitant de monter une "usine à gaz". Temps d'implémentation: quelques heures. Services rendus: énormes car ça m'a évité d'avoir à "rentrer" dans UWiKiCMS des fonctionnalités ésotériques dont j'ai besoin pour certaines pages mais qui n'ont rien à faire dans du code générique.