Nous allons donc voir aujourd’hui comment réaliser cela pour notre plugin. Nous allons découvrir comment ajouter un onglet et une page à l’interface d’administration de SPIP et comment réaliser un formulaire pour gérer et stocker ces données.

Je ne sais pas encore trop comment m’y prendre, mais je fais confiance à mon instinct pour trouver au fur et à mesure de l’avancement. Ce que je sais déjà, c’est que je souhaite créer un plugin offrant une interface graphique au plugin « champs extras » écrit hier et que cette interface soit accessible depuis la page « configuration » dans un onglet « champs extras ». Ca je le sais, donc codons le !

Créer le plugin...

Cela n’a maintenant plus aucun secret pour vous, on va créer ce plugin. Hier, ayant mis sur la zone le plugin réalisé (http://zone.spip.org/trac/spip-zone/changeset/25513), j’ai fait en sorte de séparer le « core » du plugin de ses « extensions ». Nous allons donc ajouter notre plugin dans le dossier « extensions » en créant un répertoire « interface » contenant le fichier plugin.xml ci dessous :

<plugin> <nom>Interface pour Champs Extras</nom> <auteur>Matthieu Marcillaud [->magraine.net]</auteur> <licence>GNU/GPL</licence> <version>0.1</version> <description> Offre une interface pour g&eacute;rer des champs extras. </description> <etat>dev</etat> <prefix>iextra</prefix> <necessite id="champsextras" version="[0.1;]" /> <options>iextra_options.php</options> <pipeline> <nom>declarer_champs_extras</nom> <inclure>base/iextra.php</inclure> </pipeline> <onglet id='iextra' parent='configuration'> <icone>images/iextra-24.png</icone> <titre>iextra:champs_extras</titre> </onglet> </plugin>

On indique donc que l’on va utiliser un fichier d’options, un pipeline, et que l’on demande à afficher un onglet supplémentaire sur la page de configuration de SPIP. Cet onglet est lié à la page exec/iextra.php.

Créons donc les fichiers nécessaires : images/iextra-24.png, iextra_options.php, base/iextra.php, exec/iextra.php et lang/iextra_fr.php. Ce dernier contient pour l’instant :

<?php $GLOBALS[$GLOBALS['idx_lang']] = array( //C 'champs_extras' => 'Champs Extras', ); ?>

A ce stade là, vous pouvez activer le plugin puis cliquer sur l’icône configuration de SPIP. Un nouvel onglet devrait apparaître.

Seulement, deux problèmes déjà :

• si l’on clique l’onglet, nous obtenons un message d’erreur « Fichier iextra introuvable », qui n’est pas très juste. En fait, ce n’est pas le fichier qui manque, mais la fonction "exec_iextra()" ou "exec_iextra_dist()" dans ce fichier puisque nous ne l’avons pas encore renseigné.
• tout administrateur du site peut accéder à l’onglet alors qu’il serait peut être préférable que seuls les webmestres (auteur numéro 1, ou déclarés explicitement webmestres) puissent y avoir accès.

Autoriser seulement les webmestres

Nous allons créer une autorisation pour l’affichage du bouton. Pour cela, nous allons utiliser la librairie d’autorisations de SPIP. SPIP dispose dans son code d’appels à des fonctions d’autorisations qui sont extensibles. Pour les onglets, SPIP appelle autoriser('onglet',$id), $id étant l’identifiant de l’onglet, inscrit dans le fichier plugin.xml

Lorsque SPIP appelle la fonction autoriser('onglet',$id), il regarde s’il existe une fonction autoriser_$id_onglet(), sinon une fonction autoriser_onglet(), sinon autoriser_$id(),sinon il utilise autoriser_defaut(). Ces fonctions sont déclarées dans la librairie inc/autoriser.php. Comme toutes les fonctions extensibles de SPIP, elles peuvent être suffixées de _dist.

Créons notre fonction d’autorisation dans le fichier iextra_options.php comme ceci :

function autoriser_iextra_onglet_dist($faire, $type, $id, $qui, $opt) { return autoriser('webmestre', $type, $id, $qui, $opt); }

La fonction qui renvoie simplement vrai ou faux (true ou false), appelle ici une autre autorisation déjà existante pour se baser dessus. Pour information, les paramètres reçus sont les suivants :

• $faire = 'onglet'
• $type = 'iextra'
• $id = '' dans ce cas, mais pour d’autres autorisation, correspond à l’identifiant de l’objet (exemple : autoriser('modifier','article',$id_article);)
• $qui contient les informations du visiteur/auteur connecté. Par exemple $qui['id_auteur'] contient l’identifiant de l’auteur connecté.
• $opt est un tableau d’option, vide la plupart du temps.

Maintenant le bouton n’apparaît que pour les webmestres du site. Faisons afficher quelque chose par l’onglet.

Préparer l’affichage de la page

Nous allons créer une fonction exec_iextra_dist() dans le fichier exec/iextra.php pour faire afficher quelque chose ! Commençons de la sorte :

<?php if (!defined("_ECRIRE_INC_VERSION")) return; include_spip('inc/presentation'); function exec_iextra_dist(){ // si pas autorise : message d'erreur if (!autoriser('configurer', 'iextra')) { include_spip('inc/minipres'); echo minipres(); die(); } // pipeline d'initialisation pipeline('exec_init', array('args'=>array('exec'=>'iextra'),'data'=>'')); // entetes $commencer_page = charger_fonction('commencer_page', 'inc'); echo $commencer_page(_T('iextra:titre_page_iextra'), "configuration", "configuration"); // titre echo "<br /><br /><br />\n"; // outch que c'est vilain ! echo gros_titre(_T('iextra:titre_iextra'),'', false); // barre d'onglets echo barre_onglets("configuration", "interface_extra"); // colonne gauche echo debut_gauche('', true); echo pipeline('affiche_gauche', array('args'=>array('exec'=>'iextra'),'data'=>'')); // colonne droite echo creer_colonne_droite('', true); echo pipeline('affiche_droite', array('args'=>array('exec'=>'iextra'),'data'=>'')); // centre echo debut_droite('', true); // contenu // ... // fin contenu echo pipeline('affiche_milieu', array('args'=>array('exec'=>'iextra'),'data'=>'')); echo fin_gauche(), fin_page(); } ?>

Cette fonction se décompose en plusieurs parties. D’abord on vérifie que le visiteur a l’autorisation de voir la page. Et justement, ajoutons l’autorisation dans notre fichier options, et modifions l’autorisation de l’onglet pour appeler une seule et même autorisation :

<?php function autoriser_iextra_onglet_dist($faire, $type, $id, $qui, $opt) { return autoriser('configurer', 'iextra', $id, $qui, $opt); } function autoriser_iextra_configurer_dist($faire, $type, $id, $qui, $opt) { return autoriser('webmestre', $type, $id, $qui, $opt); } ?>

Ensuite, on trouve quelques déclarations de pipelines pour que d’autres plugins puissent ajouter des actions ou des contenus sur la page. On remarquera un découpage en 4 parties : en tête de page avec titre et onglets, colonne gauche, colonne droite, et centre.

Je trouve que cette partie là duplique beaucoup de code. Vivement que les parties exec (gérant l’affichage privé) de SPIP passent toutes en squelettes, ça allégera beaucoup l’écriture.

En attendant, tachons d’afficher quelque chose...

Deux pages : la vue et l’édition

Nous allons dupliquer la page exec/iextra.php que nous venons de réaliser pour créer un fichier exec/iextra_edit.php qui permettra de créer ou modifier de nouveaux champs. Evidemment, il faut changer les noms transmis aux pipelines, qui deviennent alors ’iextra_edit’.

Avant d’aller plus loin, précisons la manière dont nous allons stocker les valeurs des extras ajoutés : nous les enregistrerons dans la table spip_meta de SPIP, dans l’entrée ’iextras’. Nous allons tout de suite créer des petites fonctions permettant de stocker et récupérer ces données, dans un fichier inc/iextras.php tel que :

<?php if (!defined("_ECRIRE_INC_VERSION")) return; function iextra_get_extras(){ $extras = @unserialize($GLOBALS['meta']['iextras']); if (!is_array($extras)) $extras = array(); return $extras; } function iextra_set_extras($extras){ ecrire_meta('iextras',serialize($extras)); return $extras; } // tableau des extras, mais classes par table SQL function iextra_get_extras_par_table(){ $extras = iextra_get_extras(); $tables = array(); foreach($extras as $i=>$e) { if (!isset($tables[$e['table']])) { $tables[$e['table']] = array(); } $tables[$e['table']][$i] = $e; } return $tables; } ?>

Ces fonctions vont nous être utiles pour la suite.

Ajouter un formulaire (CVT) dans la page

Nous allons créer et afficher un formulaire à la mode CVT (Charger Vérifier Traiter) de SPIP dans notre page d’édition. L’avantage de ces formulaires, c’est qu’on peut les coder au fur et à mesure : d’abord le HTML, puis les fonctions PHP de traitements.

Commençons par ajouter un squelette qui va appeler le formulaire. Créons le dans prive/editer/champs_extras.html avec ce contenu :

<div class='cadre-formulaire-editer'> <div class="entete-formulaire"> #ENV**{icone_retour} [<h1>(#ENV{titre})</h1>] </div> #FORMULAIRE_EDITER_CHAMP_EXTRA{#ENV{id_extra},#ENV{redirect}} </div>

En fait, On affiche une icône de retour, un titre, puis le formulaire que nous allons créer, prenant 2 paramètres : l’identifiant du champ extra en cours de lecture s’il existe, et un paramètre de redirection qui servira à rediriger le navigateur après la saisie du formulaire.

Déclarons au fichier exec/iextra_edit.php d’afficher ce squelette en ajoutant dans la partie traitant du contenu :

$id_extra = intval(_request('id_extra')); $id_extra = $id_extra ? $id_extra : 'new' ; echo recuperer_fond('prive/editer/champs_extras', array( 'id_extra'=>$id_extra, 'titre'=>$id_extra=='new' ? _T('iextra:info_nouveau_champ_extra') : _T('iextra:info_modifier_champ_extra'), 'redirect'=>generer_url_ecrire("iextra"), 'icone_retour'=>icone_inline(_T('icone_retour'), generer_url_ecrire('iextra'), find_in_path("images/iextra-24.png"), "rien.gif",$GLOBALS['spip_lang_left']), ));

On demande donc la compilation du squelette, avec un certain nombre de variables d’environnement transmises. Le titre, par exemple, change si un id_extra est présent dans l’url.

Il faut maintenant créer la partie HTML du formulaire SPIP, dans le fichier formulaires/editer_champ_extra.html. Démarrons gentiment comme ceci :

<div class="formulaire_spip formulaire_editer formulaire_#FORM"> [<p class="reponse_formulaire reponse_formulaire_ok">(#ENV*{message_ok})</p>] [<p class="reponse_formulaire reponse_formulaire_erreur">(#ENV*{message_erreur})</p>] [(#ENV{editable}) <form method='post' action='#ENV{action}'><div> #ACTION_FORMULAIRE{#ENV{action}} <ul> #SET{fl,iextra} #SET{name,champ} #SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}} #SET{obli,obligatoire} <li class="editer_[(#GET{name})][ (#GET{obli})][ (#GET{erreurs}|oui)erreur]"> <label for="#GET{name}">[(#GET{fl}|concat{':label_',#GET{name}}|_T)]</label> [<span class='erreur_message'>(#GET{erreurs})</span>] <input type='text' class='text' name='#GET{name}' id='#GET{name}' value="#ENV{#GET{name}}" /> </li> </ul> [(#REM) ajouter les saisies supplementaires : extra et autre, a cet endroit ] <!--extra--> <p class='boutons'><input type='submit' class='submit' value='<:bouton_ajouter:>' /></p> </div></form> ] </div>

Cette structure HTML est celle utilisée pour les formulaires d’édition de SPIP. Une div encadre le formulaire, les messages de réussite ou d’échec sont affichés juste avant le formulaire lorsqu’ils existent. L’action du formulaire est donnée par une variable #ENV{action} et des champs cachés servant à contrôler l’authentification de l’auteur pour les valeurs transmises sont affichés avec la balise #ACTION_FORMULAIRE.

Les différents champs de saisie sont ensuite placés dans une liste ul/li. Nous n’en n’avons mis qu’un seul pour le moment.

A partir de cet instant, le formulaire s’affiche sur la page ecrire/?exec=iextra, mais il manque des chaines de langue, ajoutons les :

<?php $GLOBALS[$GLOBALS['idx_lang']] = array( //C 'champs_extras' => 'Champs Extras', //I 'info_modifier_champ_extra' => 'Modifier champ extra', 'info_nouveau_champ_extra' => 'Nouveau champ extra', //L 'label_champ' => 'Nom du champ', //T 'titre_page_iextra' => 'Champs Extras', 'titre_iextra' => 'Champs Extras', ); ?>

Nous allons maintenant ajouter d’autres champs à notre formulaire. Mais nous allons prendre un paramètre supplémentaire en compte : lorsque le formulaire sera en modification, certains champs ne seront visibles qu’en lecture, ceci parce qu’on ne va pas gérer les changements de nom des champs (passer un champ ’ps’ en ’postscriptum’ dans la table SQL), pour éviter des complications dont on se passera bien pour le moment !

Nous supposerons que #ENV{new} indique si le formulaire est nouveau (ajout) ou non (modification). On verra comment ensuite.

Terminer la partie HTML du formulaire

On modifie donc le contenu du formulaire précédent comme ceci :

#SET{fl,iextra} #SET{name,champ} #SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}} #SET{obli,obligatoire} #SET{disabled,#ENV{new}|non} <li class="editer_[(#GET{name})][ (#GET{obli})][ (#GET{erreurs}|oui)erreur]"> <label for="#GET{name}">[(#GET{fl}|concat{':label_',#GET{name}}|_T)]</label> [<span class='erreur_message'>(#GET{erreurs})</span>] <p class="explication"><:iextra:caracteres_autorises_champ:></p> <input type='text' class='text' name='#GET{name}' id='#GET{name}' value="#ENV{#GET{name}}"[ (#GET{disabled})disabled='disabled'] /> </li>

Une entrée ’disabled’ apparait maintenant sur ce champ si l’on est en modification.

Ajoutons maintenant, après le </li> l’entrée suivante, qui va servir à sélectionner la table souhaitée.
On pourrait écrire :

#SET{name,table} #SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}} #SET{obli,obligatoire} #SET{disabled,#ENV{new}|non} <li class="editer_[(#GET{name})][ (#GET{obli})][ (#GET{erreurs}|oui)erreur]"> <label for="#GET{name}">[(#GET{fl}|concat{':label_',#GET{name}}|_T)]</label> [<span class='erreur_message'>(#GET{erreurs})</span>] <select name='#GET{name}' id='#GET{name}'[ (#GET{disabled})disabled='disabled']> #SET{type,article} <option value='#GET{type}'[ (#ENV{#GET{name}}|=={#GET{type}}|oui)selected='selected']>[(#GET{fl}|concat{:,#VAL{table_},#GET{type}}|_T)]</option> #SET{type,auteur} <option value='#GET{type}'[ (#ENV{#GET{name}}|=={#GET{type}}|oui)selected='selected']>[(#GET{fl}|concat{:,#VAL{table_},#GET{type}}|_T)]</option> #SET{type,rubrique} <option value='#GET{type}'[ (#ENV{#GET{name}}|=={#GET{type}}|oui)selected='selected']>[(#GET{fl}|concat{:,#VAL{table_},#GET{type}}|_T)]</option> </select> </li>

Mais on se rend compte que l’on écrit 3 fois presque le même code dans les options de la balise <select>. On va donc utiliser une boucle particulière pour s’affranchir de cela : la boucle POUR.

Pour l’utiliser, il faut (pour SPIP 2.0 en tout cas) utiliser le plugin SPIP Bonux. Nous ajoutons donc sa dépendance dans le fichier plugin.xml :

<necessite id="spip_bonux" version="[1.2;]" />

On peut maintenant remplacer le contenu du <select> précédent par celui bien plus court :

<BOUCLE_liste_objet(POUR){tableau #ARRAY{0,article,1,auteur,2,rubrique}}> <option value='#VALEUR'[ (#ENV{#GET{name}}|=={#VALEUR}|oui)selected='selected']>[(#GET{fl}|concat{:table_,#VALEUR}|_T)]</option> </BOUCLE_liste_objet>

Cependant, nous avons maintenant un problème : une boucle à l’intérieur du code d’une balise, et cela n’est pas permis. Effectivement, cette boucle est à l’intérieur de la balise [(#ENV{editable}) ...] ouverte en haut du formulaire. Il faut la remplacer par une boucle (CONDITION), permise par ce même plugin SPIP Bonux, comme ceci :

<BOUCLE_si_editable(CONDITION){si #ENV{editable}}> ... </BOUCLE_si_editable>

Ajoutons les derniers champs manquant à la suite :

#SET{name,label} #SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}} #SET{obli,obligatoire} #SET{disabled,''} <li class="editer_[(#GET{name})][ (#GET{obli})][ (#GET{erreurs}|oui)erreur]"> <label for="#GET{name}">[(#GET{fl}|concat{':label_',#GET{name}}|_T)]</label> [<span class='erreur_message'>(#GET{erreurs})</span>] <input type='text' class='text' name='#GET{name}' id='#GET{name}' value="#ENV{#GET{name}}" [ (#GET{disabled})disabled='disabled']/> </li> #SET{name,type} #SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}} #SET{obli,obligatoire} #SET{disabled,''} <li class="editer_[(#GET{name})][ (#GET{obli})][ (#GET{erreurs}|oui)erreur]"> <label for="#GET{name}">[(#GET{fl}|concat{':label_',#GET{name}}|_T)]</label> [<span class='erreur_message'>(#GET{erreurs})</span>] <select name='#GET{name}' id='#GET{name}'[ (#GET{disabled})disabled='disabled']> <BOUCLE_liste_types(POUR){tableau #ARRAY{0,textarea,1,input}}> <option value='#VALEUR'[ (#ENV{#GET{name}}|=={#VALEUR}|oui)selected='selected']>[(#GET{fl}|concat{:type_,#VALEUR}|_T)]</option> </BOUCLE_liste_types> </select> </li> #SET{name,sql} #SET{obli,obligatoire} #SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}} #SET{disabled,#ENV{new}|non} <li class="editer_[(#GET{name})][ (#GET{obli})][ (#GET{erreurs}|oui)erreur]"> <label for="#GET{name}">[(#GET{fl}|concat{':label_',#GET{name}}|_T)]</label> [<span class='erreur_message'>(#GET{erreurs})</span>] <input type='text' class='text' name='#GET{name}' id='#GET{name}' value="#ENV{#GET{name}}"[ (#GET{disabled})disabled='disabled']/> </li>

Comme vous le voyez, les listes ont beaucoup de codes en commun. On pourra imaginer un jour que SPIP fournisse des inclusions pour gérer les principaux types de champs de façons à ne pas trop dupliquer de code comme ici.

Modifions le bouton pour qu’il affiche soit ajouter soit modifier :

<p class='boutons'><input type='submit' class='submit' value='[(#ENV{id_extra}|intval|?{<:bouton_modifier:>,<:bouton_ajouter:>})]' /></p>

Poursuivons notre plugin en ajoutant les champs de langue manquant :

<?php $GLOBALS[$GLOBALS['idx_lang']] = array( //A 'action_modifier' => 'Modifier', 'action_supprimer' => 'Supprimer', //C 'champs_extras' => 'Champs Extras', //L 'label_champ' => 'Nom du champ', 'label_table' => 'Objet', 'label_label' => 'Label de la saisie', 'label_sql' => 'D&eacute;finition SQL', 'label_type' => 'Type de saisie', //T 'table_article' => 'Articles', 'table_auteur' => 'Auteurs', 'table_rubrique' => 'Rubriques', 'titre_page_iextra' => 'Champs Extras', 'titre_iextra' => 'Champs Extras', 'type_input'=>'Afficher une saisie input de type texte', 'type_textarea'=>'Afficher une saisie textarea', ); ?>

Pré-remplir le formulaire CVT

Les champs de notre formulaire sont vides par défaut, mais nous aimerions que la ligne ’SQL’ soit déjà remplie avec un exemple. De même, afin de pouvoir modifier un champ déjà présent, nous devons pré-remplir le formulaire avec les valeurs du champ en question.

C’est le rôle de la partie « Charger » des formulaires CVT. Pour l’utiliser, il faut créer un fichier PHP homonyme à notre formulaire : formulaires/editer_champ_extra.php et créer la fonction formulaire_editer_champ_extra_charger_dist(). Cela peut donner :

<?php if (!defined("_ECRIRE_INC_VERSION")) return; function formulaires_editer_champ_extra_charger_dist(){ $valeurs = array( 'champ' => '', 'table' => '', 'type' => '', 'label' => '', 'sql' => "text NOT NULL DEFAULT ''", ); return $valeurs; } ?>

Cette fonction retourne un tableau de valeurs pré-chargées. Si le formulaire a déjà été posté une première fois mais a besoin d’être rechargé, par exemple parce que les informations retournées ne sont pas valides, ce seront les informations postées qui seront alors utilisées pour réafficher le formulaire.

Tous les éléments envoyés par le formulaire sont insérés dans l’environnement du squelette calculé, de sorte que l’on récupère les valeurs par #ENV{cle_du_tableau}. Ce n’est pas visible ici, mais toutes les chaines transmises sont protégées de sorte que les apostrophes de poseront pas de problème sur les arguments des balises HTML.

Parfois, on souhaitera néanmoins transmettre des informations telles quelles, dans ce cas, CVT propose un nommage spécial : les clés sont alors préfixées d’un signe souligné. Exemple : '_config'=>$GLOBALS['meta']['ma_meta'], récupérable ensuite avec #ENV{_config} (Exemple un peu idiot vu qu’on pourrait faire simplement #CONFIG{ma_meta} !).

Voyons comment ajouter aussi les informations lorsque nous demandons à modifier un champ extra existant. Ajoutons au passage dans l’environnement envoyé un paramètre ’new’, vide si nous sommes en modification, non vide si effectivement c’est une création. Modifions la fonction charger pour cela :

<?php if (!defined("_ECRIRE_INC_VERSION")) return; include_spip('inc/iextra'); function formulaires_editer_champ_extra_charger_dist($id_extra='new', $redirect=''){ // valeur par defaut $valeurs = array( 'champ' => '', 'table' => '', 'type' => '', 'label' => '', 'sql' => "text NOT NULL DEFAULT ''", 'id_extra' => $id_extra, 'new' => intval($id_extra)?'':' ', ); // si un extra est demande (pour edition) // remplir les valeurs avec infos de celui-ci if (intval($id_extra)) { $extras = iextra_get_extras(); // $id_extra = 1, mais l'entree reelle est 0 dans le tableau if (is_array($extras[--$id_extra])) { $valeurs = array_merge($valeurs, $extras[$id_extra]); } } return $valeurs; } ?>

La fonction a été modifiée : elle porte maintenant les 2 paramètres transmis par la balise #FORMULAIRE_EDITER_CHAMP_EXTRA : l’identifiant et la redirection. Les paramètres passés aux balises #FORMULAIRE sont transmis, par défaut, telles quelles dans les fonctions charger, vérifier ou traiter de CVT. Cependant, il est parfois indispensable de modifier ces comportements, pour ajouter par exemple automatiquement certains autres paramètres. Dans ce cas, il faut créer une fonction de balise dynamique dans le répertoire balise/ mais c’est inutile pour notre besoin.

Le premier argument sert à récupérer les valeurs de l’extra, stockées dans le tableau $extras. Par facilité ici, le tableau $extras a des clés automatiquement gérées par PHP et commencent donc par zero. Pour ne pas confondre avec un champ nouveau, j’incrémente la clé de 1 dans l’appel à la page d’édition : ?exec=iextra_edit&id_extra=1 correspond à $extras[0]. Ca sera certainement à revoir. Lorsque les données sont récupérées, on remplace les valeurs par défaut par les nouvelles.

Vérifier les valeurs soumises par le formulaire CVT

Nous allons créer une deuxième fonction de vérification des champs. Cette fonction va vérifier que ce qu’on a envoyé n’est pas vide d’une part et est d’une syntaxe correcte pour le nom du champ d’autre part. Enfin, qu’un champ identique n’est pas déjà présent lorsqu’on veut ajouter un nouveau champ extra.

function formulaires_editer_champ_extra_verifier_dist($id_extra='new', $redirect=''){ $erreurs = array(); // pas de champ vide foreach(array('champ', 'table', 'type', 'label', 'sql') as $c) { if (!_request($c)) { $erreurs[$c] = _T('iextra:veuillez_renseigner_ce_champ'); } } // 'champ' correctement ecrit if ($champ = trim(_request('champ'))) { if (!preg_match('/^[a-zA-Z0-9_-]+$/',$champ)) { $erreurs['champ'] = _T('iextra:caracteres_interdits'); } } // si nouveau champ, ou modification du nom du champ // verifier qu'un champ homonyme // n'existe pas deja sur la meme table $extras = iextra_get_extras(); if (!intval($id_extra) // $id_extra = 1, mais l'entree reelle est 0 dans le tableau OR ($extras[--$id_extra]['champ'] !== _request('champ'))) { foreach ($extras as $i=>$e) { if (($i !== $id_extra) and ($e['champ'] == $champ) and ($e['table']==_request('table'))) { $erreurs['champ'] = _T('iextra:champ_deja_existant'); } } } return $erreurs; }

Notre fonction ici retourne un tableau. Si ce tableau n’est pas vide, le formulaire n’est pas valide et est alors réaffiché avec les erreurs correspondantes. Dans notre cas, en cas d’erreur, on envoie un message pour le champ erroné. On pourrait aussi envoyer un message général, affiché en haut du formulaire avec $erreurs['message_erreur'] = 'texte';.

Effectuer un traitement par le formulaire CVT

On va créer une dernière fonction pour les traitements. Commençons par ne rien faire :

function formulaires_editer_champ_extra_traiter_dist(){ $res = array( 'editable' => true, 'message_ok' => _T('iextra:champ_sauvegarde'), ); return $res; }

Ici, on indique que le formulaire peut être réédité par derrière, et on envoie un message de succès au passage. Mais aucune action n’est encore effectuée avec les champs transmis.

Ce qui se passe, c’est qu’une fois qu’on a validé le formulaire, le message s’affiche, et le formulaire propose encore d’être modifié (les valeurs que l’on avait écrites sont toujours affichées). Cette fonction peut être pratique si l’on a besoin de rééditer les champs juste après, mais ce n’est pas ce que l’on attend ici.

On utilisera tout à l’heure une redirection pour indiquer de se rendre sur une autre page après la validation du formulaire en ajoutant 'redirect' => 'url'.

Mais je veux simplement vous montrer un petit truc dans le cas où vous souhaitez, juste après un enregistrement valide, saisir une nouvelle entrée. Pour cela, il faut vider les champs postés au formulaire après son traitement, permettant de saisir une nouvelle entrée. Mais pas trop tôt non plus - c’est à dire au prochain chargement - de sorte que les pipelines ’traiter’ des formulaires CVT puissent aussi utiliser les éléments envoyés ! Pour cela, au moment du traitement, on va ajouter une variable spécifique, et au chargement, on enlèvera les valeurs du champ posté si cette variable est présente.

On ajoute pour ça, si le traitement est bien effectué (qui reste encore à faire d’ailleurs !) un ajout de variable, avant le retour :

// pouvoir creer un second post set_request('formulaire_traite','oui');

On va le prendre en compte dans la partie charger en ajoutant :

// si le formulaire a ete traite, on supprime les valeurs postees // pour permettre de poster un nouveau formulaire if (_request('formulaire_traite')) { foreach ($valeurs as $cle=>$val) { set_request($cle, null); } }

Assez simple finalement. Mais nous disions que nous avons simplement besoin d’une redirection vers la page ’iextra’.

Traiter le formulaire CVT

Profitons en pour réaliser un petit traitement qui sauvegarde notre modification :

function formulaires_editer_champ_extra_traiter_dist($id_extra='new', $redirect=''){ // recuperer les valeurs postees $extra = array(); foreach(array('champ', 'table', 'type', 'label', 'sql') as $c) { $extra[$c] = _request($c); } // recreer le tableau de stockage des extras $extras = iextra_get_extras(); if (intval($id_extra)) { // $id_extra = 1, mais l'entree reelle est 0 dans le tableau $extras[--$id_extra] = $extra; } else { $extras[] = $extra; } // l'enregistrer iextra_set_extras($extras); $res = array( 'editable' => true, 'message_ok' => _T('iextra:champ_sauvegarde'), ); if ($redirect) $res['redirect'] = $redirect; return $res; }

Nous retournons un paramètre ’redirect’ qui indique le lieu d’une redirection après le traitement, s’il est présent.

Pour l’instant, notre formulaire ajoute les champs dans la table spip_meta. C’est bien tout ce qu’il fait ! Donnons lui le pouvoir d’afficher les champs créés par ce plugin, dans la page exec/iextra.php et de les modifier.

Afficher les champs déclarés

Ajoutons un appel à un squelette dans la page exec/iextra.php :

include_spip('inc/iextra'); echo recuperer_fond('prive/contenu/champs_extras', array( 'extras'=>iextra_get_extras_par_table(), ));

On transmet au squelette un tableau trié par table des extras déclarés. Affichons les dans le squelette prive/contenu/champs_extras :

<BOUCLE_si_extras(CONDITION){si #ENV{extras}}> [(#CHEMIN{images/iextra-24.png}|debut_cadre_trait_couleur{1, "", <:iextra:liste_des_extras:>})] <BOUCLE_tables(POUR){tableau #ENV**{extras}}> <h2>[(#VAL{iextra:table_}|concat{#CLE}|_T)]</h2> <B_extras> <ul> <BOUCLE_extras(POUR){tableau #VALEUR}> <li> [(#VALEUR|table_valeur{champ})] | <a href="[(#URL_ECRIRE{iextra_edit}|parametre_url{id_extra,#CLE|plus{1}})]"><:iextra:modifier:></a> | <a href=""><:iextra:supprimer:></a> </li> </BOUCLE_extras> </ul> </B_extras> </BOUCLE_tables> [(#VAL{1}|fin_cadre_trait_couleur)] </BOUCLE_si_extras>

On utilise encore les boucles CONDITIONS et POUR pour afficher le tableau. On transmet un lien pour modifier le contenu (avec #CLE|plus{1} pour éviter la clé 0).

Un autre pour le supprimer... mais ce n’est pas encore fait !
Occupons-nous en ! Pour la suppression, nous allons réaliser encore quelque chose de nouveau ! Génial non ?

L’avantage de cet exemple, c’est qu’il parcoure un grand grand nombre de concepts de SPIP.

Créer une action sécurisée pour la suppression

Le formulaire CVT sécurise automatiquement les actions : seul le visiteur qui affiche le formulaire peut, en le soumettant accéder aux fonctions vérifier et traiter grâce à une clé de contrôle vérifiant diverses informations. Bref, un auteur ne peut pas poster ou modifier des informations pour un autre.

Lorsque pour d’autres actions on a besoin d’une telle sécurité, SPIP prévoit des actions spécifiques. Vous avez vu les fonctions d’autorisations, qui est déjà un moyen de protection, nous allons voir un autre moyen : l’envoi d’une clé liée à l’auteur dans une url qui sera vérifiée par le script d’action appelé.

Une balise permet de créer ces urls : #URL_ACTION_AUTEUR{nom_action, arguments, retour}. Créons déjà notre url de suppression :

| <a href="[(#URL_ACTION_AUTEUR{iextra, [supprimer_extra/(#CLE|plus{1})], #SELF})]" class="supprimer"><:iextra:supprimer:></a>

Puis faisons en sorte qu’il y ait un javascript de confirmation en mettant, un peu en dessous un script jQuery :

<script type="text/javascript"> (function($) { $('ul.liste_extras .supprimer').click(function(){ return confirm("[(#VAL{iextra:supprimer_reelement}|_T|attribut_html)]"); }); })(jQuery); </script>

Et maintenant, créons le fichier d’action dans action/iextra.php et contenant :

<?php if (!defined("_ECRIRE_INC_VERSION")) return; function action_iextra_dist() { $securiser_action = charger_fonction('securiser_action', 'inc'); $arg = $securiser_action(); // droits include_spip('inc/autoriser'); if (!autoriser('configurer', 'iextra')) { include_spip('inc/minipres'); echo minipres(); exit; } list($arg, $id) = explode ('/', $arg); // actions possibles if (!in_array($arg, array( 'supprimer_extra'))){ include_spip('inc/minipres'); echo minipres(_T('iextra:erreur_action',array("action"=>$arg))); exit; } // cas de suppression if ($arg == 'supprimer_extra'){ include_spip('inc/iextra'); $extras = iextra_get_extras(); if ($id = intval($id)) { // $id a 1 de plus unset($extras[--$id]); iextra_set_extras($extras); } } } ?>

Les 2 premières lignes de la fonction vérifient que les paramètres soumis correspondent bien à l’auteur qui a cliqué le lien. Dans le cas contraire, un message d’erreur apparait et le script s’arrête (sur l’appel de $securiser_action();).

Cette fonction permet au passage de récupérer le deuxième argument de la balise, c’est à dire les arguments (séparés ici par des barres obliques (/)).

Une fois cette vérification faite, on vérifie que l’auteur a bien l’autorisation de configurer les champs extras (normalement c’est inutile vu que pour obtenir le lien il devait déjà avoir cette autorisation !).

Enfin, on effectue la suppression si c’est bien ce qui est demandé, pour l’instant, uniquement la suppression dans l’entrée de la table spip_meta. Le script redirigera ensuite automatiquement vers l’url donné par le troisième argument de la balise.

Déclarer les champs au plugin Champs Extras

Avant de gérer la création effective des champs dans les tables lorsqu’on les ajoute, nous allons commencer par déclarer les champs créés dans le pipeline correspondant. Cela va être utile pour la suite, car si les champs sont déclarés, SPIP peut gérer automatiquement leur création ensuite en appelant les fonctions adaptées.

Créons la fonction iextra_declarer_champs_extras_dist() dans le fichier base/iextra.php :

<?php if (!defined("_ECRIRE_INC_VERSION")) return; function iextra_declarer_champs_extras_dist($champs=array()) { include_spip('inc/iextra'); $extras = iextra_get_extras(); foreach($extras as $e) { $champs[] = new ChampExtra($e); } return $champs; } ?>

Créer effectivement un champ lors de son ajout

Nous allons modifier la fonction traiter du formulaire pour qu’il crée effectivement le champ dans la table voulue lors de sa création.

On se crée une petite variable $new pour tester si l’entrée est nouvelle, puis on appelle la fonction maj_tables() :

// l'enregistrer iextra_set_extras($extras); // creer le champ s'il est nouveau : if ($new) { include_spip('base/create'); $table = table_objet_sql($extra['table']); maj_tables($table); }

Supprimer effectivement le champ à la suppression

Même chose, on modifie l’action pour effectuer la suppression demandée :

// cas de suppression if ($arg == 'supprimer_extra'){ include_spip('inc/iextra'); $extras = iextra_get_extras(); if ($id = intval($id)) { // $id a 1 de plus $extra = $extras[--$id]; unset($extras[$id]); iextra_set_extras($extras); $table = table_objet_sql($extra['table']); sql_alter("TABLE $table DROP $extra[champ]"); } }

Il faut récupérer les informations de l’extra avant de le supprimer pour pouvoir les utiliser dans la requête de suppression.

The End

Fin de ce chapitre qui a permi de découvrir un peu le principe des autorisations, des actions en base, des formulaires CVT, des fichiers exec...

Il y a bien sûr plein de choses à améliorer encore dans le plugin :

• pouvoir ajouter des champs déjà créés dans les tables par des requêtes manuelles via phpMyAdmin,
• gérer d’autres type que input text et textarea, comme les select et checkbox que permettaient les champs extras sérialisés de SPIP (passés en plugin eux-aussi)
• gérer l’ordre d’affichage des champs extra
• ...

En attendant, voici le plugin en zip, qui est aussi actualisé sur la zone. Ce zip est le résultat au terme de ce tutorial et fonctionne avec le plugin créé hier, et SPIP 2.0.2. Ce plugin d’interface et son parent vont certainement évoluer sur la zone au fil du temps. A suivre donc.