Carnet Wiki

Surcharger un formulaire du privé

Utiliser des pipelines pour surcharger un formulaire de l’espace privé SPIP 3.

L’interface privée de SPIP 3 est complètement écrit en formulaires CVT avec une topologie Z : cela rend facile à un webmestre de personnaliser ses écrans privés, mais au risque de perdre les éventuelles améliorations apparaissant dans de nouvelles versions.

Une solution plus propre serait d’utiliser des pipelines spécialisés : voyons la démarche de mise en place à partir d’un exemple.

Le besoin s’est fait jour sur l’utilisation du plugin Mes Préférences, qui posait un problème de fonctionnement sur son design “Elastic” ; et la référence étudiée s’appuie sur l’exemple du plugin Polices Privées, qui intervient déjà sur cet écran

extrait de l'ecran SPIP3 configurer_preferences
extrait de l’ecran SPIP3 configurer_preferences

La surcharge classique de formulaires

Grace au système des formulaires CVT, il est facile de personnaliser des formulaires dans l’’espace public, et dans l’espace privé : dans ce dernier cas, il suffit de créer un sous-dossier ./prive/formulaires/ dans votre répertoire de squelettes, et d’y coller des copies des deux fichiers ( configurer_preferences.html et configurer_preferences.php depuis leur dossier d’origine ./prive/formulaires/ de la racine de SPIP). Le sytème de surcharge de chemin de SPIP va donc donner la pré-éminence à vos nouvelles copies (chargées dans notre cas depuis ./plugins/mes_preferences/privés/formulaires/.

Notez bien que dans ce cas, on annule et remplace les fichiers d’origine !
Ce n’est pas très pérenne [1].

L'ecran surchargé pour Mes préférences
L’ecran surchargé pour Mes préférences
Un champ supplémentaire (4 boutons-radio) est ajouté au début du formulaire ;
une valeur supplémentaire est insérée dans le dernier champ de bouton-radios.

Le code du formulaire configurer_preferences du core n’utilise pas directement les facilités du plugin saisies ; neanmoins il utilise des blocs input standars, paramétrés par la valorisation de l’attribut name au nom du champ à traiter : vous verrez donc chaque bloc <li ....  input..> introduit par une ligne du genre ( ici pour le champ nommé “theme”.) :

#SET{name,theme} #SET{erreurs,#ENV**erreurs}|table_valeur{#GET{name}}}
#SET{obli,''}

Le paramétrage supplémentaire voulu

En fait, l’objectif est d’ajouter des champs (et également des options de choix) supplémentaires : ainsi le nouvel écran a-t-il proposé un nouveau champ theme (composé de quatre boutons radios de choix de la valeur des icônes de bandeau).

Le traitement de la largeur d’ecran (à stocker dans une variable de nom spip_ecran dans la $GLOBALS['spip_ecran'], et dans un cookie..) est plus complexe, car d’une part il faut rajouter un choix supplémentaire dans le bloc du champ de name =spip_ecran ; et il faut aussi tenir compte de d’un autre plugin apte à modifier cette valeur [2].

<div class="choix">
 <input type='radio' class='radio' name='#GET{name}' id='[(#GET{name})]_elastic'[(#ENV{#GET{name}}|=={elastic}|oui)checked="checked" ]value="elastic" onchange="if (this.checked) jQuery('body').addClass('elastic').removeClass('elastic'); else jQuery('body').removeClass('elastic').addClass('elastic');"/>
 <label for="[(#GET{name})]_elastic"><:mes_preferences:info_elastic:></label>
</div>

Activer un pipeline

Une solution propre consiste à rajouter par pipelines le bloc de code correspondant aux champs supplémentaires voulus : comment ce fait-se ?

Les plugins savent facilement activer des pipelines, identifiés par leur nom :
le terme de pipeline désigne un pré/ou/post-traitement (une fonction php) appliqué automatiquement par le compilateur SPIP au squelette résultant, ici au HTML généré par un #FORMULAIRE_.. ; il faut différentier dans cette interprétation :
-  le point d’entrée défini dans le core de SPIP par ses développeurs,
(voir la liste , issue du code de pipelines existants. )
-  la fonction utilisateur activée à ce traitement pour un cas d’usage
La fonction de pipeline s’injecte en traitement sur le $flux de texte HTML en-cours de compilation par SPIP : elle filtre et modifie ce flot de texte, pour altérer le code, avant de retourner le flux modifié à son contexte d’appel...
La déclaration des pipelines activés s’inscrit dans paquet.xml en SPIP 3 : ainsi notre plugin “modèle” utilise quatre pipelines avec la déclaration suivante dans paquet.xml :

        <pipeline nom="formulaire_charger" inclure="polpriv_pipelines.php" />
        <pipeline nom="formulaire_verifier" inclure="polpriv_pipelines.php" />
        <pipeline nom="recuperer_fond" inclure="polpriv_pipelines.php" />
        <pipeline nom="header_prive" inclure="polpriv_pipelines.php" />

On peut alors se reporter au source du fichier des fonctions activées par le plugin...
-  Les deux fonctions de pipelines formulaire_charger et formulaire_verifier , pour s’appliquer au bon formulaire, doivent tester le nom de formulaire à surcharger, par
   if ($flux['args']['form'] == 'configurer_preferences'){  
-  on rajoute aussi du contenu par un recuperer_fond, qui teste l’écran traité, mais d’une façon analogue et non identique
  if ($flux['args']['fond'] == 'formulaires/configurer_preferences'){  
-  enfin la fonction de pipeline header_prive a pour objectif de rajouter les règles de style CSS appelant les polices sélectionnées dans le corps de toutes les pages utilisées en privé, en les insérant à la place du commentaire <!--extra--> dans le $flux['data']['texte'] envoyé au navigateur client.

[1la surcharge du fichier login.html avait représenté un souci bien réel en son temps... surtout quand les webmestres l’avaient oublié : vécu !

[2Il s’agit de la lame “Largeur d’ecran” du Couteau Suisse :en fait l’activation de cette lame effectue une surcharge de l’écran d’origine, désactivant ce champ, mais il lui serait utile de rajouter un message d’avertissement à la place...!

Mist. GraphX , YannX - Mise à jour :6 May 2019 at 10:44