Finalement...

Après une petite promenade dans le code de FSB (cf Rester sur phpBB ?), même s'il comporte de bonnes choses, il en comporte aussi des moins bonnes, dont :

  • Commentaires des méthodes, classes et fonctions ne respectant pas la syntaxe (inspirée de la syntaxe javadoc) utilisée par les principaux outils de génération automatique de documentation tels que phpDocumentor.
  • L'intégration des modules reste moyenne et semble se résume principalement à une modification automatique du code, similaire à ce que fait EasyMod, mais intégré au forum. C'est déjà pas mal mais j'espérais mieux avec une réelle exploitation de l'extension des classes par exemple ou des fonctionnalités d'import/export de données...
  • Pas mal de choses telles que l'ajout de champs au profil sont présentes mais pas aussi puissantes que ce que j'ai déjà développé pour phpBB2 et demanderaient donc d'être revues voire re-codées complètement.

Donc au final, même si ça constituerait un mieux, c'est pas encore ça... De plus, à la réflexion, migrer l'intégralité de mes modules prendrait un temps fou (plusieurs mois), pendant lequel je serais forcé de geler tout nouveau développement.

Une autre solution s'offre donc : rester sur phpBB2 et le modifier encore plus en profondeur, sans rester proche de l'original. En effet, jusque là, pour bénéficier des mises à jour et pouvoir publier des mods rapides à installer et ne cassant pas la compatibilité, je faisais en sorte de rester proche des habitudes de codage de phpBB et de cantonner les modifications à des zones les plus restreintes possibles.

Maintenant comme phpBB2 est en fin de vie, ne bougera plus de masses et sera de moins en moins utilisé, l'intérêt de faire cela s'amenuise. Du coup afin de pouvoir migrer plus progressivement les mods vers quelque chose de plus propre, je pense partir de ma version actuelle et la "démonter" progressivement en re-codant les mécanismes plus proprement, jusqu'à obtenir un script totalement différent et exploitant diverses briques externes telles que PHPTAL.

Cela fera au final probablement plus de boulot mais d'une part pour un résultat qui me conviendra sans doute mieux (puisque codé entièrement selon mes idées) et d'autre part avec des améliorations progressives qui permettront d'avoir en cours de route un résultat utilisable plutôt que de devoir attendre des mois d'avoir rattrapé l'existant...


Rester sur phpBB ?

Cela fait maintenant plus de 5 ans que mes forums tournent sous phpBB2 (et à part EDForum qui a commencé en phpBB1 pour ses premiers mois, je n'ai jamais utilisé que ça).

Ce script étant tout de même en fin de vie avec la sortie prochaine de phpBB3, se pose pour moi (comme pour surement pas mal de monde, vue la popularité de phpBB) la question de savoir vers quoi se tourner pour la suite.

Ayant quelques dizaines de mods plus ou moins imposants à mon actif sur phpBB2, j'ai eu l'occasion d'en relever les limites principales qui sont :

  • un code trop peu orienté objet (après un an passé à coder intensivement en objet au boulot, le retour à une architecture impérative et fortement séquentielle me rebute quelque peu).
  • de trop nombreuses redondances de code.
  • découlant de ces deux premiers points : une grande difficulté à développer des modules approchant un tant soit peu du plug and play.

J'ai donc regardé ce qu'on pouvait trouver actuellement comme scripts de forums pour voir ce qu'on pouvait avoir, puisque quitte à migrer quelques dizaines de mods, autant que ce soit dans de bonnes conditions.

Voilà ce que j'ai brièvement testé :

  1. phpBB3 : fort logiquement j'ai d'abord regardé là puisque c'est la suite logique... Mais même si les fonctionnalités ajoutées sont assez nombreuses et pour certaines vraiment bien pensées niveau interface, niveau code, c'est franchement pas terrible : toujours très séquentiel et pauvre en objets. C'est évidemment bien mieux que phpBB2 globalement mais c'est pas encore ça... Faut dire que les débuts des devs datent de 4-5 ans déjà, donc forcément...
  2. punBB : il a bonne réputation comme étant rapide, donc j'ai regardé un peu... Mais c'est pas mieux que phpBB3, voir moins bien avec un certain nombre de trucs codés en dur que même phpBB2 ne mettait pas en dur... Alors j'ai peut-être raté quelque chose avec le peu de temps que j'y ai consacré mais ça m'a franchement pas convaincu, d'autant que le code n'est pas plus objet que phpBB.
  3. Fire soft board, alias FSB : c'est alors que je me suis souvenu du script développé par Genova (ancien moddeur phpBB2), je suis donc allé voir ce que ça devenait et apparemment il a fait du bon boulot avec sa version 2 (proche de la sortie, puisqu'en RC4 déjà) : il a pensé au développement de mods, codé en objet, tout ça \o/ Apparemment il avait vu les mêmes défauts que moi dans phpBB2... Bref ça m'a l'air pas mal. Puis c'est développé par une équipe francophone pour une fois, ce qui ne gâche rien.

Après ces quelques investigations (pas très poussées, j'en conviens, vu que je n'ai regardé que 3 scripts différents et pas trop en détails...), mon choix se porte plutôt vers FSB. J'ai pas encore vraiment commencé à travailler avec, donc peut-être de mauvaises surprises en perspective... Rendez-vous dans quelques temps pour en savoir plus.


PHPTAL, moteur de templates XML

PHPTAL est un moteur de templates spécialisé dans la production de documents XML (et donc (X)HTML puisqu'il s'agit d'un langage XML).

Les templates qu'il utilise sont définis en XML valide, PHPTAL ajoutant ses propres attributs qui sont ensuite traité par le moteur. Le code des templates est donc purement de l'XML et non un code bâtard XML/PHP comme c'est le cas avec certains autres moteurs.

Avantages :

  • il n'accepte que du code XML valide, ce qui permet de détecter rapidement toute erreur d'imbrication.
  • le code des templates est de l'XML ce qui donne la possibilité de l'exploiter ou de le générer via les bibliothèque de gestion de fichiers XML habituelles.
  • il est installable sous forme de package pear ce qui rend son déploiement et sa mise à jour très simples.
  • comme il est entièrement XML il est en général plus accessible pour le graphiste qui pourra être chargé de construire les templates.

Inconvénients :

  • il ne permet a priori de générer que du code XML (ou de tout langage XML) ce qui peut être limitatif.
  • peut s'avérer limité par rapport à d'autres moteurs pour des traitements complexes.
  • le code des templates n'est pas forcément toujours des plus compacts.

Cela fait quelques mois que je l'utilise au boulot et j'en suis globalement satisfait, du moins dans les cas que j'ai eu à traiter avec... Cela dit je n'ai pas beaucoup expérimenté d'autres moteurs (à part celui de phpBB 2 qui est assez limité).


Mise à jour du 21/10/2018 à 10:56

Mise à jour de l'URL du site de PHPTAL qui a changé entre temps.

SimpleXML et sections CDATA

PHP5 inclut de base la bibliothèque SimpleXML qui permet, comme son nom l'indique de gérer de manière très simple du code XML.

Un point est par contre problématique, la gestion des sections CDATA. En effet, supposons que l'on parte du code XML suivant :

<?xml version="1.0"?>
<root>
	<parent>
		<child>123</child>
		<child><![CDATA[456]]></child>
		<child attr="a"><![CDATA[789]]></child>
	</parent>
</root>

Lorsque l'on récupère les enfants d'un nœud via :

$parentnode->child;

On a la mauvaise surprise de ne pas obtenir tous les nœuds... En effet :

  • le premier passe sans problème, car il ne contient pas de section CDATA.
  • le second contient un CDATA et se perd dans la nature...
  • le troisième contient un CDATA mais a également un attribut, il est alors correctement renvoyé (ne me demandez pas pourquoi).

Par contre, dans le cas où tous les nœuds sont basés sur le modèle du second (CDATA sans attribut), le premier est bien trouvé et retourné (au lieu d'un tableau).

Une fois le problème identifié j'ai fait quelques recherches et j'ai pu trouver cette solution consistant à éliminer les CDATA avant le traitement du code XML. Je ne la trouve pas très satisfaisante mais je n'ai pour l'instant rien trouvé d'autre...


Doublons dans l'historique de commandes

Lorsque l'on travaille sous Linux, on se retrouve souvent à taper un bon nombre de fois les mêmes commandes. Du coup l'historique des commandes (accessible notamment via les flèches) n'est rapidement plus très praticable tant il est redondant.

Pour régler ce genre de problème, on peut utiliser la variable shell HISTCONTROL. Celle-ci peut prendre différentes valeurs :

  • ignoredups :
    lorsqu'une commande est identique à la précédente n'est pas ajoutée à l'historique, ce qui évite de se retrouve avec un dizaine de uptime à la file quand on surveille la charge du serveur.
  • ignorespace :
    lorsqu'une commande commence par un espace, elle n'est pas ajoutée à l'historique, ainsi on peut choisir quelle commande ajouter ou non.
  • ignoreboth :
    cumule les comportements des deux valeurs précédentes.
  • erasedups :
    lorsqu'une commande est tapée, toutes les commandes identiques présentes dans l'historique sont supprimées. Ceci est particulièrement intéressant pour éviter d'avoir son historique parasité par un grand nombre de ls, ps, cd .. et autres commandes courantes.
  • enfin pour revenir au comportement classique, il suffit d'affecter une chaine vide.

Cette valeur peut être affectée de plusieurs manières :

  • pour la session courante uniquement via la commande :
    export HISTCONTROL=valeur
  • pour toutes les sessions, en ajoutant HISTCONTROL=valeur dans votre fichier bashrc
  • pour tous les utilisateurs (uniquement si vous êtes administrateur de la machine, bien entendu) en ajoutant HISTCONTROL=valeur dans le fichier bashrc global trouvable dans /etc.