SpipBB - GaFoSpip et la gestion de forums avec SPIP

Informations générales

Comme vous le saviez peut être nous avions relancé le plugin SpipBB pour qu’il soit compatible avec SPIP v 1.9.2 et prochainement 1.9.3 . En parallèle pouvait se poser la question du travail fait aussi par Scoty pour GaFoSpip et ses contributeurs pour le plugin du même nom, issu lui aussi de SpipBB. Après échanges, voici ce que nous avons pu établir :
-  a priori une volonté commune de fusionner notre travail, chacun ayant apporté des fonctionnalités et des idées intéressantes.
-  qu’il sera plus efficace de mettre en commun nos efforts.
-  devoir adapter notre mode de travail pour être plus cohérents et surtout arriver à travailler de concert, ce qui est loin d’être aussi simple qu’il n’y parait :-)
-  faire appel à toutes les bonnes volontés pour nous donner un coup de main. Entre celles et ceux qui pourraient « juste tester/essayer » pour « voir si ça marche » et les autres qui peuvent apporter tant du point de vue design que du point de vue du code. Ce qui implique donc que nous continuerons à travailler sur la Zone et donc pour certains de gros efforts pour s’y adapter.
-  de rester adapté aux novices de Spip et aussi à ceux qui le tordent dans tous les sens ;-)

Le déroulement :

1. Première grosse étape, fusionner les deux pour en faire un plugin « unique ». Scoty et moi-même allons essayer de faire cela rapidement en fonction de nos disponibilités (sur notre temps libre).
2. Travailler sur les fonctionnalités existantes ou à venir que nous envisageons (cf ci-dessous). Certaines existent déjà (plus ou moins) d’autres sont à venir (on le souhaite).
3. Éventuellement trouver un nouveau nom à ce futur plugin, héritier de ses prédécesseurs (et du travail de la SpipBB team) mais pas seule

Le planning :

Quand ça sera prêt. Si vous voulez que ça aille plus vite, venez nous aider :)

Installation / activation

• un processus d’installation du plugin qui ne soit pas « 100% automatique mais 100% automatisé » : une fois le plugin activé, l’administrateur doit valider les éléments qu’il veut utiliser ou non (partie publique/privée, les outils disponibles, les paramètres spécifiques comme les informations sur les auteurs, la lutte contre le spam, etc etc). Le tout centralisé sur une page de configuration qui reste le point de passage obligé tant que cette étape n’a pas été réalisée (a priori une fois pour toutes).

Interface privée

• dans l’interface privée, une gestion/administration qui peut s’appliquer à tous les forums du site, ce de façon indépendante de l’interface publique. Ce qui signifie que si seule la partie « modération » (ou autre) vous intéresse, vous n’êtes pas obligé d’activer l’interface publique et garder le fonctionnement propre à votre site.
• les fonctions de l’interface vues de façon modulaire, pouvant être globalement activées ou désactivées par l’administrateur. Ceci facilitant aussi l’ajout de fonctions plus « personnelles ».
• une volonté de dissocier code / squelette tant du point de vue de l’interface publique que privée. Pour info, dans l’interface publique il restait (de façon historique) des portions de PHP mélangées aux squelettes. Du côté de l’interface privée, si la présentation ne convient pas ou qu’un contributeur veut l’améliorer, pas de nécessité de maîtriser le PHP, les pages sont des squelettes HTML comme les autres.
• une interface privée d’administration qui permette de façon centralisée de :
  • gérer les forums d’un seul tenant,
  • organiser la rubrique/secteur forums (ordre de présentation, ajouts/ suppressions de catégories, de forums)
  • gérer les auteurs/visiteurs (dernières contributions, listes des messages, etc)
  • gérer les fils de discussions (les déplacer, les diviser, les fermer, les supprimer en bloc ou partiellement)
  • gérer le spam que ce soit des mots / expressions sur la publication (modération a posteriori), du nombre de messages publiés ou d’autres critères (comme l’adresse d’inscription, le domaine , etc etc) au d’autres critères de spam envisageables (URLs publiés par exemple). Avec différents niveaux d’action possibles.
  • des outils plus spécifiques (comme par exemple la migration d’autres forums non SPIP dans spip).
  • gérer des « niveaux » d’utilisateurs (mesures de « qualité » et de quantité) pouvant apparaître dans l’interface publique. Pouvant faire apparaître différemment ceux qui publient beaucoup des autres, ou ceux dont les réponses ont été qualifiées intéressantes des autres.
  • choisir la présentation parmi celles proposées (ou d’activer sa propre feuille de style bien sur).

Interface publique

• On reste a priori sur une structure d’interface associée à une rubrique/secteur associée aux forums dédiés. Dedans on pourra continuer à créer des rubriques/catégories qui contiendront les différents forums, les articles créés au sein de ces sous-rubriques ouvriront des forums.
• Des articles avec un mot clé spécifique pourront aussi être utilisé pour créer des forums d’annonce ou de FAQ par exemple où seuls les modérateurs (auteurs/rédacteurs) pourront ajouter/éditer des commentaires/informations.
• Des éléments qui sont disponibles en fonction de la configuration choisie par l’administrateur, par exemple des boutons RSS, l’affichage/utilisation d’avatars, abonnement/désabonnement au suivi du forum.

Les autres plugins requis/compatibles

• S’appuyant sur les données de session des auteurs, les pages publiques requièrent en 1.9.2 le plugin BALISE_SESSION (en 1.9.3 c’est/ce sera intégré dans le noyau de SPIP).
• De même pour le moment, le plugin s’appuie sur la balise CONFIG et les fonctions associées (lire_config), requiert donc CFG, sans toutefois en utiliser la partie interface privée (utilisant fonds/ notamment).
• La volonté de faciliter la coexistence avec d’autres plugins pour gérer notamment les droits des utilisateurs, les informations sur les auteurs etc. Ce qui implique par exemple le choix possible (configuration) entre l’utilisation du champ EXTRA (pour les auteurs) ou une table de la base de données (et les champs associés).