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 ».
Aucune discussion
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.
Seguir los comentarios: |