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.

Le débugage des JavaScript sous Firefox

Cet article est marqué comme contenant des informations dépassées depuis le 21/10/2018.
Ces extensions n'existent plus, remplacées par les outils de développement natifs de Firefox.

Pour le débugage JavaScript, Firefox dispose de base d'une console d'erreurs JavaScript. Cette console est accessible via le menu « outils » sous le nom « console d'erreur » et liste trois types d'informations :

  1. les erreurs : il s'agit des erreurs que Firefox ne parvient pas à traiter et qui entrainent un arrêt pur et simple de l'exécution du script. Ces erreurs doivent être corrigées impérativement pour que le script s'exécute jusqu'au bout.
  2. les avertissements (warnings) : ceux-ci ne sont pas bloquants. Ils relèvent juste une erreur minime ou un non-respect de la norme javascript (variable non-déclarées, fonctions ne retournant pas toujours de valeur, etc.). Il n'est pas absolument nécessaire de les corriger mais il vaut mieux les corriger et ce pour deux raisons : d'une c'est par principe toujours mieux de coder proprement et de deux ils peuvent être cause de bugs puisque le script ne se comportera pas forcément de la façon dont vous l'imaginiez.
  3. les messages : il s'agit de simples messages qui peuvent être envoyés depuis du code javascript dans certains cas. Il ne s'agit pas d'erreurs, juste d'informations diverses en général utilisés lors du débugage d'extensions.

La plupart des messages d'erreur ou d'avertissement sont accompagnés d'un numéro de ligne, d'un nom de fichier et d'un lien direct pour visualiser la ligne posant problème.

De base cette console est déjà très efficace (comparée à son homologue sous IE, c'est déjà le jour et la nuit). Cependant il existe également des extensions qui peuvent permettre d'aller plus loin :

  • Prévisualisation - Console²
    Console² :
    Cette extension permet de filtrer plus précisément les messages affichés par la console. Elle permet également le passer le contrôle en mode « strict » ce qui augmente le nombre d'avertissements en cas de non-respect des normes. Elle permet également d'afficher certaines erreurs dans les fichiers CSS et XML évalués par le navigateur.
  • Prévisualisation - Firebug
    Firebug :
    Celle-ci permet de faire pas mal de chose en ce qui concerne le débugage aussi bien JavaScript que CSS et HTML. Elle semble notamment permettre une exécution pas à pas du JavaScript. Je ne l'ai pas testée très en détails, peu convaincu au premier abord... Cependant elle semble avoir bonne réputation, il doit donc y avoir de bonnes choses à en tirer.

Et IE dans tout ça ? Ben là c'est pas la joie... Outre le fait que son moteur JavaScript n'a quasiment pas bougé depuis IE6, ce qui implique un retard énorme, sa fenêtre d'erreur est des plus minimalistes. Elle se limite en effet à un message d'erreur rarement clair et pas toujours approprié, un numéro de ligne approximatif et aucun nom de fichier (cela ne pose pas de problème pour un script simple sur un seul fichier mais pour quelque chose de plus complexe répartit en plusieurs fichiers, c'est déjà beaucoup plus gênant)... Une fois de plus le navigateur de Microsoft est largement à la traine.