Geekographie Maïeulesque

Un formulaire d'inscription à une liste de discussion/diffusion avec Formidable

Maïeul — 2014-08-07T13:06:03Z

Certains hébergeurs proposent des services de listes de diffusion / de discussion sans proposer pour autant de formulaire d'inscription aux dites listes. C'est par exemple le cas de TuxFamily ou de Toile-Libre. L'inscription se fait alors par courriel. Il en est cependant possible d'afficher un formulaire d'inscription sur son site SPIP, pour faciliter la vie du public [1].

Du reste, on peut également le souhaiter pour les hébergeurs proposant des listes avec formulaire d'inscription : cela permet d'afficher le formulaire sur son propre site, en gardant ainsi une interface uniforme.

Une manière simple de faire ceci est d'utiliser le plugin nommé à juste titre "Formidable".

1 - Principe de base

Les listes de discussions suivent la norme suivante : une adresse nom_de_la_liste-request@domaine.tld peut recevoir des inscriptions de configuration de la liste. Pour la liste des utilisateurs de eledmac, l'adresse est donc : eledmac-request [arobase] lists.tuxfamily.org.

Il suffit d'envoyer un mail avec la requête comme objet. Dans le cas qui nous intéresse, il suffit de mettre :

subscribe si on veut s'inscrire à la liste
unsubscribe si on veut se désinscrire de la liste.

Évidement, cette email doit être envoyé depuis l'adresse qui souhaite s'inscrire.

Notre formulaire est donc un simple formulaire qui se contente de faire cela... c'est tout.

2 - Création du formulaire

Nous supposons que vous avez installé formidable.

Dans le menu « édition », se rendre dans « formulaires », puis choisir « créer un nouveau formulaire ».

2.1 - Configuration de base du formulaire

Donnez un titre à votre formulaire, un identifiant pour le mémoriser (par exemple « inscription-liste-eledmac »), indiquez un message de retour pour prévenir l'internaute qu'il doit confirmer son inscription via le courriel qu'il recevra, et conservez les autres paramètres.

Validez alors.

2.2 - Création des champs

Vous arrivez alors sur la page d'ajout des champs.

Ajout de champs dans un formulaire

2.2.1 - Champ courriel

Choisissez d'ajouter une « Ligne de texte » en cliquant sur le bouton ad hoc. Votre champ « ligne de texte » est alors ajouté au formulaire. Il vous faut maintenant le configurer en cliquant sur le bouton avec un crayon sur une page.

Bascule vers l'édition d'une ligne de texte

Dans le champ « Description », entrez « Courriel » (ou « email », si vous êtes sur un site anglophone).

Basculez ensuite dans l'onglet « Validation ». Cochez la case « Champ obligatoire », et dans le menu déroulant, choisissez comme vérification « Adresse de courriel ».

Validez ensuite le champ.

2.2.2 - Champ action

Il vous faut maintenant ajouter le bouton radio pour permettre aux utilisateurs de choisir entre l'inscription et la désinscription. Cliquez donc sur le bouton ad hoc, puis éditez le champ, via l'icône avec un crayon sur une page.

Édition des boutons radio

Dans le champ « Label », saissiez « Action » (ou tout autre terme adéquat). Dans « liste des choix possibles », ajouter les lignes suivantes :

subscribe|Inscription unsubscribe|Désinscription

Vous pouvez bien sûr changez « Inscription » / « Désinscription » par tous termes appropriés.

Dans « Valeur par défaut », choisissez « Subscribe ».

Validez ensuite le champ.

2.2.3 - Validation des champs

Il est important de ne pas oubliez de valider les champs, en cliquant sur le bouton en bas de page.

Validation des champs du formulaire

2.3 - Configuration des traitements

Il ne vous reste plus qu'à configurer le formulaire pour qu'il envoie les mails.

Cliquez à gauche sur « Configurez les traitements ». Cochez alors « Envoyez par courriel ». Dans le formulaire qui apparaît alors, remplissez ainsi les champs :

« Destinataires supplémentaires » : mettre l'adresse -request. Par exemple : eledmac-request[arobase]tuxfamily.org (en remplaçant bien sûr le [arobase]
« Courriel de l'envoyeur » : choisissez « Courriel » (étonnant non ?)
Ne pas oubliez de cochez « Insérer le courriel de l'envoyeur dans le champ "From" »
Dans sujet du message, mettre @radio_1@.

À partir de la version 3.7.0 de formidable, il faut aussi cocher la case « Valeurs brutes ». Sinon l'objet du message sera « Inscription » et pas "subscribe.

Options valeur brutes

Validez alors le formulaire.

Il vous reste alors à faire un test, en remplissant le formulaire avec un email, extérieur au domaine de votre site. Par exemple un yopmail.

Il se peut cependant que votre hébergeur refuse d'envoyer de tels courriels depuis votre site. Dans ce cas, il faudra voir avec lui... ou bien tester via un SMTP externe, grâce au plugin facteur.

3 - Insertion du formulaire dans un article

Il ne vous reste plus qu'à insérer le formulaire dans un article, via le raccourci :

4 - Pour allez plus vite

Formulaire d'inscription à une liste de discussion

J'ai exporté mon formulaire en .yaml. Vous pouvez le télécharger, puis l'importer avec le bouton ad hoc.

Importer un formulaire depuis un ficher .YAML

Il vous faut ensuite :

modifier le formulaire, pour lui donner un titre et un identifiant bien à vous.
configurer les traitements, pour modifier l'option « Destinataires supplémentaires ».

[1] Comme je l'ai fait pour la listes des utilisateurs de eledmac.

Succession d'articles avec A2A

Maïeul — 2012-09-13T19:16:57Z

La nouvelle version du plugins A2A permet de typer les relations entre articles. Je m'en sert sur ce site pour créer des succession d'articles, par exemple ma série d'articles sur les stemma.

Comment fais-je ?

Configuration du plugin

Je crée un nouveau type de relation, dont la clef est « Suivant » et le titre est « Article suivant ».

Chaque article de la chaîne, sauf le dernier, est relié à l'article suivant selon ce type.

Voilà pour l'espace privé.

Côté squelettes

Je souhaite afficher l'ensemble des articles de la chaîne dans laquelle se situe l'article courant mais :

En ne mettant pas de lien sur l'article courant.
En mettant un attribut rel=prev ou rel=next pour le liens vers l'article immédiatement précédent/suivant.

Voici comme je procéde, les commentaires suivent.

 #SET{precedent,''} #SET{suivant,''} #SET{succession,#LISTE{#ID_ARTICLE}}  #SET{succession,#LISTE{#ID_ARTICLE}|push{#GET{succession}}} [(#ID_ARTICLE_LIE|=={#_article:ID_ARTICLE}|oui) #SET{precedent,#ID_ARTICLE} ]    #SET{succession,#GET{succession}|push{#ID_ARTICLE_LIE}} #SET{suivant,#ID_ARTICLE_LIE}  #SET{succession,#GET{succession}|push{#ID_ARTICLE_LIE}}     <:geek:succession_article:> :
  {1}} >  [(#EXPOSE|non)] #TITRE [(#EXPOSE|non)]

l. 1 : la boucle englobante du squelette, je masque ici les autres contenus.
l. 2-3 : deux variables dans lesquelles on stockera les numéros de l'article précédent et de l'article suivant.
l. 4 : liste dans laquelle on va stocker les id de chaque article de la chaîne. On initialise la liste avec le numéro de l'article courant.
l. 5 et 11 : on cherche l'article précédent.
l. 6 : on ajoute l'article précédent à la liste des articles de la chaîne, en début de liste.
l. 9 : on indique l'id de l'article immédiatement précédent dans la variable precedent. Notez le test qui permet de jouer avec la récursion de la l. 10 sans changer à chaque fois precedent.
l. 13 à 20 : la même chose que l. 5 à 11, mais pour les articles qui suivent dans la chaîne. Notez qu'on étend la liste vers la fin, et non pas vers le début, comme précédement.
l. 23 à 38 : boucle (ARTICLES) classique, mais on choisit comme < code>id_article ceux listés dans le tableau. Notez que {id_article IN …}. On notera :
- l. 24 : l'utilisation de #EXPOSE pour styler différemment l'article courant, de même l. 25 et 27 pour n'afficher le liens que sur les articles différent de l'article courant.
- l. 25 [ rel="next"(#ID_ARTICLE|=={#GET{suivant}}|oui)] et son comparse [ rel="prev"(#ID_ARTICLE|=={#GET{precedent}}|oui)] qui permet d'ajouter l'attribut rel à la balise , si besoin.

Jeux de squelettes sous forme de plugin pour SPIP 3

Maïeul — 2012-07-23T15:29:48Z

Dans un précédent article, j'expliquais pourquoi et comment distribuer un jeu de squelettes sous forme de plugin. Cet article est une simple adaptation pour SPIP 3.

Les raisons de distribuer un jeux de squelette sous forme de plugin n'ont pas changé : je ne les répète donc pas. En revanche, le passage à SPIP 3 a introduit la transformation de plugin.xml à paquet.xml. Ces changements sont liés à la volonté d'avoir un formalisme plus important et plus propre. Voici donc un fichier paquet.xml minimal pour proposer un jeu de squelettes sous forme de paquet.xml. On lira les spécifications du paquet.xml pour aller plus loin.

 Nom du plugin Nom de l'auteur Licence

Selon la documentation officielle, la compatibilité prend l'une des formes suivantes :

[v1 ;v2] qui correspond à v1 <= SPIP <= v2
[v1 ;[ qui correspond à SPIP >= v1
[ ;v2[ qui correspond à SPIP < v2

et toutes les autres combinaisons avec inclusion ou pas des bornes.

Ainsi pour indiquer une compatibilité sur toute la branche SPIP 3, mettre :

À noter que ni la balise auteur ni la balise licence ne sont obligatoires, et leurs attributs sont facultatifs. En outre, on doit mettre une balise auteur par auteur.

Vous devez choisir entre l'un des trois états du squelette : dev, test, ou stable. Le prefix du squelette doit être parlant mais court. Vous pouvez préciser dans les attributs documentation et demonstration de la balise paquet l'url de la documentation et du site de démonstration.

En ce qui concerne la balise necessite, il faut en mettre une par plugin nécessaire, en mettant comme valeur de l'attribut nom le préfixe du plugin demandé.

Vous pouvez aussi préciser les versions compatibles de ces plugins, via l'attribut compatibilite, ayant la même syntaxe que pour la balise paquet.xml.

Il ne faut pas mettre de numéro de version dans le prefix ni dans le titre : l'attribut version sert à cela. Cette attribut doit avoir la forme x.y.z :

Un changement de X indique un changement majeure (rupture de compatibilité, réorganisation totale du code).
Un changement de Y indique un changement mineure (nouvelle fonctionalité).
Un changement de Z indique une correction de bug.

Il est très fortement demandée de mettre les trois chiffres pour une version d'un squelette.

Le fichier de langue

Avec paquet.xml certains éléments doivent être indiqués dans des fichiers de langue. Ces fichiers doivent être situés dans le dossier lang du plugin, et avoir un nom sous la forme : paquet-{préfixe_du_plugin}_{code_de_langue}.php. Par exemple, pour un jeux de squelette dont le prefix est toto, les chaînes de langues de descriptions du squelette seront à placer dans lang/paquet-toto_fr.php.

Il existe deux chaînes de langues quasi-obligatoires :

 'Description aussi succincte que possible du plugin, pas une documentation.', 'prefix_slogan' => 'Slogan du plugin' ); ?>

Et le fichier `options.php` ?

Dans la précédente version de cet article, je présentais rapidement un fichier options.php recommandés. Ce fichier n'a plus de sens pour une distribution minimale d'un jeu de squelette, puisque SPIP 3 s'occupe automatiquement de supprimer les numéros devant les titres.

Cependant, pour une jeu de squelette propre à votre organisation et non générique, vous pouvez mettre un fichier prefix_options.php afin d'augmenter le quotat de cache, en mettant les lignes suivantes (pour augmenter à 100 Mo le quota de cache :

Vérifier son paquet.xml

On pourra utiliser l'outil de vérification en ligne pour s'assurer de la conformité du fichier paquet.xml.

Sept bonnes pratiques de développement avec SPIP

Maïeul — 2012-01-05T00:39:57Z

Je travaille en ce moment sur un squelette qui n'est pas de moi. Il semble que la personne qui l'a créé n'était pas au courant des bonnes pratiques de développement sous SPIP. Il est vrai que ces bonnes pratiques ne sont pas nécessairement accessibles aux premiers abords de la documentation webmaster de SPIP.

Voici sept règles que je juge indispensables

1. Ne pas mettre de PHP dans les squelettes

Le but de SPIP était de permettre de ne pas avoir à connaître le PHP pour concevoir un site. Tout un système spécifique a été prévu, pour faire des requêtes SQL, mais aussi des tests. C'est parfois perturbant pour les utilisateurs venant du monde PHP.

Mais pour autant, c'est une très bonne pratique de ne quasiment-jamais mettre de PHP dans un squelette. En réalité, c'est une mauvaise pratique d'en mettre.

2. Ne rien mettre dans le dossier IMG

Le dossier IMG ne doit contenir que les images et documents ajoutés par l'utilisateur depuis l'interface privé. En aucun cas il ne doit contenir des images propres aux squelettes, qui doivent se trouver dans le même dossier que les squelettes.

Choisir de mettre les images dans IMG (comme je l'ai vu dans ce squelette), c'est compliquer les réutilisations des squelettes, et mélanger les couches utilisateurs et webmestres de SPIP.

3. Utiliser `#CHEMIN`

La balise #CHEMIN est une balise indispensable de SPIP. Elle permet d'indiquer l'adresse d'un fichier sans se préoccuper du nom du dossier parent. En effet, SPIP va cherche le fichier passé en argument dans l'ordre suivant [1] :

squelettes
plugin B dépendant du plugin A
plugin A
squelettes-dist
prive
ecrire

Exemple : j'ai une image dans le dossier squelettes, je ne fais pas :

mais bien

mieux, je met mon image toto.png dans le dossier img du dossier squelettes.

Je peux alors faire :

L'avantage d'un tel système est évident : permettre d'avoir un dossier squelettes qui ne s'appelle pas squelettes, par exemple lorsqu'on utilise ma sixième recommandation : les squelettes sous forme de plugins. Mais aussi permettre à SPIP de gérer correctement les URLS arborescentes (le cas échéant).

4. Utiliser `|balise_img`

Il est recommandé lorsqu'on insère une balise de lui mettre des attributs height et with pour améliorer les performances du navigateur lors de l'affichage de la page.

On peut bien sûr indiquer cela manuellement :

Mais supposons que je réduise la taille de toto.png : je dois dans ce cas modifier les attributs height et width à chaque fois que je l'utilise.

Pour éviter cela, SPIP prévoit le filtre |balise_img qui, lorsqu'il est appliqué au chemin d'un fichier image, crée automatiquement la balise , avec la hauteur et la largeur du fichier. Ainsi, pas besoin de corriger si on réduit la taille du fichier.

Le filtre s'utilise de manière très simple :

[(#CHEMIN{toto.png}|balise_img)]

On peut même mettre en argument le contenu de l'attribut alt

[(#CHEMIN{toto.png}|balise_img{0+0})]

Voir en deuxième argument la valeur de l'attribut class :

[(#CHEMIN{toto.png}|balise_img{0+0,blague_pour_enfants})]

Ce code au final me produit :

5. Utiliser les chaînes de langues

Bien que cela puisse paraître inutile et fastidieux pour un site monolingue, utiliser les chaînes de langue est quand même utile pour trois raisons :

on ne sait jamais : si le site devient multilingue, c'est toujours cela de fait.
il est plus facile d'uniformiser les textes.
il est plus facile de corriger en cas de faute ou de changement d'avis.

6. Utiliser

C'est un principe de base de l'informatique : dès qu'une séquence d'instructions est utilisée plusieurs fois, il faut non pas la dupliquer, mais la mettre dans un morceau qu'on appelle plusieurs fois.

En SPIP ce morceau, c'est un fichier inclus.

Typiquement supposons que j'affiche sur toutes les pages de mon site les sites amis.

Au lieux de copier-coller le code suivant dans les squelettes :

   #NOM

Je le met dans un fichier sites-amis.html, situé dans un dossier inclure du dossier contenant les squelettes.

Et je met le code suivant là où je souhaite afficher les sites amis :

Cela me permet si je dois modifier les critères de cette liste de ne les modifier qu'à un endroit [2].

La logique est donc : diviser son site en briques réutilisables. Chaque brique correspondant à fichier et à un morceau logique de page. Ensuite assembler ces briques dans des fichiers plus globaux [3].

Le modèle de squelettes Z pousse à l'extrême cette logique des inclusions. Je conseille de le suivre : on gagne largement en maintenance ce qu'on perd en temps d'apprentissage initial.

Une règle importante dans les inclusions : les balises html qui s'ouvrent dans un fichier doivent se fermer dans le même fichier. Il est très mauvais d'ouvrir une balise dans un fichier puis de la fermer dans un autre : on y est perd en lisibilité du code, et donc en maintenance [4].

7. Mettre ses squelettes sous formes de plugins

Cela peut paraître un luxe ou coquetterie, mais cela facilite énormément le déploiement d'un même squelette sur plusieurs sites ou le déménagement depuis la version locale vers la version en ligne :

en indiquant les dépendances aux plugins.
en incluant le fichier mes_options.php dans le même dossier.
en permettant même le cas échéant d'ajouter automatiquement un contenu pré-défini.

Un précédent article détaille comment fabriquer ces squelettes-plugins.

Amis SPIPeurs, j'attends vos remarques et ajouts !

[1] Liste tirée du site Programmer avec SPIP.

[2] En outre, cela diminue les requêtes SQL et donc la charge du serveur SQL, mais la contrepartie est de multiplier les fichiers de caches ainsi que les inclusions PHP.

[3] Pour comprendre comment passer des paramètres lors de ces inclusions, pour par exemple connaître l'article courant, je renvoie à mon article sur la balise #ENV. Cet article devrais être mis à jour pour parler des dernières nouveautés. Mais l'essentiel est là.

[4] J'ai crû à un moment qu'une structure html était incorrecte du fait qu'un fichier avait plus de

ouvrantes que fermantes. En réalité, le dernier

manquant se trouvait ailleurs.

Vous pouvez utiliser (C)Keditor

Maïeul — 2011-02-20T12:50:17Z

Il y a quelque temps, j'avais posté un message extrêmement critique vis à vis de de (F)CKeditor. Je révise ici mon jugement, suite au dernier article publié sur Contrib.

Je continue à penser que (F)Ckeditor est une mauvaise idée parce qu'il incite à penser forme et non sens. Je continuer à penser que l'apprentissage des raccourcis typographiques de SPIP a plus de sens, même si cela peut prendre un peu plus de temps (et encore).

Pour autant, la dernière contribution enlève une de mes critiques majeures, en fait ma critique majeure, à savoir que (F)Ckeditor produit du HTML et non pas du code SPIP.

En effet, il est désormais possible de dire à (F)Ckeditor de produire du SPIP et non pas du HTML. Ce qui à l'avantage :

de permettre une conversion plus simple vers d'autres formats.
de permettre de se passer de CKeditor le cas échéant.
de pouvoir utiliser les crayons.

Je n'ai pas testé, mais je fais confiance à l'auteur de l'article. Reste à savoir comment nettoyer une base qui a été salie par les anciennes versions du plugin.

N'utilisez pas (F)CKeditor !

Maïeul — 2011-01-30T19:11:58Z

Les différentes variantes du plugin (F)CKeditor de SPIP ont un certain succès. Ainsi, si j'en crois le site des statistiques SPIPiennes, près de 11% des sites SPIP l'utiliseraient, ce qui prouve qu'il y a demande.

Pourtant, c'est un très mauvais choix technique. L'expérience que j'ai eue avec tous ceux qui l'ont installé me le confirme : s'il semble plus pratique au début, il entraîne rapidement des soucis.

Une confusion des genres

Pourquoi utiliser ce plugin ? Deux raisons sont principalement évoquées :

permettre aux utilisateurs de ne pas avoir à apprendre les raccourcis typographiques de SPIP.
permettre aux utilisateurs de personnaliser l'apparence de leur article.

Je passe sur la première raison, étant donné que je dirais quelques alternatives.

La seconde raison est très mauvaise :

Elle incite à confondre sens et manière de présenter.
Elle incite à se concentrer non pas sur le contenu d'un article, mais sur la manière dont il sera présenté.
Elle a pour conséquence, bien souvent, d'obtenir un site dont l'unité graphique n'est plus assurée, ce qui produit au mieux des chocs visuels, au pire des crises d'épilepsies.

Autrement dit, elle rend inutile le travail du toilemestre. Elle rend même inutile la logique d'un CMS, puisqu'un CMS est là justement pour distinguer le travail de rédaction, qui relève des rédacteurs (si si !) et celui de présentation du contenu, qui relève du webmestre.

Ainsi une des conséquences pourra être que le rédacteur confonde, par exemple un intertitre et un texte « grosse police rouge ».

Une base de donnée bousillée

Ce type de plugins n'utilise pas les raccourcis typographiques de SPIP, mais introduit directement du HTML dans la base de donnée.

Conséquence :

un HTML bien souvent foutoir et illisible, impossible à « épurer » simplement, par exemple le jour où l'on décide d'avoir un site à l'allure cohérente.
l'absence d'abstraction entraîne une conversion plus difficile vers des formats autres que le HTML (LaTeX, XML et j'en passe).
l'absence d'abstraction rend tout changement beaucoup plus complexe.

Exemple du troisième point : alors que le système des documents de SPIP affecte un numéro à chaque document, numéro qui est appelé dans le texte grâce au raccourci . Il est ainsi possible d'appeler plusieurs fois un même document dans divers articles, puis de modifier une seule fois ce document et que cela se répande sur tous les articles. ~~Ce n'est pas du tout possible avec FCKeditor~~. En fait c'est possible avec la dernière version du plugin. Si le plugin s'améliore afin d'utiliser les raccourcis de SPIP et non pas du HTML, ma critique tombera à l'eau.

La perte des crayons

Et oui, il est impossible d'utiliser avec cela le plugin Crayons. Or ce plugin est incontestablement un très bon plugin et une aide précieuse pour le maintien d'un site, puisqu'il permet d'éditer le contenu sur le site public.

Si on essaye de crayonner un article créé avec CKeditor, on obtient alors une catastrophe, puisque le HTML apparaît dans le formulaire.

Quelles alternatives ?

Apprendre les raccourcis typographiques de SPIP n'est pas la mer à boire et permet aussi de se concentrer sur le sens. On pourra même obtenir un tableau récapitulatif : http://www.uzine.net/IMG/pdf/doc-273.pdf. Et le temps pour un webmestre de formation des rédacteurs sera largement compensé par le non-temps passé à démêler le HTML produit par CKEditor.
On pourra utiliser le porte-plume qui offre une barre typographique produisant des raccourcis SPIP, propre. Et les extensions du porte-plume permettront de combler certains manques.
On pourra également utiliser le plugin Odt2SPIP qui permettra de convertir un fichier Openoffice structuré selon le sens en article SPIP.
Pour la gestion des documents, on utilisera avec pertinence le plugin médiathèque, éventuellement en conjonction avec la Médiabox.

Cet article aurait pu être publié sur Contrib … mais celui-ci n'a pas pour but d'engendrer une polémique.

On lira également mon article suite aux modifications apportées dans le code de (F)CKeditor.

Afficher plusieurs fois un même objet SPIP

Maïeul — 2010-12-19T22:11:04Z

Dans le cadre d'un projet associatif, je me sert de SPIP pour gérer une base de donnée. Cette base de donnée contient un certain nombre d'objets — des cartes de jeux en fait, que j'ai « traduites » en SPIP par des articles — que j'ai besoin d'afficher plusieurs fois. Le nombre d'affichages nécessaires est propre à chaque cartes / articles.

Pour arriver à mes fins, voici comment j'ai fait :

J'ai ajouté un champ extra nombre à la table articles.
Dans ce champ je précise le nombre de fois où je souhaite afficher un article. C'est donc un champs de type INT.
J'utilise ensuite le plugin SPIP-Bonux pour boucler sur un tableau PHP que je génère grâce à la fonction array_fill() de PHP. Ce tableau contient #NOMBRE fois la valeur ''.
A l'intérieur de cette boucle, je peux récupérer les informations de l'article directement avec les balise #CHAMP dont SPIP reconnaitra qu'elle font allusion à la boucle « mère ».

Cela nous donne donc :

  J'affiche le titre de l'article #TITRE qui porte le numéro #ID_ARTICLE etc.

Le code exposé ici n'est pas tout à fait celui que j'utilise pour mon projet, car dans celui-ci je dois mélanger de manière aléatoire les différents articles. Je passe donc par un tableau global que je remplis des valeurs des #ID_ARTICLE le nombre de fois nécessaires.

Notifications sur un forum plat

Maïeul — 2010-12-17T10:17:40Z

Sur ce site j'utilise le plugin Notifications, pour que les personnes reçoivent les réponses à leurs réactions.

J'ai coché dans la configuration « Fil de discussion : les participants au même fil de discussion reçoivent les notifications des forums (publics). ». Mais les personnes ne recevaient pas les notifications. Voilà comment j'ai résolu le problème.

Le problème, c'est que mes forums sont en mode {plat} [1]. Donc il n'y a pas vraiment de fil de discussion, mais seulement des messages individuels sans liens, du coup notification ne peut fonctionner.

La solution est de s'arranger pour avoir un fil de discussion unique.

Pour cela, j'appel de la manière suivante le formulaire de réaction :


#FORMULAIRE_FORUM

#FORMULAIRE_FORUM

Ainsi, le message est systématiquement posté en réaction au dernier message, et s'il n'y a pas de message, il est posté directement en réaction à l'article, et un fil de discussion est ouvert.

[1] En fait j'utilise le plugin de Romy : Comments, qui met ce mode {plat}

Jeux de squelettes sous forme de plugin

Maïeul — 2010-12-05T15:08:14Z

Pourquoi mes squelettes sont-ils désormais entièrement sous forme de plugin ? Pourquoi n'utilise-je plus la technique classique, à savoir un dossier /squelettes à la racine de SPIP ? Pourquoi fais-je un squelettes sous forme de plugin ?

En dehors des squelettes génériques, il est utile maintenant de faire tout ses jeux de squelettes sous forme de plugin.

Pourquoi faire ?

Avoir un seul dossier qui contient les squelettes et le fichier d'options. Plus besoins d'avoir un fichier mes_options.php à part.
Disposer de la syntaxe du fichier plugin.xml pour dire les dépendances du squelettes.

Comment faire ?

Créer un dossier dans lequel vous mettrez l'ensemble de vos squelettes (comme vous faisiez classiquement avant).
Si vous êtes sous SPIP 3, reportez à l'article correspondant au paquet.xml, sinon continuez votre lecture.
Dedans y mettre le fichier plugin.xml prochainement. Cet article pourra être périmé le jour où vous le lirez.]] suivant :

 NomSquelette squelette  Votre nom  0.1 stable  Un descriptif autant complet que possible, utilisation de la syntaxe spip autorisée. prefix prefix_options

Mettez autant de nécessite que de plugin nécessaire. Attention la valeur de l'attribut id est le prefix du plugin (dans son fichier plugin.xml) pas son nom.

Remplacez prefix par un préfixe à vous. A titre d'exemple, le plugin.xml du squelette de ce site.

Dans le fichier prefix_options.php, mettez les lignes suivantes [1] :

Cela supprimera automatique les numéros dans les titres d'articles, dans les noms d'auteurs etc. La valeur de $GLOBALS['quota_cache'] est par défaut à 10 (Mo) mais si vous utilisez un squelette de type Z, ce n'est pas assez.

Copiez le dossier ainsi créé dans le dossier de plugin. Activez depuis l'espace privé de SPIP ce plugin.

Si vous avez peur que quelqu'un désactive ce plugin et mette en l'air la présentation plugin, vous pouvez à partir de SPIP 2.1 mettre dans le dossier extension, ce qui rendra non désactivable le plugin/squelette.

Pour la syntaxe complète du fichier plugin.xml c'est par là : http://doc.spip.org/@Plugin-xml

[1] Voir aussi mon précèdent article.