Omacronides 3.0 : PHP

Alors que le site grandit en taille, la maintenance d'une version statique des pages devient de plus en plus problématique. D'où l'idée de les convertir en PHP et de bénéficier des avantages d'une publication dynamique.

Tout ou partie des informations ci-dessous peuvent être obsolètes. Lire Omacronides 4.

La mise en oeuvre de la version PHP du site a, pour l'essentiel, consisté à adapter les fonctionnalités de l'utilitaire Autoit-CMS en PHP.

Gestion du site

En fait, le point de départ d'Autoit-CMS était de faire avec le langage de programmation AutoIt ce que des cms classiques faisaient avec PHP, en produisant cependant des pages web statiques. Le chemin inverse, transformer des scripts AutoIt en PHP, n'était donc pas trop difficile. Il suffisait de remplir le même cahier des charges, agrémenté de quelques autres conditions :

  • Gestion de 2 types de documents : articles et brèves.|2006-04-18
  • Gestion de l'architecture section/rubrique/article et journal/news.|2006-04-18
  • Format de stockage des données humainement lisible (xml).|2006-04-18
  • Gestion de brouillons et d'annexes (contact, recherche, etc.).|2006-04-18
  • Transformation d'une syntaxe wiki en code xhtml.|2006-04-18
  • Gestion des erreurs.|2006-04-18
  • Possibilité d'éditer le site « à la main », sans avoir besoin d'interface graphique ou de langage de script.|2006-09-10

La seule différence, c'est que la version PHP génère maintenant des pages dynamiques, c'est-à-dire des pages qui sont créées lorsque l'internaute demande leur affichage (en cliquant sur un lien ou en écrivant une adresse dans la barre d'adresse).

Administration

Outre l'automatisation de la création des pages HTML, Autoit-CMS possédait une interface d'administration du site rudimentaire (ajout d'un article ou d'une brève), mais j'utilisais Keynote pour écrire les textes ou modifier les fichiers de configuration. Les scripts PHP saupoudrés d'un peu de javascript permettent maintenant d'afficher / de modifier / de créer des articles ou des brèves et d'organiser l'architecture du site. Grosso modo, l'interface fonctionne comme suit :

  • Le PHP s'occupe de tout ce que faisait Autoit-CMS (création de nouvelles ressources, initialisation des fichiers de configuration) ainsi que l'ouverture / l'enregistrement des documents (articles, news, fichiers css, etc.).
  • Le javascript facilite à la fois la gestion de ces ressources (affichage de la liste des news en fonction de la rubrique par exemple) et simule quelques fonctionnalités d'édition de Keynote comme l'insertion de texte prédéfinis ou la gestion de « mots-clés » à remplacer par des expressions correspondantes (le « glossaire » de Keynote).
  • Enfin, le navigateur web Firefox supplée Keynote dans son rôle d'interface d'édition, de correcteur orthographique (l'extension Spellerpage remplaçant mon KnSpell), pour la prise de note (extension QuickNote) ou la gestion de documentation (extension Scrapbook).

Cette interface d'administration n'est pas encore en ligne (le sera-t-elle un jour ?) : il me faut auparavant régler les éventuels problèmes de sécurité.

Base de données : des fichiers xml

Tous les documents du site (brèves et articles) sont enregistrés dans des fichiers xml, un format de texte plat qui permet :

  1. une organisation logique du contenu en plaçant les informations dans différentes balises (titre, chapeau, rubrique, texte, etc.).
  2. une liberté de production / consultation que n'accordent pas des solutions utilisant une base de données MySql (ou autre). Je peux ainsi créer les fichiers avec n'importe quel outil d'édition ( un éditeur de texte ou le script PHP créé à cet effet) et ils peuvent être utilisés / exploités de différentes manière : à travers des scripts PHP mais aussi avec des fichiers de transformation xslt, ou tout simplement comme de simples fichiers textes lisibles.

L'extraction du contenu des fichiers xml se fait par l'intermédiaire d'une fonction untag créée par Chris Heilmann (mon xml-parser n'est en fait que l'adaptation Autoit de cette dernière).

Je pourrais éventuellement utiliser la collection de fonctions PHP 5 simpleXML, qui offre une alternative pour la manipulation des données xml plus simple que la solution expat proposée avec les versions antérieures, mais je n'ai pas encore entièrement appréhendé les subtilités de l'outil. Une technique mélangeant PHP et transformation XLS pourrait aussi être envisagée.

La configuration générale du site (sections, rubriques, nombre de brèves, etc.) est elle gérée par des fichiers .ini ou des fichier .php. Là encore, une évolution envisageable consisterait à placer ces données dans une base de données SQLite, utilisable à partir de PHP 5.

1.3. Mise en cache des pages

Enfin, un dernier point dans la gestion générale du site fût l'implémentation d'un système de mise en cache des pages web, qui permet d'améliorer la vitesse d'affichage. J'ai opté pour jpcache, pour sa légèreté et sa simplicité d'utilisation : une variable à définir dans un fichier de configuration, l'appel de la fonction à insérer en début de page et le tour est joué. Son utilisation peut par contre être encore amélioré.

Syntaxe wiki

Autre propriété d'Autoit-CMS qu'il fallait adapter : la gestion d'une syntaxe wiki pour transformer un texte humainement lisible en code XHTML. J'ai d'abord pensé à convertir les scripts autoit en PHP mais comme il est inutile de réinventer la roue toutes les 5 minutes, j'ai fini par utiliser le travail d'Olivier Meunier, la classe PHP « wiki2xhtml », intégrée entre autre dans son gestionnaire de blog Dotclear.

Cette classe est aujourd'hui en grande partie réécrite pour être intégrée dans une structure plus vaste, mais ces modifications ne doivent en aucune manière être considérées comme des « améliorations ». Il s'agit simplement d'une adaptation à certains besoins et à des habitudes d'écriture.

2.1. Gestion des titres

Plutôt mal à l'aise avec la syntaxe des titres de wiki2xhtml ou d'autre scripts équivalents, syntaxe qui consiste à utiliser une liste de points d'exclamation pour spécifier le niveau de la titraille (h2, h3, etc.), j'ai repris la forme d'écriture utilisée avec Autoit-CMS, ce qu'on appelle la syntaxe setext :

Titre de niveau 1
=======================================

Titre de niveau 2
--------------------------------------------------

Olivier Meunier avait implémenté en option la gestion de ce type de titre ; je n'ai eu qu'à y ajouter la prise en charge des identifiants pour construire le plan des articles. Ainsi, une notation du genre :

1. Titre de niveau 1
=======================================

1.1. Titre de niveau 2
--------------------------------------------------

devient :

<h1 id="p1">Titre de niveau 1</h1>

<h2 id="p1.1">Titre de niveau 2</h2>

2.2. Aménagement des blockquotes

L'aménagement de la syntaxe des blockquotes a consisté à supprimer la ligne vide nécessaire pour spécifier un nouveau paragraphe dans la citation. Ce type de notation est utilisée dans les e-mails, mais là encore, les habitudes d'écriture...

2.3. Ajout des listes de définition

Wiki2xhtml ne gère pas de syntaxe pour les listes de définition. Wikirenderer en possède une mais sous forme de notation sur une ligne pas très pratique. Dans Autoit-CMS, j'utilisais la syntaxe wiki suivante :

: terme à définir
:: définition du terme

Ce qui donnait :

<dl>
<dt>terme à définir</dt>
<dd>définition du terme</dd>
</dl>

J'ai donc ajouté cette syntaxe dans Wiki2xhtml. On peut même construire des listes de définition un peu plus complexe :

: terme à définir
:: première définition du terme.
:: seconde définition du terme.

: terme 1
: terme 2
:: définition des 2 termes.

2.4. Attributs des blocs

Wiki2xhtml ne permet pas à l'origine d'appliquer des attributs aux blocs (une classe, un identifiant, etc.). Heureusement, Steve Frécinaux a écrit un petit morceau de code tout simple qui permet de le faire.

2.5. Gestion des notes de bas de page

Enfin, j'ai modifié la gestion des notes de bas de page simplement parce que le système implémenté dans wiki2xhtml ne permettait pas, par exemple, d'écrire des notes avec plusieurs paragraphes (ou tout autre type de balises blocs).

2.6. Autres scripts de gestion d'une syntaxe wiki

  • PHP Markdown (PHP) de Michel Fortin. D'après le Markdown (perl) de John Gruber. Une syntaxe wiki très (trop ?) complète.
  • RestructuredText (Python). Un outil puissant utilisé notamment dans le projet DocUtils.
  • Setext (perl).
  • Textile (PHP) de Dean Allen. Existe une version plus complète en perl, et en php. Outil syntaxique utilisé notamment dans le cms TextPattern.
  • wiki2xhtml (PHP) d'Olivier Meunier. Script qui sert de base à celui utilisé sur ce site.
  • Wikirenderer (PHP) de Laurent Jouanneau.

3. Les annexes

3.1. Moteur de recherche

Le moteur de recherche en PHP est une simple adaptation du moteur de recherche en javascript crée pour la version statique du site. Il analyse 2 petites bases de données au format texte, l'une pour les articles et l'autre pour les brèves.

3.2. Glossaire, style switcher

Le glossaire ainsi que le style switcher fonctionnent toujours sur le même principe à base de javascript, même si j'aurai pu en faire une version PHP.

4. Todo list

4.1. Améliorer les fonctions PHP

Le CMS est actuellement une version brute de ce que je souhaiterai obtenir. On peut toujours améliorer l'efficacité des processus ou la rapidité des opérations. Certaines fonctionnalités pourront par exemple être gérées par une base SQLite. La mise en cache pourrait aussi être modifiée pour alléger les fichiers enregistrés.

Comme pour Autoit-CMS, les fonctionnalités des scripts PHP sont un peu trop spécifiques aux besoins de ce site pour avoir une portée générale. Je ne pense donc pas en diffuser le code ; pour le faire, il faudrait réécrire une grande partie des fonctions puis assurer leur diffusion sur le court/moyen terme, ce dont je ne me sens absolument pas capable. Ce ne sera pas une grande perte.

Par contre, je publierais sans doute des articles décrivant quelques fonctionnalités particulières qui pourront être utiles à tout un chacun.

4.2. Recherche, mots-clés, sections et rubriques

La classification des ressources en fonctions des mots-clés et son articulation avec la hiérarchie section-rubrique sont encore à l'état d'ébauche. Il faut clarifier les relations entre les deux systèmes pour implémenter une technique de recherche pertinente.

4.3. Commentaires ?

Je ne suis pas certain d'implémenter un système de commentaires du type de ceux des blogs ou des CMS. Il n'y a rien de vraiment compliqué au niveau technique, mais je me suis déjà exprimé sur le sujet (PS 2). Pour résumer mon propos :

  • Je n'aurai pas suffisamment de temps à consacrer à la modération des messages reçus, et je ne peux envisager un système de commentaires sans modération : je suis responsable du contenu diffusé sur ce site et n'ai pas envie de faire le flic à tout bout de champ (je sais de quoi je parle : on croise de curieux énergumènes sur les forums spip de Framasoft).
  • Avec le système actuel, j'estime qu'une personne qui prend le temps d'envoyer un email, qui écrit donc pour contacter l'auteur et pas uniquement pour voir sa prose imprimer sur la toile, a toujours quelque chose d'intéressant à dire (même si le système ne protège pas totalement du spamming).