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 ».
Discussions par date d’activité
7 discussions
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
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 :
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) :
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
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 ».Voir aussi les réponses de Maïeul ici.
Répondre à ce message
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 :
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 :
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 :Répondre à ce message
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 :
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.
Suivre les commentaires : |