LapSuske

Afficher directement l'article unique d'une rubrique

François Rygaert (aka Suske) — 2012-03-24T16:21:00Z

C'est parfois un problème avec SPIP : on crée une rubrique pour un seul article, afin que les choses soient bien rangées. Mais du coup, les visiteurs doivent cliquer et recliquer pour rien. Sur SPIP-Contrib, dans ce cas-là, la page de l'article unique est affichée directement. Voici comment.

Le code utilisé sur SPIP-Contrib est visible sur la zone : http://zone.spip.org/trac/spip-zone.... Il contient quelques critères dont nous n'avons pas besoin pour un cas général. Nous les enlevons donc, ce qui donne :

#SET{normale,' '} [(#REM) test sur presence sous-rubriques] <BOUCLE_test_sousrubrique(RUBRIQUES){id_parent}{0,1}> </BOUCLE_test_sousrubrique> <BOUCLE_articles_unseul(ARTICLES){id_rubrique}{pagination 1}> [(#GRAND_TOTAL|=={1}|oui) <?php include_spip('inc/headers'); redirige_par_entete('[(#URL_ARTICLE|texte_script)]'); ?> [(#SET{normale,''})] [(#REM) reinjecter l'id_article dans le contexte pour les stats] ] <?php if ('#GRAND_TOTAL'=='1') $GLOBALS['contexte']['id_article'] = intval('[(#ID_ARTICLE)]'); ?> </BOUCLE_articles_unseul> <//B_test_sousrubrique> <BOUCLE_principale_rubrique(RUBRIQUES){id_rubrique}>[(#GET{normale}|oui)<INCLURE{fond=structure}{env}{type=rubrique}{composition} />]</BOUCLE_principale_rubrique>

Explication :
– lignes 1 : on définit une variable locale "normale", qui servira a lancer le squelette "normal" si la rubrique appelée contient au moins une sous-rubrique ou plus d'un article.
– lignes 3 : tester s'il existe au moins une sous-rubrique de la rubrique appelée. Si c'est le cas, la BOUCLE_articles_unseul ne sera pas exécutée vu qu'elle est dans la partie alternative de la BOUCLE_test_sousrubrique.
– ligne 4 à 12 si la BOUCLE_test_sousrubrique est vide, BOUCLE_articles_unseul est exécutée. Elle liste les articles de la rubrique. Si leur nombre est égal à 1 (l.5), la fonction SPIP redirige_par_entete est appelée et le navigateur est renvoyé directement sur la page d'article (code 302). On vide la variable "normale" et on s'occupe des statistiques de visite.
– ligne 13 : voici le marqueur qui indique que ce qui précède est à exécuter si la boucle principale ne renvoie rien
– ligne suivante : une dernière boucle sur la rubrique appelée, qui lance en l'occurrence la mécanique de ZPIP si et et seulement si la variable "normale" est positionnée (donc, qu'on a au moins une sous-rubrique ou plus d'un article).

De manière générale, le php n'est pas à utiliser dans les squelettes. On constate ici qu'il est utilisé uniquement pour faire appel à des fonctions ou globales de SPIP, je suppose que c'est ce qui rend cet usage acceptable.

Voilà, voilà. Bon SPIP !

Chapitre 1er : plugin.xml, pipelines, CFG

François Rygaert (aka Suske) — 2012-03-23T19:03:55Z

Premier étape du chantier, en regarder les bases : les fichiers situés à la racine du plugin. Je vais regarder, et toucher (mais peu, je ne sais même pas vraiment où je vais). On va donc commencer par les fichiers à la racine : plugin.xml et bisous_pipelines.php

Plugin.xml

SPIP 3 marquera l'abandon progressif de ce fichier de déclaration de plugins, au profit d'un autre nommé paquet.xml. Le plugin "Plugonet" facilite la création de paquet.xml, nous y reviendrons plus tard. Dans l'immédiat, regardons de quoi se compose le plugin.xml de Bisous pour SPIP 2 et voyons ce qu'il y a à y changer.

<plugin> <nom>SPIP Bisous !</nom> <auteur>RastaPopoulos</auteur> <licence>GPL</licence> <version>0.2.0</version> <version_base>0.2</version_base> <etat>dev</etat> <description>Vous êtes en colère ? Il vous faut des bisous ! Vous êtes content ? Il vous faut des bisous !</description> <lien></lien> <!-- URI de documentation --> <prefix>bisous</prefix> <icon>images/amour.png</icon> <install>base/bisous_installation.php</install> <pipeline> <nom>declarer_tables_interfaces</nom> <inclure>base/bisous_tables.php</inclure> </pipeline> <pipeline> <nom>declarer_tables_principales</nom> <inclure>base/bisous_tables.php</inclure> </pipeline> <pipeline> <nom>affiche_gauche</nom> <inclure>bisous_pipelines.php</inclure> </pipeline> <necessite id="SPIP" version="[2.0.0;2.1.99]" /> <categorie>communication</categorie> </plugin>

Commentaires :
– Ligne 5 : le numéro de version du plugin est bien entendu un élément crucial pour la bonne information du webmestre. Jusqu'à l'apparition du plugin STEP pour SPIP 2.1, ce numéro n'était pas utilisé dynamiquement en spip. Dans SPIP 3, l'interface de gestion des plugins fera usage de cette donnée pour gérer les mises à jour, les dépendances, etc. Ce numéro doit avoir la forme X.Y.Z. Si je faisais une évolution du plugin existant, je devrais l'incrémenter en Z, au minimum mais je crois que ce n'est pas nécessaire vu que je crée une version spécifique pour SPIP 3 [1]
– Ligne 6 : le numéro de version de la base doit être incrémenté, en cas de modification de la base de donnée par le plugin. Son incrémentation déclenche les actions ad hoc de SPIP.
– ligne 10 : Outre son utilisation nécessaire dans les noms de fonctions, etc., à partir de SPIP 3, c'est le préfixe qui détermine l'unicité du plugin pour le serveur de plugins.
– lignes 12 à 20 : la mécanique d'installation et de fonctionnement des tables du plugin, c'est pour plus tard peut-être.
– lignes 21 à 24 : le pipeline "afficher_gauche" définit un affichage dans la colonne de gauche de l'espace privé. Comme perso j'aime l'affichage en 3 colonnes du privé et que la droite est souvent oubliée, je vais mettre "afficher_droite". Par ailleurs, le contenu de cet affichage est défini dans le fichier bisous_pipelines.php, ça tombe bien on ira y jeter un œil tout à l'heure.
– ligne 25 : pour que ce plugin s'installe sous SPIP 3, il faudra adapter ça : je mets
– ligne 26 : la catégorie est désormais nécessaire pour pouvoir mettre un peu d'ordre dans la gestion des plugins, tant dans SPIP que sur le serveur de plugins

Ajout supplémentaire :
– Il est désormais prévu pour chaque plugin un "slogan" qui définit en quelques mots l'utilité du plugin. J'ajoute une ligne comme ceci, sous le nom : Embrassez-vous !

Mon plugin.xml pour SPIP 3 ressemble donc désormais à ceci :

<plugin> <nom>SPIP Bisous !</nom> <slogan>Embrassez-vous !</slogan> <auteur>RastaPopoulos</auteur> <licence>GPL</licence> <version>0.2.0</version> <version_base>0.2</version_base> <etat>dev</etat> <description>Vous êtes en colère ? Il vous faut des bisous ! Vous êtes content ? Il vous faut des bisous !</description> <lien></lien> <!-- URI de documentation --> <prefix>bisous</prefix> <icon>images/amour.png</icon> <install>base/bisous_installation.php</install> <pipeline> <nom>declarer_tables_interfaces</nom> <inclure>base/bisous_tables.php</inclure> </pipeline> <pipeline> <nom>declarer_tables_principales</nom> <inclure>base/bisous_tables.php</inclure> </pipeline> <pipeline> <nom>affiche_gauche</nom> <inclure>bisous_pipelines.php</inclure> </pipeline> <necessite id="SPIP" version="[3.0.0-dev;3.0.99]" /> <categorie>communication</categorie> </plugin>

Rest à faire : Passer ça en paquet.xml, PlugOnet nous y aidera (plus tard).

Attaquons-nous maintenant à ce fameux bisous_pipelines.php.

bisous_pipelines.php

La version SPIP 2 est la suivante :

<?php function bisous_affiche_gauche($flux){ include_spip('inc/presentation'); include_spip('public/assembler'); if ($flux['args']['exec'] == 'auteur_infos'){ $flux['data'] .= debut_cadre_relief('',true,'',_T('bisous:bisous_donnes')); $flux['data'] .= recuperer_fond('prive/bisous_donnes',array('id_auteur'=>$flux['args']['id_auteur'])); $flux['data'] .= fin_cadre_relief(true); $flux['data'] .= debut_cadre_relief('',true,'',_T('bisous:bisous_recus')); $flux['data'] .= recuperer_fond('prive/bisous_recus',array('id_auteur'=>$flux['args']['id_auteur'])); $flux['data'] .= fin_cadre_relief(true); } return $flux; } ?>

Commentaires :
– ligne 2 : cette fonction (la seule du fichier, chouette !) est visiblement une fonction d'affichage. Je veux un affichage à droite en cas d'écran sur 3 colonnes, je déduis que je dois en changer le nom : ce sera function bisous_affiche_droite($flux). Je suppose que le premier terme doit correspondre au préfixe du plugin et les deux suivants au pipeline que j'ai appelé dans plugin.xml .
– lignes 3 et 4 : il y a inclusion de deux fichiers de SPIP que je suppose être chargé de la mise en forme et de la construction de page. Un petit coup d'oeil dans /ecrire (le dossier des fichiers internes de SPIP, en tout cas du privé) me montre que ces deux fichiers existent toujours en SPIP 3. Pour faire bonne mesure, je vais comparer aussi avec un plugin du core : l'extension "organiseur". Je constate des similitudes et des différences :

function organiseur_affiche_droite($flux){ if ($flux['args']['exec']=='accueil'){ $flux['data'] .= recuperer_fond( 'prive/squelettes/inclure/organiseur-rappels', array( 'id_auteur'=>$GLOBALS['visiteur_session']['id_auteur'], 'last' => $GLOBALS['visiteur_session']['quand'], ) ); } return $flux; }

Ces deux lignes d'inclusion n'y sont pas présentes. L'inclusion se fait probablement d'office à présent. Je les enlève et croise les doigts ;-). Par ailleurs mon hypothèse pour la ligne 2 est validée, semble-t-il.

– ligne 7 : je constate qu'en SPIP 2 les bisous donnés et reçus s'affichent sur la page d'auteur, dans le privé. Cette page s'appelle via ecrire/?exec=auteurs_infos. Il s'agit d'un fichier qui se trouve dans ecrire/exec/auteurs_infos.php.
En SPIP 3, il n'existe plus. La page d'auteur est désormais appelée via ecrire/?exec=infos_perso. Je vais donc à la recherche d'un fichier "infos_perso", et je le trouve dans /prive/squelettes/contenu. Au passage je note que ce qui concerne le squelette de l'espace privé de SPIP semble donc se trouver donc dans /prive/squelettes, vu que j'y retrouve la liste de sous-dossiers habituelle en Zpip ! Pour la ligne 7, je tente donc le remplacement par if ($flux['args']['exec'] == 'infos_perso').
– lignes 8 à 14 : je détecte des chaînes de langue (_T('bisous...')) et des indications de mise en forme ( les debut_cadre_relief('',true,'',_T('bisous:bisous_donnes')); et fin_cadre_relief). Je suppose qu'il s'agit de la méthode SPIP 2 pour définir les cadres dans le privé. Comme je sais que l'interface privée est "squeletisée", il doit y avoir moyen de faire ça en boucles. Je le note et on verra plus tard. Ce qui m'intéresse ici, c'est que je retrouve bien la fonction recupere_fond et ses arguments. Dans bisous pour SPIP 2, ces fonds se trouvent dans /prive. Je note d'adopter l'organisation SPIP 3 mais je ne touche à rien pour l'instant. Je reviendrai quand j'aurai avancé sur ces fameux squelettes du privé.

Mon fichier ressemble désormais à ceci :

$flux['args']['id_auteur'])); $flux['data'] .= fin_cadre_relief(true); $flux['data'] .= debut_cadre_relief('',true,'',_T('bisous:bisous_recus')); $flux['data'] .= recuperer_fond('prive/bisous_recus',array('id_auteur'=>$flux['args']['id_auteur'])); $flux['data'] .= fin_cadre_relief(true); } return $flux; } ?>

J'enregistre le tout et constate que j'ai désormais bien des boites "Bisous donnés" et "Bisous reçus" sur ma page d'auteur. Cool :-)

Reste à faire :
– remplacer les debut_cadre_relief par le système SPIP 3
– déplacer les fonds dans prive/squelettes/inclure/ ET reporter ici la modification.
– ajouter la ligne "sécurité" qui vérifie inc-version (je me souviens avoir vu ça passe sur toute la zone il y a peu mais elle ne se trouve pas sur spip-bisous)

Un petit supplément pour la route...

CFG a été intégré à SPIP 3

Dernière étape : dans le privé je ne vois pas d'entrée pour la configuration de SPIP-Bisous. Cela semble normal : j'ai lu que la plupart des fonctionnalités de base de CFG ont été intégrées à SPIP 3 et j'ai constaté qu'un logo de configuration vient à présent se poser dans la page d'administration des plugins, en regard des plugins à configurer.

Par comparaison avec d'autres plugins, je déduis que le fichier fonds/cfg_bisous.html doit être déplacé vers prive/exec/configurer_bisous.html pour être pris en compte.

Un commit plus tard, je constate qu'en effet, la page de configuration est désormais prise en compte. J'y ajoute un

pour que cela soit un rien mieux intégré. J'ignore si la configuration est prise en compte par contre :-), ce sera pour plus tard... Par contre, je vois que ce formulaire n'utilise pas le mécanisme CVT de SPIP. Ce sera à adapter...

Reste à faire :
– vérifier si la configuration est enregistrée
– passer le form de configuration en CVT.

Pour la suite...

Voilà tout pour aujourd'hui. Outre les "Reste à faire ci-dessus", je constate encore que le plugin n'est pas fonctionnel à ce stade : un test de bisou sur une page auteur me renvoie une superbe page blanche :-)

Ce n'est pas une surprise, il va falloir descendre dans les entrailles du plugin.

A suivre...

[1] A noter que plusieurs plugins ont une compatibilité qui s'étale à plusieurs versions de SPIP : 2.0, 2.1, 3.0 . Je suis trop ignorant pour gérer ça, ayant toujours reculé devant la création de pages privées dans SPIP 2.

Récupérer un zip depuis le site de la zone "SPIP"

François Rygaert (aka Suske) — 2012-01-03T11:07:06Z

Lorsqu'on a pas de client SVN sous la main et que le plugin que l'on veut récupérer n'est pas fourni en "zip", la zone offre une solution alternative (ne pas abuser pour ne pas faire tomber le serveur plus que nécessaire :-p)

Dans le cas présent, je tente de mettre à jour régulièrement une version SVN de SPIP3. Pour le core de SPIP, pas de souci, tout est mis à jour régulièrement dans le zip qui est là : http://www.spip.net/fr_download. Par contre, cela ne permet pas de récupérer les dernières versions des extensions, lesquelles sont développées sur la zone et ne sont "packagées" avec SPIP que lors de la publication d'une version "officielle" (SPIP3beta par exemple). Dans l'intervalle, il faut utiliser SVN, ou ruser.

Le principe est simple, il suffit d'appeler dans son navigateur :

http://zone.spip.org/trac/spip-zone/changeset/latest/ICI_LE_CHEMIN_COMPLET SUR LE ZONE?old_path=/&format=zip

Donc pour récupérer le zip avec les extensions actualisées de SPIP (que je peux lister à http://zone.spip.org/trac/spip-zone...), il me suffit de reporter ce qui suit "browser" dans l'url, soit _core_/plugins puis visiter le lien : http://zone.spip.org/trac/spip-zone/changeset/latest/_core_/plugins?old_path=/&format=zip

Bon alors attention : si on indique un chemin (path) trop court ça choppe toute l'arborescence dessous, donc... C'est le genre de distraction qui a pu faire tomber la zone. C'est aussi pour ça qu'elle est redémarrée automatiquement toutes les heures.

Un autre exemple : certains plugins/squelettes développés sur la zone ne sont pas proposées en zip sur http://files.spip.org/spip-zone, pour toutes sortes de raison. Ce système permet de remédier à cela, au cas où...

Mise à jour du 25 mai 2012 :

Sur IRC#spip, denisb me souffle [1] :

@@@récupérer un zip des diff entre 2 révisions :

http://zone.spip.org/trac/spip-zone/changeset?format=zip&new=[[jusqu'à la révision]]&old=[[depuis la révision]]&new_path=_plugins_/[[nom du plugin]]&old_path=_plugins_/[[nom du plugin]]

par exemple :

http://zone.spip.org/trac/spip-zone/changeset?format=zip&new=59775&old=56572&new_path=_plugins_/langonet&old_path=_plugins_/langonet

Ce système permet donc de récupérer uniquement les fichiers modifiés entre 2 révisions, ce qui peut être utile pour minimiser les transfert de fichiers sur certains gros plugins ou ne pas intégrer des modifs trop récentes par exemple...

Toujours plus bôôô, toujours plus cool....

Voilà, voilà.

SPIP c bôôôô.

[1] en fait non, il me pastebin ;-)

|extraire_balise(s)

François Rygaert (aka Suske) — 2011-11-11T13:07:54Z

Hors donc un spipeur cherchait à isoler les images insérées en html dans les textes de son site... Cette pesonne se présenta sur IRC, le 27/1/2011.

Appelons notre spipeur zabcd et dans le rôle de sadeur, nous retrouverons defgh, dit "le fourbe".

11:23 < defgh> #TEXTE|extraire_balise{img}
11:23 < defgh> sort la première balise img depuis TEXTE
11:24 < defgh> #TEXTE|extraire_balises{img} sort le tableau de *toutes* les balises img
11:25 < zabcd> defgh : il y a les 2 filtres extraire_balise *et* extraire_balises ?
11:25 < defgh> oui
11:25 < defgh> ça permet de faire plein de choses intéressantes
11:26 < defgh> mais c'est de la regexp (donc lourd)
11:26 < defgh> combiné avec |replace{}
11:26 < zabcd> defgh : oui mais ça ira pour une petite remontée d'article ici et là
11:27 < zabcd> d'autant que je les remonte via ajax et donc uniquement si l'internaute clique sur actions concernées
11:27 < zabcd> la surcharge ne sera pas énorme

Pour éviter les liens codés en html sur un forum, on pourra écrire par exemple dans les boucles forums :

[(#TEXTE|extraire_balises{a}|?{' Liens html interdits ',#TEXTE})]

En français, si il y a une balise ... dans le #TEXTE du forum, afficher Liens html interdits, sinon afficher le #TEXTE.

Voilà, voilà.

Le texte a dû être retravaillé pour en mettre la quintessence en évidence, d'où le long délai avant publication :-)

Récupérer, dans une sauvegarde de plusieurs Gigabytes, le contenu d'une table malencontreusement effacée

François Rygaert (aka Suske) — 2011-11-10T17:53:11Z

Hors donc une table a été malencontreusement effacée de la base de données. La taille de la sauvegarde dont je dispose est telle que travailler dans mon éditeur de texte habituel est strictement impossible, la simple ouverture du fichier nécessitant plus de 20 minutes. Récit d'une quête et de sa mise en oeuvre :-)

Je suis sous LinuxMint, comme l'utilisation d'un programme graphique semble beaucoup trop lourde, j'ouvre une console pour essayer de m'en sortir avec la ligne de commande, moins gourmande pour le système.

Repérer la table dans la sauvegarde

Je me positionne dans le dossier où se trouve la sauvegarde puis je tente d'abord de l'ouvrir avec nano, un éditeur en ligne de commande.

cd mondossier nano sauvegarde.sql

Beaucoup plus rapide qu'avec l'éditeur graphique : 3 minutes suffisent, je peux voir les premières lignes. Je connais le nom de la table que je cherche à récupérer. Dans nano, je lance une recherche (Ctrl W) sur 'spip_evenements' et cela m'amène à découvrir que les données sont écrites en quelques centaines de lignes aux alentours de la ligne 26000. Peu importe l'exactitude, la voie était sans issue : chaque intervention sur le contenu du fichier rend nano incontrôlable pendant 3 minutes... Je note néanmoins que la partie du fichier qui m'intéresse commence par "LOCK TABLES spip_evenements WRITE ;".

Trouver un moyen de récupérer mes données sans affichage graphique

Je sais que me passer complètement d'affichage du contenu du fichier me permettrait d'exécuter plus aisément la tâche que j'ai à mener : cela prendra certainement des minutes mais au moins elle ne sera pas systématiquement ralentie par les besoins de l'affichage.

Me voilà parti sur le web pour une recherche des divers outils existants. Dans un premier temps, je tente une "réduction" de mon fichier avec la commande "sed " (appliquée sur une copie vu que sed modifie le contenu du fichier cible).

cp sauvegarde.sql sauvegarde_bis.sql sed '1,25000d' sauvegarde_bis.sql

Cette commande devrait supprimer les lignes 1 à 25000 du fichier sauvegarde_bis.sql . Le terminal se met à tourner. Cela durera des heures et se terminera par une erreur... Après quelques dizaines de minutes, je cherche une autre solution :-).

La solution : la commande grep

En fait il y a beaucoup plus simple et rapide. La commande grep.

grep -C300 'LOCK TABLES spip_evenements WRITE;' sauvegarde.sql > restore.sql

Cette commande devrait extraire 300 lignes à partir de celle qui débute par "LOCK TABLES spip_evenements WRITE ;" dans le fichier sauvegarde.sql puis copier ces lignes dans un fichier restore.sql, le tout sans modifier sauvegarde.sql .

Et ça marche : en quelques secondes le boulot est terminé et restore.sql contient les lignes nécessaires à la restauration. Une quizaine de lignes à la fin des 300 contiennent des instructions relatives à une autre table, je les supprime et sauve mon fichier.

Après, j'uploade ce fichier restore.sql via phpmyadmin (option "importer") et la table est restaurée.

GNU/Linux, c bôôôôô. Il me reste à suggérer à l'admin du site d'être plus prudent avec les manoeuvres sur les plugins. Désactiver temporairement, ça va, mais désinstaller, quand le plugin a été bien codé, cela entraîne la suppression des données de ce plugin...

Ouvrir un article "directement" en mode édition

François Rygaert (aka Suske) — 2011-01-10T16:32:11Z

Quand on navigue dans l'interface privée d'un site SPIP, les titres présentés en liste sont visiblement cliquables. Dans le cas des articles, la puce de statut et le numéro le sont aussi. Un truc glâné sur IRC : merci b_b :-)

Si l'on souhaite modifier un article SPIP, on clique donc généralement sur son titre, puis lorsque la page article est chargée, on clique sur "modifier cet article". Deux opérations mais il y a moyen de faire plus rapide : en cliquant sur le numéro d'article, à droite dans les listes, on ouvre directement l'article en mode "édition", sous réserve d'en avoir le droit bien entendu.

Visuellement : à gauche, ouvrir la page d'article, à droite, ouvrir l'article en mode édition.

Cool, j'ignorais :-)

Tant qu'à parler de ces listes, c'est peut-être le moment de rappeler que, dans les mêmes listes, la puce de statut (verte dans l'image ci-dessus) s'anime au survol de la souris. Cinq petits carrés/pictos apparaissent qui permettent de modifier rapidement le statut de l'article :

– blanc => en cours de rédaction
– orange => proposé à publication
– vert => article publié
– rouge => refusé
– noir => poubelle

C'est dit... Bon SPIP !

MàJ du 11/02/2011 : arno* a (de longue date) clarifié les choses via un plugin http://plugins.spip.net/Listes-d-ar.... Il rend (notamment) cette fonctionnalité visible donc utilisable :-)

Modérer les forums depuis le site public

François Rygaert (aka Suske) — 2010-09-14T06:33:00Z

Quelle qu'en soit la raison, on peut souhaiter supprimer certains messages postés sur son site. Le passage par l'espace privé nécessite alors plusieurs clics qui s'avèrent fastidieux si l'opération doit être répétée plusieurs fois. Avec ce code, un clic suffit :-)

Ce billet est la simple description du système mis en place sur http://forum.spip.org .
Merci d'abord aux codeurs de ce squelette, pour cette fonctionnalité en particulier !

Utilité

Il arrive que des personnes postent des messages hors de propos, ou injurieux, ou... ou du spam... Traditionnellement, il faut repasser par l'espace privé puis la gestion des forums puis modérer. 3 clics. Dépublier ces messages en un clic, c'est mieux :-)

Description

C'est assez simple : si vous êtes connecté-e au site et que vous disposez du droit de gérer les forums, une petite croix rouge vient s'installer à côté du titre du message de forum (ou là où vous le souhaitez dans votre squelette, dans une boucle FORUMS...)

Un clic et le message voit son statut passé à "off", c'est à dire qu'il est dépublié. Si nécessaire, vous pouvez encore modifier ce statut ensuite, via l'espace privé.

Mise en place

Le dispositif installé sur forum.spip.org consiste en :

une fonction à installer dans le fichier mes_fonctions.php
du code, fondé sur la balise #AUTORISER, à insérer dans la/les boucle-s FORUMS

La fonction :

// moderer les messages depuis l'espace public // ne supprime pas le message ni le fil mais les passe en 'off' // on peut toujours les revalider dans l'espace prive function invalider_forum($id_forum,$r='') { include_spip("inc/securiser_action"); list($id_auteur, $pass) = caracteriser_auteur(); $arg="$id_forum"; $hash = _action_auteur("instituer_forum-$arg-off", $id_auteur, $pass, 'alea_ephemere'); $r = rawurlencode(_request('redirect')); return generer_url_action('instituer_forum', "arg=$arg-off&hash=$hash&redirect=$r"); }

Le code :

[ (#AUTORISER{invalider_forum,forum,#ID_FORUM})<a href='[(#ID_FORUM|invalider_forum|parametre_url{redirect,#GET{url}})]'>' title='<:ecrire:bouton_radio_modere_posteriori:>' /></a> ]

Il vous faut bien bien entendu disposer quelque part dans votre site de l'image "croix-rouge.gif" et des codes de langue... Sur les forums de SPIP, le même principe permet de supprimer les mots-clés joints aux forums et il s'agit d'une piste plus qu'intéressante pour les documents joitns aux forums également :-).

Voir en ligne : Les forums de SPIP (cliquer sur le papillon au bas des pages pour afficher le squelette)

SPIP subit progressivement une cure d'amaigrissement qui consiste à passer des parties spécifiques du "core" en plugins/extensions. Ce sera prochainement le cas des forums et j'imagine que cette possibilité sera intégrée dans le plugin en question. En attendant, plus besoin de se priver :-)

|is_null permet de tester l'existence d'une variable

François Rygaert (aka Suske) — 2010-07-11T15:59:37Z

Ce filtre s'applique à la balise #ENV et permet de tester l'existence de variables dans l'environnement SPIP.

Il est parfois nécessaire de différencier une variable de contenu vide d'une variable inexistante. Ce filtre est là pour vous y aider. Il s'applique à la balise #ENV{blabla} et permet donc de tester la présence ou non de la variable "blabla" dans l'environnement du squelette.

[(#ENV{blabla}|is_null)]

Ce code retourne "1" si la variable "blabla" est nulle/inexistante ou rien si elle est non nulle/présente [1].

Ce filtre ne s'applique pas aux variables déclarées avec #SET/#GET dont la valeur n'est pas présente dans l'environnement mais uniquement dans le squelette.

Techniquement, |is_null est une fonction php et n'est donc pas spécifique à SPIP.

[1] Ne pas confondre variable nulle, c'est à dire inexistante, et variable vide, c'est à dire présente dans l'environnement mais sans valeur affectée.

Découvert sur http://programmer.spip.org/GET, ce filtre m'a permis d'apporter une piste de solution sur http://forum.spip.org/fr_225786.html. Le texte ci-dessus a été proposé sur spip.net/fr mais ne semble pas devoir y être publié vu qu'il s'agit essentiellement de l'application comme filtre SPIP d'une fonction php.

Gérer les IP spammeuses avec un squelette

François Rygaert (aka Suske) — 2010-06-24T15:04:56Z

Par principe, on peut souhaiter laisser les forums de son site ouvert aux posteurs anonymes. Le plugin "NoSpam" s'impose alors mais en ce qui me concerne, j'y ajoute une petite couche (en squelettes). Le principe est que rien ne change si l'utilisateur est connecté puisqu'on ne visera que les posteurs anonymes et dont l'adresse IP a posté des commentaires qui ont été modérés, supprimés via l'interface privée de SPIP.

Pour l'activation du plugin NoSpam, je vous renvoie à la documentation. Il fonctionne bien et rend nettement service. Quelques détails :
– très peu de spams sont affichés directement sur le site public. La plupart du temps, ces messages sont placés "en attente de validation". L'administrateur peut les supprimer (ou les publier s'il s'agit d'un faux positif).
– les spams "à la chaîne", effectués par des robots, sont bloqués. La plupart du temps, seul le premier message est accepté mais il est modéré comme expliqué ci-dessus.
– de plus en plus, hélàs, le spam est fait "à la main"... Dans ce cas, le premier message est souvent publié, mais les suivants sont mis en attente.
– N'empêche, à la longue, même dans l'espace privé, ces listes de messages à supprimer s'allongent parfois et font perdre leur temps aux adminsitrateurs. Comme l'expérience m'a montré qu'en outre ces spams "manuels" proviennent souvent d'une même adresse IP, cela m'a motivé à rajouter une couche.

La suite de l'exemple est du code qui me sert sur des sites dotés du plugin "SpipClear" (dont ici :-) ), il y a quelques adaptations à faire pour rendre ceci générique mais je réserve cela à la mise en plugin de la chose et ne résiste pas plus longtemps au plaisir de partager.

Tout d'abord, il me faut une mini-fonction qui me permettra de récupérer l'adresse IP de la personne connectée. Dans /squelettes/mes_fonctions.php [1], je mets donc :

function ip_visiteur() {
$ip = $_SERVER['HTTP_X_FORWARDED_FOR'] ? $_SERVER['HTTP_X_FORWARDED_FOR'] : ( $_SERVER['HTTP_CLIENT_IP'] ? $_SERVER['HTTP_CLIENT_IP'] : $_SERVER['REMOTE_ADDR'] ); return $ip_vis;
}

Ensuite, j'écris un bout de squelette que je place dans /squelettes/spam.html

[(#REM) Recupere l'ip du visiteur]
#SET{ip_courante,#VAL|ip_visiteur} [(#REM) chercher si cette ip a ete moderee depuis moins de 15 jours] <BOUCLE_enfoire(FORUMS){ip=#GET{ip_courante}}{statut=off}{age<15}> </BOUCLE_enfoire>
[(#REM) si oui ] [(#TOTAL_BOUCLE|>{0}|oui) Votre adresse ip #GET{ip_courante} a spammé les forums de ce site. [(#REM) prevoir le non-affichage des forums] #SET{pas_forum,1} [Vous devez vous inscrire pour pouvoir poster. <hr />(#FORMULAIRE_INSCRIPTION)] [(#REM) si on a le formulaire de contact avance, l'employer] [<hr />(#FORMULAIRE_CONTACT)] ] </B_enfoire> [(#REM) si l'ip n'a pas ete moderee, on envoie le formulaire de forum)]
[(#GET{pas_forum}|=={1}|non)
[(#FORMULAIRE_FORUM)][(#PARAMETRES_FORUM|?{'',<:spipclear:commentaires_fermes:>})]
]

Enfin, dans mon squelette d'appel, je modifie l'appel des forums afin de tester, si nécessaire, l'adresse IP du visiteur non-connecté.

[(#REM) si visiteur connecte, rien ne change] [(#SESSION{id_auteur}|oui) [(#FORMULAIRE_FORUM)][(#PARAMETRES_FORUM|?{'',<:spipclear:commentaires_fermes:>})] ]
[(#REM) si pas connecté, on passe par spam.html pour tester l'IP] [(#SESSION{id_auteur}|non) <INCLURE{fond=spam}{env}> ]

Voilà, voilà. Je crois que ce futur plugin est promis à un bel avenir, surtout si on rend configurable la période analysée et le nombre de modérations avant blocage de l'IP.

[1] Merci à denisb pour l'amélioration de la détection IP : $ip_vis = $_SERVER["REMOTE_ADDR"] ; est un peu léger semble-t-il

Diriger un administrateur de rubrique vers sa page de rubrique

François Rygaert (aka Suske) — 2010-06-18T12:38:11Z

Un "truc-astuce" pour permettre aux administrateurs restreints de se connecter directement à la page de leur rubrique dans l'espace privé de SPIP.
La demande est apparue sur IRC. La solution envisagée passait par de la programmation, ce qui est sûrement bien. Mais j'aime bien les solutions "en squelette", qui, à l'usage, présentent souvent l'avantage de la pérennité.

Quand un administrateur restreint se connecte à l'espace privé, il arrive sur la page "A suivre". Hors, bien souvent, ce type d'utilisateur se connecte pour publier dans la rubrique dont il/elle a la charge. L'astuce qui suit permet donc d'économiser un ou quelques clics et, accessoirement, de la facilité sur un site qui comporte des dizaines de rubriques. Il s'agit d'insérer une étape intermédiaire (invisible) entre le formulaire de login et l'arrivée dans l'espace privé. On crée pour cela un squelette dans le dossier /squelettes. Appelons ce squelette test_admin_restreint.html. Il contiendra :

[(#REM) Si pas de statut administrateur erreur 404]
[(#SESSION{statut}|=={0minirezo}|non) [(#HTTP_HEADER{location: [(#URL_PAGE{404}|url_absolue)]})]] [(#REM) Si statut administrateur traitement]
[(#SESSION{statut}|=={0minirezo}|oui) [(#REM) Selectionner la rubrique associee a l'administrateur et rediriger] <BOUCLE_rub_admin(auteurs_rubriques){id_auteur=#SESSION{id_auteur}}{0,1}> [(#HTTP_HEADER{location:#URL_SITE_SPIP/ecrire/?exec=naviguer&id_rubrique=#ID_RUBRIQUE})] </BOUCLE_rub_admin> [(#REM) Si pas de rubrique associee, login classique] [(#HTTP_HEADER{location:#URL_SITE_SPIP/ecrire})] <//B_rub_admin>
]

Il reste alors à inviter les personnes concernées à se connecter via un formulaire appelé avec :

 #FORMULAIRE_LOGIN{#URL_PAGE{test_admin_restreint}}

Mettez ce code dans la page par laquelle les rédacteurs se connectent à votre site, par exemple, sommaire.html . Une fois le formulaire rempli et validé, il renvoie vers le squelette qui ne sert qu'à tester si le rédacteur est administrateur et, si oui, s'il est rattaché à une rubrique. Si oui, la connexion se fera sur la page de cette rubrique, sinon, connexion classique sur la page "A suivre".