ComBack : conception

Mon dernier billet présentait le plugin ComBack pour DotClear qui permet aux auteurs d’un blog de répondre aux commentaires de leurs visiteurs. Pourquoi avoir créé une nouvelle table ? Pourquoi un nouvel écran de gestion ? Pourquoi le ciel est bleu ? Autant de questions brûlantes qui trouvent leur réponse ici (sauf une)…

Analyse de l’existant

• Côté blog l’affichage des commentaires déjà postés est fait dans le thème :
  • list.php (liste des billets) qui affiche le nombre de comms pour chaque billet via dcPostNbComments()
  • post.php (affichage d’un billet) qui parcourt les commentaires (while ($comments->fetch())) et affiche les différents éléments dcComment*() correspondant à chacun : ID, Date, Time, Author, Content
• Côté admin les écrans de gestion des commentaires sont sous ecrire/ :
  • comments.php (liste des commentaires) qui récupère le nombre de commentaires ($blog->getNbComments()) pour faire la pagination, ainsi que la liste complète ($blog->getComments()), et leur contenu ($comments->getData()), qu’il affiche pour chacun (ligne_comment())
  • poster.php (édition d’un billet) qui récupère les commentaire du post ($blog->getComments()), les affiche (showComments()) avec pour chacun : auteur, date, mail, site, IP, contenu, et liens de mise en/hors ligne, de suppression, et de modification. Cet écran permet également d’ajouter un commentaire. Et c’est lui qui gère la suppression des comms ($blog->delComment()) et leur mise en/hors ligne ($blog->statusComment())
  • comment.php (modification d’un commentaire) affiche les différents champs du comm dans des zones éditables (sauf IP et date) et permet d’enregistrer ou supprimer le comm

Limitations des plugins dotclear

Un plugin dotclear ne permet pas de modifier les écrans d’administration, simplement d’en ajouter de nouveaux. Toucher aux fichiers existants, les fichiers core, serait une plaie pour la maintenabilité.

Stockage des commentaires

Les commentaires sont stockés dans la table dc_comment :

• comment_id (int(11)) : ID unique du commentaire, non affiché
• post_id (int(11)) : ID du billet
• comment_dt (datetime) : date de création du comm
• comment_upddt (datetime) : date de modification du comm
• comment_auteur (varchar(255)) : nom du commentateur
• comment_email (varchar(255)) : son mail
• comment_site (varchar(255)) : sa page
• comment_content (longtext) : texte du commentaire
• comment_ip (varchar(15)) : IP du commentateur
• comment_pub (int(1)) : en/hors ligne
• comment_trackback (int(1)) : trackback ou commentaire

Cette table sert également à stocker les trackbacks, identifiés par un comment_trackback à 1 contre 0 pour les commentaires. Ces trackbacks sont créés lorsqu’un billet externe possède un lien vers notre billet. L’auteur du trackback est le titre du blog externe, le site est l’adresse du billet externe, le contenu est son titre et ses premiers mots. Ces trackbacks sont extraits des listes de commentaires avant de les lister (fonction extractTrackbacks()).

Autres contraintes

En tant qu’utilisateur, si un jour je décide de retirer le plugin ComBack, j’aimerais que mes réponses ne soient pas tout à fait perdues. Cela m’aurait orienté plutôt vers l’utilisation des commentaires pour gérer les réponses que vers la création d’un nouvel objet. Mais alors pour adapter par exemple le comptage des commentaires (qui ne doit pas prendre en compte les réponses) j’aurais dû redéfinir des fonctions existantes : incompatible avec une maintenabilité satisfaisante…

De plus, l’utilisation des formulaires existants pour les commentaires est problématique car il ne faut pas que n’importe quel visiteur puisse pourrir les commentaires en ajoutant des réponses. Et utiliser des champs réservés comme comment_trackback va encore à l’encontre de la maintenabilité.

Conclusion

Ces points font que j’ai finalement choisi de gérer les réponses séparément des commentaires. Si quelqu’un veut retirer ComBack et récupérer le contenu des réponses, il pourra faire un script de migration.