Alinéas : « Retour simple »

Depuis le 4 février 2011 : Pour le respect automatique des « retours à la ligne », « allers à la ligne », « retours chariot ». Depuis ses débuts semble-t-il, SPIP comporte le filtre |post_autobr destiné à assurer ce respect des alinéas, mais curieusement ce filtre a été négligé et aucun “plugin” n’en permettait la mise en œuvre. Tel est désormais l’objet du plugin « Alinéas : Retour Simple ». — N.B. : Ne fonctionne pas si le « Couteau suisse » est installé ; dans ce cas, utiliser la “lame” « Retours de ligne automatiques » du Couteau suisse.

Installation

1. — Soit à partir des fils RSS de chargement automatique proposés sous "Adresse du plugin ou de la liste" dans l’onglet "Ajouter des plugins" de la page de gestion des plugins de l’espace privé de votre site sous SPIP. Charger le plugin par cette voie permet une mise à jour régulière de son code source.

2. — Soit télécharger l’archive “.zip” de la présente page vers le dossier de plugins de votre site sous SPIP, puis installer le plugin depuis votre espace privé comme expliqué ici : http://www.spip.net/fr_article3396.html.

Contexte

« Pour une raison particulièrement mystérieuse », il existe depuis plus longtemps un autre plugin assurant à l’inverse la suppression de la mise en forme en alinéas, pourtant d’usage multi-millénaire, et cette suppression y compris lorsque le code <br /> est inséré par les rédacteurs : le plugin Interdire les retours-chariot. L’auteur ne semble pas même connaître le terme et la notion d’« alinéa » : il parle de « paragraphes joints et disjoints ». Sans doute pour la commodité des intéressés, ce plugin suppressif a été placé dans la même présente rubrique que le plugin Alinéas : « Retour simple ». — On peut comparer le succès des deux plugins par les statistiques par sondage automatisé officielles du site http://plugins.spip.net suivantes de janv. 2012 : le plugin respectueux des alinéas, qui existe depuis le 4 févr. 2011, est employé dans près du triple de sites que celui suppressif, qui existe depuis au moins 2008. (Et sans compter les usages de la “lame” « Retours de ligne automatiques » du Couteau suisse, employé dans près de 20 000 sites…) — Quant aux pages de présentation sur le présent site, la présente s’agissant du plugin pour le respect des alinéas reçoit plus de dix fois plus de visites mensuelles que celle du plugin suppressif.

Compatibilité SPIP

Ce plugin a été élaboré à l’époque de SPIP 2.1, il est probablement compatible avec les version antérieures mais personne ne l’a signalé.
Merci à RastaPopoulos d’avoir validé ce plugin pour SPIP 3.0. et d’avoir en conséquence mis à jour les mentions de compatibilité.

Principe

Il s’agit que les « retours à la ligne » ne soient plus ignorés par SPIP, mais produisent des alinéas lorsque le texte y est continué. Le code <br /> est automatiquement ajouté dans ce cas, comme lors de l’ajout manuel de _ (“tiret bas”, “underscore”) en début de ligne [1]. — En revanche, il ne s’agit pas de créer des espaces (multiples “lignes vides”) par plusieurs retours à la ligne : dans ce cas il est estimé que le comportement de SPIP doit demeurer, qui élimine les espaces multiples, et crée un nouveau paragraphe lors de saut(s) de ligne(s). [2]

Résultat

Le respect des alinéas obtenu concerne les Rubriques, les Articles (chapeau, texte, post-scriptum), les Brèves, et leurs Notes de bas de page respectives. Et dans nombre de cas, les champs créés par d’autres plugins : voir « Tests particuliers », et explication.

S’agissant des plus récentes versions de SPIP, le respect des alinéas est assuré directement par SPIP (sans plugin) dans les messages de forums publics sous les articles : il a été donc récemment considéré dans ce cas que « le public » de SPIP doit s’attendre au respect des alinéas.

SPIP présentant par ailleurs une qualité et une liberté typographiques très appréciées, le cas échéant augmentées par des plugins, le problème de liberté typographique d’alinéas traité par Jujubre en 2006 n’a pas évolué jusqu’en 2011, jusqu’au plugin réalisé par Maïeul Rouquette en commençant par la solution de Jujubre, puis sur les nouvelles indications de Fil, qui a expliqué l’usage correct du filtre |post_autobr et exposé des pistes de mise en œuvre encore plus poussées. Pour l’instant, il s’est agi pour Maïeul, en confectionnant un “plugin”, non de “promouvoir” a priori l’usage des alinéas sur le “web” en général et dans SPIP en particulier, mais du souci technique d’éviter que les utilisateurs souhaitant le respect des alinéas aient à modifier un fichier du “core” de SPIP comme dans la solution initiale de Jujubre [3].

S’agissant notamment des champs créés par d’autres plugins, Maïeul écrit : « Tout champ sur lequel les raccourcis typographiques de SPIP sont appelés doit normalement respecter ces règles [de « Retour simple », respect des alinéas], avec ce plugin ».

Caractéristiques techniques du plugin

Voir aussi : http://plugins.spip.net/retoursimple.html.

N.B. pour les experts : Cf. http://article.gmane.org/gmane.comp.web.spip.zone/22255.

Le plugin est disponible ici :
http://files.spip.org/spip-zone/retoursimple.zip
et son développement sur la “zone” s’est effectué ici :
http://zone.spip.org/trac/spip-zone/log/_plugins_/retoursimple.

Le champ « auteur » du plugin en version 0.2 indique :
« Plein de gens dont Fil, Maïeul et PatV ».

Voici le contenu intégral du fichier retoursimple.php établi à partir des indications de Fil (les seuls autres fichiers du plugin étant le .xml, le .png et le .revision) :

<?php
define('_TRAITEMENT_RACCOURCIS', 'propre(post_autobr(%s), $connect)');
?>

Évolutions supposées du plugin

Éventuel échappement de balises :

Pour mémoire / éventuels perfectionnements futurs (si compatible avec l’utilisation de post_autobr par le plugin « Alinéas : Retour simple ») :

PatV a perfectionné la lame analogue du Couteau suisse (« Retours de ligne automatiques ») par le commit :
http://zone.spip.org/trac/spip-zone/changeset/51187/_plugins_/couteau_suisse
« Timestamp : 09/09/11 11:34:07
Message : Échappement des balises <html|code|cadre|frame|script|jeux> avant d’appliquer le filtre post_autobr ».

Les balises <modele> et <jclic> semblent pouvoir être ajoutées pour échappement.

Ceci semble connexe au problème soulevé par Joseph dans le forum public de l’article « Alinéas : Retour simple », qui relève finalement du filtre post_autobr lui-même :
http://www.spip-contrib.net/Retour-simple,3823#forum446036

Interférence du « Couteau suisse »

Par ailleurs, dans le même temps de mise au point du plugin Alinéas : « Retour Simple », Patrice Vanneufville a développé une solution alternative par un nouveau module-“lame” ajouté au Couteau suisse. Il faut noter que le plugin Alinéas : « Retour simple » de Maïeul est paralysé dès lors que le Couteau suisse est installé : le plugin Alinéas : « Retour simple » ne produit strictement rien, ni effet ni erreur, dès lors que le Couteau suisse est installé. Ceux qui installent le Couteau suisse doivent donc utiliser le module de celui-ci : “lame” « Retours de ligne automatiques », dans la section « Améliorations des textes ».
Ce module du Couteau suisse traite seulement le texte principal des articles.
Il est possible d’étendre les traitements selon les modalités actuellement indiquées par l’auteur, savoir, dans config/mes_options.php ajouter [4] :

function autobr_surcharger_outil($tab)
	{$tab ['
	traitement:DESCRIPTIF:pre_propre,
	traitement:CHAPO:pre_propre,
	traitement:PS:pre_propre,
	traitement:TEXTE/rubriques:pre_propre,
	traitement:TEXTE/breves:pre_propre
	'] = 'autobr_pre_propre'; return $tab;}

Code mis à jour au 2011-05-04 selon message de forum ci-dessous de Patrice Vanneufville : « L’utilisation d’une “globale” n’est plus recommandée. Il vaut mieux désormais encapsuler le code dans une fonction, pour gagner en mémoire et en performance ». [5]N.B. : Ne pas mettre la ligne « traitement:NOTES:pre_propre, ». En effet, les « Notes » de bas de page sont traitées sans cette ligne de code, et l’ajout spécifique du traitement des « Notes » fait doublon et provoque un double retour à la ligne, donc un saut de ligne, donc un nouveau paragraphe pour SPIP dans les notes de bas de page. [6]

Tests généraux

Il reste cependant, au regard de ces avancées quant à l’utilisation du filtre |post_autobr délaissé jusqu’à lors, qu’aucun de ces plugin et module ne permet à ce jour un comportement harmonisé de SPIP pour tous les champs souhaitables, éventuellement par perfectionnisme :
— s’agissant des sites référencés, le champ « Description du site » (le plugin Alinéas : « Retour simple » assure le respect des alinéas dans ce cas, mais non le Couteau suisse),
— s’agissant des mots-clés, le champ « Texte explicatif »,
— s’agissant des auteurs, le champ « Qui êtes-vous ? Courte biographie en quelques mots »,
puis en partie privée uniquement :
— s’agissant des messages, le champ « Texte du message »,
— s’agissant des forums internes, le champ « Texte de votre message ».

Tests au 2011-04-22 / SPIP 2.1.10
— Plugin «  Alinéas : « Retour simple »  » 0.2 [44290]
—  « Couteau suisse » 1.8.38.00 [46601]

Ci-dessous :
— « ARS » désigne le plugin Alinéas : « Retour simple »,
— « CS » désigne le module « Retours de ligne automatiques » du « Couteau suisse », agrémenté de l’ajout de code dans config/mes_options.php indiqué ci-dessus au point 2.,
— « + » indique : « respect des alinéas »,
— « - » indique : « non-respect des alinéas ».

• « Rubriques », champ « Texte explicatif » (y compris Notes)  :
— partie publique : ARS + | CS +
— partie privée : ARS + | CS +

• « Articles », champs « Chapeau » (y compris Notes), « Texte » (y compris Notes), « Post-scriptum » (y compris Notes)  :
— partie publique : ARS + | CS +
— partie privée : ARS + | CS +

• « Brèves », champ « Texte de la brève » (y compris Notes)  :
— partie publique : ARS + | CS +
— partie privée : ARS + | CS +

Le résultat est donc parfait pour Rubriques, Articles, Brèves,
y compris pour leurs Notes de bas de page
 [7].

Les autres cas listés ci-après pourraient être considérés comme relevant de perfectionnisme…

• « Sites référencés », champ « Description du site » :
— partie publique : ARS + [8] | CS -
— partie privée : ARS + | CS -

• « Mots-clés », champ « Texte explicatif » :
— partie publique : ARS + | CS -
— partie privée : ARS - | CS -

• « Auteurs », champ « Qui êtes-vous ? Courte biographie en quelques mots » :
— partie publique : ARS + | CS -
— partie privée : ARS - | CS -

Puis en partie privée uniquement :

• Forums internes, champ « Texte de votre message » :
— partie privée : ARS - | CS -

• « Messages », champ « Texte du message » :
— partie privée : ARS - | CS -

Tests particuliers

Il s’agit ici de répertorier les tests signalés de l’effet du plugin Alinéas : « Retour simple » dans des champs créés par d’autres plugins.

Plugin « Agenda 2.0 »
2011-05-02 : Perline signale que le plugin Alinéas : « Retour simple » produit son effet de respect des alinéas dans le champ descriptif mais pas dans le champ adresse. Voir aussi dans le forum ci-dessous. Voir explication ci-dessus.

Notes techniques

Extraits de message de Fil du 7 février 2011  :


La fonction post_autobr n’est pas bugguée, en tous cas pas pour le cas indiqué :

aaa
bbb

Je m’explique : son insertion dans le pipeline pre_propre() provoque bien l’erreur signalée. Mais cette fonction n’a jamais été prévue pour ce pipeline (qui n’existait d’ailleurs pas à l’époque où elle a été codée). En effet, j’ai introduit post_autobr pour qu’elle s’applique au contenu “brut” tel qu’envoyé dans le formulaire de saisie du contenu, avant l’insertion en base de données (d’où le nom : POST auto-BR).

(Pour la petite histoire, et par parenthèse, cette fonction était
associée à une case à cocher « [x] tenir compte des sauts de [retours à la] ligne », qui devait convertir, dès la première saisie, les [retours à la] ligne en « _ ». L’interface utilisateur était défectueuse, et on a démonté la chose.)

Pour revenir à notre problème, il se trouve que l’on peut sans problème exploiter cette fonction en une ligne d’options.

Voici le code actuel, dans ecrire/public/interfaces.php :

define('_TRAITEMENT_RACCOURCIS', 'propre(%s, $connect)');
../..
// gerer les sauts de ligne dans les textes des forums
$table_des_traitements['TEXTE']['forums'] =
	str_replace('%s', 'post_autobr(%s)',
	$table_des_traitements['TEXTE']['forums']
);

Il suffit donc, pour que les [retours à la] ligne soient correctement pris en compte, et sans le bug signalé, d’indiquer dans mes_options.php un simple :

define('_TRAITEMENT_RACCOURCIS', 'propre(post_autobr(%s), $connect)');


(avec comme seul souci le fait que la fonction sera appliquée deux fois aux forums ; par ailleurs à cause du découpage/découplage entre #TEXTE et propre(), on n’a plus l’équivalence #TEXTE = propre($texte), mais c’est un problème qui ne concerne pas que cette fonction).

=> Chers amis, jouissons tous de cette liberté qui nous est si chère.

CEPENDANT je ne crois pas que ça épuise la question, qui est toujours la même depuis le début : si cette option est un simple “switch”, qu’on peut vouloir inverser à tout moment, que fait-on des contenus existants, qui risquent de subir une transformation indésirable, s’ils ont été saisis sans souci des [retours à la] ligne, et se retrouvent avec des <br /> “pourris”.
Je crois qu’il faudrait proposer un outil permettant de détecter les contenus qui vont éventuellement être modifiés par le changement du moteur, et permettre plusieurs opérations : 1) tout changer dans les contenus existants 2) tout laisser 3) changer pour certains articles.

Lorsque j’ai “switché” sur les forums, j’ai testé le filtre sur l’ensemble des forums d’un gros site que je gère, où les contributeurs ne sont absolument pas spipeurs, et le résultat était très positif en termes visuels. En revanche pour des articles, où les rédacteurs SAVENT que le saut de ligne n’est pas pris en compte, j’irais très prudemment…

Une autre idée liée à cet (éventuel) changement, si on veut qu’il puisse être pérenne : ce serait de réussir à indiquer, dans les textarea (au moins de l’espace privé), les endroits où on a un [retour à la] ligne, par exemple avec un petit symbole ¶ de couleur orange. (C’est quelque chose que je ne sais pas faire.)

C’est bien le problème ci-dessus qui a longtemps bloqué cette fonction.

— Fil

Voir aussi un fil de forum sur l’« échappement des appels de modèles ».


Notes

[1Comme dans la plupart des traitements de texte, dans les dernières versions de SPIP (intégrant le « Porte-plume ») l’usage simultané des touches « Majuscule » et « Entrée » (« Retour chariot ») produit un alinéa en introduisant le caractère _ (suivi d’une espace) en début de nouvelle ligne. Pour ceux qui savent pratiquer cette combinaison au clavier, le présent plugin reste principalement utile s’agissant du collage dans SPIP de textes comportant des alinéas.

[2Il ne faut pas confondre (ici) alinéas et sauts de lignes : un alinéa n’est pas un saut de ligne, mais un retour à la ligne où le texte est continué, sans “ligne blanche” que constitue un “saut de ligne” — malheureusement, l’expression “saut de ligne” est souvent mise pour “retour à la ligne” : or, l’expression “sauter une (ou plusieurs) ligne(s)” implique manifestement une omission de texte consistant en une ou des “ligne(s) vides(s)”, ce qui produit dûment dans SPIP un nouveau paragraphe. — J’ai rectifié sur ce point la documentation du filtre |post_autobr le 24 avr. 2011. frdm

[3En fait, Jujubre avait posté sa solution « Retours à la ligne fidèles à l’article rédigé » le 2 août 2006, et le filtre |post_autobr faisait l’objet d’une publication/documentation succincte ici quelques jours après, le 10 août 2006. Jujubre ne pouvait donc pas, semble-t-il, avoir connu ce filtre, et avait publié sa propre solution.

[4Le fichier mes_options.php, s’il n’existe pas déjà, est à créer dans le répertoire config/ du site. Ce fichier “php” devra en tant que tel débuter par <?php et se terminer par ?> (attention à ne pas laisser d’espace ou de ligne vierge avant <?php ou après ?>).

[5Ce code doit notamment assurer le respect des alinéas dans le champ « Descriptif », utilisé par le plugin « Agenda 2.0 » par exemple.

[6En fait, c’est moi qui avais ajouté le traitement de « NOTES », initialement, dans ce code, par excès de zèle donc… frdm

[7Cependant N.B. : Le Couteau suisse produit une augmentation d’espacement de lignes dans les notes de bas de page, pour les lignes commençant par -- (deux traits d’union) suivis d’une espace, ou par _ (“tiret bas” : “underscore”) suivi d’une espace (le Couteau suisse transforme ces lignes en paragraphes). (P.S. : Le terme « espace » est féminin en typographie.)

[8« - » avec le squelette Sarka-Spip 3.0.4 (40664) : ceci est manifestement dû à un choix de mise en page par ce squelette, et n’est pas un défaut à proprement parler. Le même cas pourra se rencontrer avec d’autres squelettes.

S’agissant d’un article relatif à la typographie, la capitalisation systématique du terme « SPIP » résulte d’un usage en vigueur sur le présent site, ainsi que Cédric Morin l’a rappelé par le terme « usage », au soutien de l’observation de tetue, à propos du présent article.

Discussion

7 discussions

  • 1

    Bonjour tout le monde,

    J’essaie en vain d’utiliser ce plugin fort bien utile.
    Quand je commence à coder, j’efface tout le habillage.css pour repartir de zéro. Peut-être n’est-ce pas la bonne méthode puisqu’aujourd’hui ça me pose problème…

    En gros quand je rétablis le css d’origine, j’ai bien mes sauts de lignes, mais plus avec le mien (d’ailleurs meme les underscore+espace ne font plus rien)

    quelqu’un saurait quels attributs css est à garder pour éviter ce genre de soucis ?

    Merci d’avance,

    LD.

    • edit :
      je ne sais pourquoi, mais j’avais un margin-top négatif qui annulait le saut de ligne

      merci à ceux qui auraient cherché

    Répondre à ce message

  • 2

    Retour de bug avec le plugin Retour simple. Si on insère un modèle avec une syntaxe ayant des retous à la ligne, syntaxe valide, comme :

    <modele12|param1=toto
       |param2=truc
       |param3=machin

    alors le plugin va insérer des underscore (_) dans l’appel du modèle. Il faudrait que l’expression régulière du plugin exclu les appels de modèles.

    Cordialement

    • Merci pour ce signalement.

      Je m’aventure à une réponse limitée simplement due aux échanges sur la liste spip-zone que j’ai suivis, ayant précédé la dernière version de ce plugin.

      Ce plugin ne comporte pas d’« expression régulière ».

      Il met seulement en œuvre en une seule ligne de code le filtre post_autobr à partir des indications de Fil pour cette mise en œuvre. Fil est le seul à avoir pu indiquer comment utiliser le filtre post_autobr, après des suspicions de bug de ce filtre qu’il a ainsi démenties.

      Cependant le point que tu présentes soulèverait à nouveau, éventuellement, une suspicion de bug de post_autobr… et si Fil a su être le seul à pouvoir répondre auparavant sur ce filtre, il se pourrait que ce soit à nouveau le cas.

      En toute hypothèse, voici le contenu intégral du fichier retoursimple.php (les seuls autres fichiers du plugin étant le .xml, le .png et le .revision) :

      <?php
      define('_TRAITEMENT_RACCOURCIS', 'propre(post_autobr(%s), $connect)');
      ?>

      Mes aptitudes ne me permettent pas d’en dire plus ou mieux.

      Cordialement, fr

    • Pour les autres lecteurs, une suite de la discussion, entre Joseph et Fil,
      « Retour d’expérience sur le filtre post_autobr sur un texte comportant des modèles »
      se trouve ici :
      http://comments.gmane.org/gmane.comp.web.spip.devel/60770
      ou ici :
      http://archives.rezo.net/archives/spip-dev.mbox/...

    Répondre à ce message

  • 2

    Bonjour,
    quand est-il des champs extras.
    Je ne parviens pas à faire autre chose que des
    pour les sauts de pragarphes.
    Merci de cette contrib et d’une éventuelle réponse...
    Goushi.

    • Pour ma part je n’utilise pas « Champs extras », je ne peux donc dire ce qu’il en est. Je ne suis pas sûr de ma compréhension de la question : vous voulez dire que vous avez déjà effectivement essayé le plugin « Retour simple » dans des « Champs extras », et que les alinéas par retour simple à la ligne n’y sont pas respectés ? Voulez-vous dire de plus que _ suivi d’une espace en début de ligne puis de texte sur la ligne ne produit non plus aucun effet d’alinéa dans les « Champs extras » ? En toute hypothèse, il faudrait quelqu’un de plus compétent que moi pour répondre à de telles questions, s’agissant de « Champs extras ».

    Répondre à ce message

  • 2

    Merci pour tout ce travail, notamment l’étude RS/CS. Le chantier n’est pas tout a fait terminé sur le sujet, mais bon, que les choses évoluent finalement bien ainsi au gré des usages...

    En ce qui concerne le code de surcharge pour étendre ou modifier les lames du CS, l’utilisation d’une globale n’est plus recommandée. Il vaut mieux désormais encapsuler le code dans une fonction, histoire de gagner en mémoire et en performance :

    function autobr_surcharger_outil($tab) {
    	$tab['traitement:CHAPO:pre_propre,
    	traitement:PS:pre_propre,
    	traitement:NOTES:pre_propre,
    	traitement:TEXTE/rubriques:pre_propre,
    	traitement:TEXTE/breves:pre_propre'] = 'autobr_pre_propre';
    	return $tab; 
    }

    Ce code signifie que les balises #CHAPO, #PS, #NOTES et #TEXTE [1] passent automatiquement par le filtre autobr_pre_propre qui traite les alinéas, le Couteau Suisse ne proposant nativement que les contenus #TEXTE d’article.

    Pour le plugin Agenda, il suffit d’ajouter la ligne suivante à la fonction ci-dessus pour que le CS traite également les descriptifs d’évènement :

    	$tab['traitement:DESCRIPTIF:pre_propre'] = 'autobr_pre_propre';
    • L’article est maintenant rectifié selon ces nouvelles indications. Merci.

    • N.B. : Ne pas mettre la ligne traitement:NOTES:pre_propre, — Les « Notes » de bas de page sont traitées sans cette ligne de code, et l’ajout spécifique du traitement des « Notes » fait doublon et provoque un double retour à la ligne, donc un saut de ligne, donc dans les notes un nouveau paragraphe pour SPIP. (En fait, c’est moi qui avais ajouté le traitement de « NOTES », initialement, dans ce code, par excès de zèle donc… frdm)

      Finalement, dans config/mes_options.php il faut donc :

      function autobr_surcharger_outil($tab) {
          $tab['traitement:DESCRIPTIF:pre_propre,
          traitement:CHAPO:pre_propre,
          traitement:PS:pre_propre,
          traitement:TEXTE/rubriques:pre_propre,
          traitement:TEXTE/breves:pre_propre'] = 'autobr_pre_propre';
          return $tab; }

    Répondre à ce message

  • 4

    Très pratique ce plugin pour ne pas déstabiliser les utilisateurs habituels, non férus des techniques spécifiques à SPIP ou qui n’ont pas envie de les apprendre.
    Serait-il possible de généraliser ce fonctionnement ? Comme pour le filtre qui permet d’enlever le numéro devant tous les champs titre, ne pourrait-on pas envisager que cette technique s’applique à tous les champs texte ou descriptif, comme par exemple ceux du plugin agenda ?
    De cette manière tous les plugins existants ou futurs pourraient bénéficier du retour à la ligne sans autre précision, du moment que leurs champs s’appellent titre, texte ou descriptif.
    Merci.

    • en fait tout champs sur lequel les raccourçis typographiques de SPIP sont appelés doit normalment respecter ces règles, avec ce plugin

    • Ça marche dans le champ descriptif mais pas dans le champ adresse.
      Je dois retourner chez le plugin agenda pour voir s’il considère les raccourcis SPIP, c’est ça ?

    • tout a fait

    • J’ai ajouté quelques lignes dans l’article pour y faire bénéficier directement les lecteurs de ces observations, avec lien vers ce fil de discussion de forum. Cf. ci-avant dans l’article nouvelle section « Tests particuliers ».

    Répondre à ce message

  • Sur forum.spip.org, Chris écrit :
    « Plugin absolument indispensable pour pallier a l’une des incohérences insupportable du pourtant si génial SPIP. ».
    Merci pour les contributeurs à ce plugin mentionnés dans l’article.

    Répondre à ce message

  • Les tests sur des versions de Spip antérieures à celle 2.1 seront les bienvenus.

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom