SPIP

SPIP 3.0

cerdic, tetue — 2012-05-19T11:00:00Z

SPIP 3 : une version marquée par la réécriture complète de l'espace privé en squelettes, une forte modularisation et une boucle DATA révolutionnaire. Cette version a été publiée en mai 2012 et son support prend fin le 30 juin 2019.

Sommaire

SPIP 2.0 avait apporté les fonctionnalités permettant de l'utiliser comme un « framework » pour le développement d'applications Web, au-delà de sa vocation initiale de simple outil de publication.

SPIP 3 pousse la logique du « framework » jusqu'à se l'appliquer à lui-même : l'ensemble de l'espace privé de SPIP a été recodé en squelettes, sur la base des outils et fonctions proposés par le langage de squelettes de SPIP.

Cette remise à plat de l'espace privé a été l'occasion de repenser le fonctionnement des objets éditoriaux et de normaliser leur usage pour le rendre le plus générique possible : la plupart des particularités historiques de chaque objet (et les exceptions de traitement associées dans le code de SPIP) ont été gommées pour être ramenées à une simple déclaration.

La création de nouveaux objets éditoriaux et la personnalisation des objets existants deviennent ainsi beaucoup plus faciles et plus rapides.

SPIP 3 achève également la découpe du logiciel en plugins comme SPIP 2 l'avait amorcé : l'ensemble des fonctionnalités proposées par SPIP 2 repose dorénavant sur un noyau SPIP 3 accompagné de 23 plugins.

La découpe complète du noyau a permis de compléter ses API et points d'entrée pour les développeurs de plugins.

SPIP 3 se nourrit fortement des développements de la communauté SPIP-Zone, et marque une forte inversion : ce n'est plus le noyau qui tire les développements des plugins, mais les développements de plugins qui nourrissent l'avancée de SPIP par leurs expérimentations [1].

Parmi de nombreuses autres nouveautés fonctionnelles, SPIP 3 introduit une nouvelle boucle DATA qui permet enfin de boucler sur tout type de données et plus seulement sur les tables SQL. Il devient ainsi possible de parcourir soit une énumération, soit un fichier CSV, XML, YAML... Plus fort encore, la boucle DATA permet directement de boucler sur une URL : il devient possible de parcourir directement une feuille de calcul Google Spreadsheet, un calendrier en ligne, une liste de vidéos sur Youtube, des photos sur Flickr… le Web devient votre base de données !

Prérequis :
SPIP 3.0 requiert désormais au minimum une version 5.1.0 de PHP pour pouvoir fonctionner correctement.
Attention : SPIP 3.0 n'est pas compatible avec PHP 7.

Un nouvel espace privé [2]

Visuellement, l'espace privé demeure dans la continuité des versions précédentes, complété de nouvelles icônes, avec :

pour les icônes principales de navigation, un jeu spécifique réalisé pour SPIP par Sébastien Desbenoît,
pour le reste de la page, l'adoption d'un jeu dérivé de FatCow.

La refonte de l'interface est essentiellement technique, même si elle a également permis de résoudre un certain nombre de défauts ergonomiques historiques.

La navigation principale est repensée et réorganisée. Le menu déroulant, désormais entièrement navigable au clavier, intègre aussi des temporisations pour faciliter son utilisation à la souris et être plus robuste aux mouvements mal contrôlés.

L'ensemble de l'espace privé est donc réécrit sous forme de squelettes rangés dans le répertoire prive/squelettes organisés par sous-dossiers correspondants à un découpage de la page en blocs. Ce découpage est utilisé notamment pour le rafraîchissement des morceaux de page en Ajax, évitant le rechargement complet des pages et fluidifiant les interactions [3].

De nombreux points d'entrée (utilisés en premier lieu par les plugins du noyau) sont disponibles sous forme de pipeline pour permettre aux plugins d'étendre les fonctionnalités de l'espace privé.

Les pages de l'espace privé sont réorganisées et renommées. En particulier toutes les pages d'objets éditoriaux utilisent un nommage cohérent fondé sur le nom de l'objet.

La réécriture a également permis de remettre à niveau la structure complète du HTML et son accessibilité. Un référentiel a été mis en place pour que les développeurs de plugins puissent réutiliser les mêmes structures, et que les ajouts d'interface restent homogènes avec le noyau.

Toutes les listes d'objet sont des squelettes qu'il devient facile de personnaliser. Elles bénéficient toutes du tri par colonne et de pagination ajax.

Un système d'échafaudage des pages d'objet permet de construire automatiquement une interface minimale pour les nouveaux objets déclarés par les plugins. Chaque élément de cette interface par défaut peut ensuite être personnalisé en fonction des particularités de chaque objet : [4].

Tous les formulaires interactifs sont écrits sous forme de formulaires CVT, ce qui permet d'assurer des interactions de qualité avec gestion systématique des messages d'erreur, vérification de saisie, ajax robuste à volonté, saisie multipage si nécessaire… Ils sont ainsi tous facilement extensibles par les plugins.

Autre nouveauté, en mode édition, SPIP 3 prend en compte le retour à la ligne simple (il n'est désormais plus nécessaire d'utiliser « _ »).

Enfin, l'espace privé intègre un mécanisme technique de thèmes qui permet de personnaliser les feuilles de style ou tout ou partie des icônes. Ce mécanisme pourra être utilisé par un plugin proposant des variantes activables par chaque utilisateur en fonction de ses préférences.

Modularisation en plugins

SPIP 3 achève donc la découpe du logiciel en plugins. Son noyau conserve la gestion des articles, rubriques et auteurs ; le langage de squelettes et l'ossature de l'espace privé. Toutes les autres fonctionnalités sont externalisées dans des plugins, automatiquement installés dans la distribution par défaut de SPIP 3. Ces plugins fournis par défaut sont désormais placés dans un dossier plugins-dist/ [5]

Cette découpe du noyau a permis de compléter un certain nombre d'API implicites, maintenant à disposition des développeurs de plugins qui peuvent ainsi ajouter des fonctionnalités sans limite, en prenant modèle sur les plugins natifs de SPIP.

Dans le domaine des plugins, SPIP 3 amène également une refonte importante du formalisme de déclaration XML. Outre une lisibilité améliorée, cette évolution intègre la question des traductions de plugins, ainsi que les outils d'alimentation automatique d'un annuaire des plugins de SPIP et un outil de chargement.

Par ailleurs, les plugins peuvent bénéficier des fonctions de mise à jour de base de données du core (avec reprise sur timeout) par simple déclaration de la procédure.

Les plugins distribués par défaut avec SPIP sont :

Brèves s'occupe de l'objet éditorial Brèves.
Compagnon propose l'affichage de textes pédagogiques d'information et d'accompagnement lors des premiers accès à l'espace privé.
Compresseur déjà présent dans SPIP 2.1, prend en charge l'optimisation des performances du site en compressant et concaténant les feuilles de style CSS et les fichiers JavaScript embarqués dans la page.
Cette version du plugin améliore des feuilles par média. Utilisation de @media pour concaténer tous les médias en un seul fichier sans en modifier l'ordre de chargement. Gestion des urls absolues sans protocole pour que les feuilles de style compressées fonctionnent sur http et https.
Dump assure la gestion des sauvegardes et restaurations. La fonctionnalité a été complètement ré-écrite pour assurer une sauvegarde complète et fiable. Le format de sauvegarde est maintenant SQLite et toutes les tables sont systématiquement conservées. Votre hébergement doit donc disposer de SQLite. Si ce n'est pas le cas, réalisez vos sauvegardes via phpmyadmin ou toute autre interface de gestion de la base de données fournie par votre hébergeur.
Forum gère l'objet éditorial forum, tant pour le site public que pour les interactions éditoriales dans l'espace privé. Outre une interface de modération repensée, les forums sont maintenant utilisables sur tous les objets éditoriaux de SPIP (natifs ou ajoutés par des plugins).
Images, déjà dans SPIP 2.1, prend en charge tous les filtres d'images et de couleurs dans les squelettes.
jQuery UI implémente dans SPIP la librairie complémentaire. jQuery UI facilite la création de composants graphiques dynamiques : onglets, drag & drop, barres de progression, widgets, effets… [6]
Mediabox intègre dans SPIP par défaut une boîte pop-in pour visualiser les médias ou proposer des interactions [7].
Medias [8] prend en charge la gestion des documents et images. Il propose une refonte de l'interface et rend les documents utilisables sur n'importe quel objet éditorial.
Mots apporte la gestion des mots-clés et groupes de mots. Les mots-clés sont maintenant utilisables sur tous les objets éditoriaux.
Organiseur assure les fonctions de messagerie et calendrier interne de l'espace privé. L'interface est complètement refondue. La messagerie interne bénéficie de notification par email, et le calendrier repose sur la librairie FullCalendar qui permet une navigation fluide.
Pétitions gère les pétitions sur les articles et propose une interface de modération repensée.
Porte plume, déjà dans SPIP 2.1, assure l'aide à la saisie.
Révisions assure le versionage utilisable sur tous les objets éditoriaux de SPIP. L'interface de gestion des révisions est modernisée.
SafeHTML, déjà dans SPIP 2.1, prend en charge la sécurisation des contenus externes potentiellement dangereux.
Sites assure le fonctionnement de l'objet éditorial « Site syndiqué » ainsi que des articles syndiqués. Une interface de modération des articles syndiqués est proposée.
Squelettes par rubriques assure le fonctionnement des squelettes suffixés (article-2.html pour les articles de la rubrique 2 et de ses sous-rubriques).
Statistiques assure le calcul des statistiques du site et des articles, et propose un affichage complètement refondu.
Support vieux navigateur, déjà dans SPIP 2.1, propose des fonctions JavaScript activables pour permettre aux vieilles versions de navigateurs d'afficher correctement votre site.
Svp permet la gestion complète des plugins : installation, activation, mise à jour, recherche…
Textwheel est un moteur typographique qui supporte intégralement les raccourcis de SPIP, décrits désormais dans un fichier de règles au format YAML. Ce moteur permet une nette accélération du traitement des raccourcis (jusqu'à 2 fois plus rapide sur certains contenus), et facilite l'évolution et la personnalisation des raccourcis.
Urls Étendues supporte les URLs propres ou arborescentes, et propose une interface de configuration ainsi qu'une interface de gestion avancée optionnelle pour gérer finement les URLs de chaque page.
Vertèbres, déjà dans SPIP 2.1, permet au webmestre d'afficher le contenu d'une table SQL de SPIP au moyen d'un squelette généré automatiquement d'après la structure SQL de la table. Cet affichage se fait maintenant dans l'espace privé.

Nouveaux squelettes par défaut

Les squelettes par défaut ont été révisés, avec un nouvel habillage graphique, pour marquer le coup. Ils adoptent une nouvelle structure HTML de base qui anticipe le HTML5, « responsive » par défaut, et embarquent des sélecteurs conditionnels pour plus de souplesse CSS.

Par la répartition en plusieurs feuilles de styles utilisables indépendamment, à la carte (selon la méthode Daisy, voir Un, deux, trois… feuilles CSS !), ils constituent désormais un cadre d'intégration modulaire. Ils posent notamment une base typographique complète et harmonieuse, immédiatement utilisable pour démarrer un site. L'historique spip_style.css disparaît au profit de spip.css, feuille indispensable, à utiliser en complément de vos styles habituels.

De nouvelles fonctionnalités

Le support de SQLite a été nettement amélioré, et c'est le format de base de données proposé par défaut lors d'une nouvelle installation (quand il est supporté par le serveur), compte tenu de sa simplicité de mise en œuvre [9].

La gestion des objets éditoriaux est généralisée. Par suite, les auteurs, documents, mots-clés, forums, révisions et logos sont utilisables sur n'importe quel objet (tous ceux de SPIP mais aussi tout objet éditorial ajouté par un plugin avec la nouvelle API de déclaration).
La gestion du statut, de la date de publication, de la langue et de la traduction est également généralisée et utilisable sur tout objet par simple déclaration.
Lorsque le signalement de l'édition concourante est activé, tout objet édité est désormais pris en compte dans le signalement.

L'identité du site est complétée d'un slogan du site, entre titre et descriptif long, utilisable avec la balise #SLOGAN_SITE_SPIP.

L'écran de sécurité est intégré en standard.

Les logs (fichiers de trace) bénéficient d'une gestion par niveau d'importance. Par défaut, les logs sont beaucoup moins verbeux en production et ne signalent que les anomalies ou informations importantes. Le niveau de log peut être ajusté pour le debug ou le développement, permettant ainsi d'avoir toutes les informations nécessaires.

Le cron périodique qui reposait sur des fichiers a été supprimé au profit d'une file de tâches en attente (qui gère aussi les tâches périodiques). Cette file de tâches permet de programmer des actions asynchrones [10] et propose une API simple d'utilisation pour les développeurs de plugin.

L'ajax des squelettes ({ajax} sur les INCLURE) bénéficie d'une prise en charge des attributs ARIA pour améliorer son accessibilité. De plus, l'historique de navigation est aussi automatiquement pris en charge grâce à l'API « History » de HTML5 [11]. L'URL du navigateur est donc mise à jour automatiquement sur les liens ajax, et permet les retours en arrière sans soucis.

Les modèles utilisés dans du texte éditorial reçoivent automatiquement l'environnement du squelette dans lequel est affiché le texte [12].

Les formulaires des l'espace privé utilisent les possibilités de HTML5 avec par exemple les attributs required ou placeholder.

Les squelettes peuvent maintenant échapper les caractères # [ ] ( ) { } < > en utilisant une barre oblique \. Il devient possible d'écrire des conditions par exemple sur une case à cocher de formulaire de manière bien plus élégante, sans que les crochets de l'attribut name n'interfèrent avec les crochets de la balise englobante :

[(#ENV{param}|oui) Avec tendresse ?  ]

Raccourcis

Un raccourci pour les abréviations a été introduit nativement : [SNCF|Société Nationale des Chemins de fer Français] (ou [CMS|Content Management System{en}]) pour indiquer une langue différente du texte principal) génère une balise abbr [ n'est plus utilisée en HTML5." id="nh13">13].

Les modèles de document peuvent prendre en argument la largeur ou la hauteur pour réduire leur dimension : .

Les tableaux à 2 entrées (horizontale et verticale) sont désormais gérés correctement.

Il n'est désormais plus nécessaire d'utiliser le raccourci « _ » pour produire un retour ligne simple.
Pour retrouver le fonctionnement antérieur, ce nouveau comportement est débrayable en utilisant un define('_AUTOBR', ''); dans son fichier mes_options.php.

Boucles

Le système de boucles de SPIP a été généralisé pour s'appliquer non plus directement sur une table SQL mais sur un itérateur. Un itérateur SQL assure le fonctionnement historique des boucles sur les tables SQL, mais il devient possible de boucler sur toute donnée itérable : Les itérateurs de SPIP - la boucle (DATA)

Premier exemple de nouvelle application : la boucle DATA étend le fonctionnement des boucles à toute information structurée sous forme de tableau. Il devient possible de boucler sur un fichier CSV, sur une url distante qui renvoie une information en JSON... :

Pour assurer la migration facile des squelettes qui utilisaient des boucles POUR et CONDITION, celles-ci sont également supportées comme cas particuliers de la boucle DATA, dans la même syntaxe que celle qui existait.

Critères

{si ...} : permet de conditionner l'exécution d'une boucle à la condition exprimée dans le critère, qui ne dépend pas des données en base mais du contexte du squelette.

{tri ...} : associé à la balise #TRI pour des tris faciles.

{feuille} : permet de sélectionner les rubriques sans enfants (celles tout en bas de la hiérarchie).

{noeud} : permet de sélectionner les rubriques qui ont des enfants.

{!racine} : exclut les rubriques de la racine.

{profondeur=3} : permet de sélectionner les rubriques du 3e niveau (les rubriques secteurs sont le niveau 0, puis les rubriques du dessous le niveau 1 etc.).

{id_parent} voit son comportement modifié en l'absence de boucle RUBRIQUES englobante : auparavant, id_parent prenait le id_rubrique de contexte (#ENV{id_rubrique}), désormais {id_parent} prend le id_parent de contexte (#ENV{id_parent}). En conséquent, on peut désormais écrire {id_parent}.

Pour migrer un boucle utilisant {id_parent} on peut :
- passer un contexte id_parent.
- utiliser {id_parent ?}{id_rubrique ?}.

Balises

Les modèles peuvent avoir un cache s'ils contiennent une balise #CACHE (mais par défaut ils n'en ont pas, comme auparavant).

Dans l'espace privé, les squelettes n'ont pas de cache non plus, sauf si une balise #CACHE est présente.

#LOGO_DOCUMENT peut prendre en argument le mode d'affichage du logo :

auto (par défaut, et c'est le fonctionnement historique) affiche automatiquement la vignette du document si existante, sinon un aperçu ; et sinon l'icône correspondant au type de document.
icone indique que c'est l'icône correspondant au type du fichier qui doit être affichée
apercu affiche un aperçu de l'image exclusivement, même si une vignette existe.
vignette affiche la vignette du document si elle existe, ou sinon rien.

La balise #SPIP_CRON disparaît et n'a plus d'effet dans les squelettes où elle serait encore utilisée.

#BOUTON_ACTION{libellé, url, classe, confirm, title, callback} génère un mini formulaire HTML avec un seul bouton qui affiche « libellé » et déclenche au clic un POST vers « url ». Cette balise est à utiliser de préférence à un lien quand la page « url » modifie la base de données. Si la « classe » contient la valeur « ajax » le bouton déclenchera un rechargement du bloc ajax qui l'inclue. « confirm » permet d'indiquer un message pour faire confirmer l'action par l'utilisateur, « title » le contenu de l'attribut homonyme sur le bouton, et « callback » une fonction javascript à appeler lors du clic sur le bouton.

#INFO_XXX{article, 13} : permet de retrouver le #XXX sans faire une boucle ARTICLES sur l'article 13 (utilisable pour toute boucle et tout champ de la boucle : #INFO_TITRE{article,13}, #INFO_NOM{auteur,2}...)

#CONFIG{nom} permet d'afficher la valeur de la meta de configuration nom.
Si la meta est un tableau, il est possible d'accéder directement à des sous valeurs avec la syntaxe #CONFIG{nom/sousvaleur} qui renverra la sousvaleur de la meta nom.
Pour accéder à la meta d'une table spécifique à un plugin, il faut utiliser la syntaxe #CONFIG{/metamonplugin/nom} : en commençant par un /, on indique que l'on veut la meta nom de la table spip_metamonplugin au lieu de la table spip_meta de SPIP.
Dans tous les cas, il est possible d'indiquer en second argument la valeur par défaut qui doit être utilisée si la meta n'existe pas encore : #CONFIG{nom,valeurpardefaut}

À l'instar de #CONFIG{nom/sousvaleur} les balises #ENV, #GET, #SESSION permettent d'utiliser des barres obliques pour obtenir des sous valeurs de tableau tel que :#ENV{nom/sousvaleur}, #GET{tableau/cle/souscle}, #SESSION{prefs/couleur}.

#PUBLIE : pour tester l'état (publié ou non) d'un objet. S'utilise dans une boucle, porte implicitement sur l'objet en cours ou avec des arguments explicites : [(#PUBLIE{article, 3}|oui) ... ], sur tout autre objet.

#CLE et #VALEUR sont les deux balises qui permettent d'afficher la clé et la valeur dans une boucle DATA
#VALEUR{x} permet d'afficher la sous valeur de x si #VALEUR est un tableau (équivalent à [(#VALEUR|table_valeur{x})]). On peut enchaîner plusieurs sous index #VALEUR{x/y/z} pour afficher une valeur dans un sous-niveau du tableau.

#PRODUIRE : renvoie le nom d'un fichier statique produit à partir d'un squelette. Utile pour une feuille de style calculée ou un fichier javascript calculé. La syntaxe est la même que pour la balise #INCLURE : #PRODUIRE{fond=mafeuille.css,couleur=ffffff} pour utiliser le squelette mafeuille.css.html

#LISTE{a,b,c} renvoie simplement un tableau contenant les valeurs a,b et c. C'est une écriture simplifiée de #ARRAY{0,a,1,b,2,c}.

#TOTAL_UNIQUE renvoie le nombre d'éléments affichés par l'intermédiaire du filtre |unique. Si on utilise |unique{nom}, il faut faire référence au même nom dans la balise : #TOTAL_UNIQUE{nom}

Dans l'espace privé :

#AIDER{surtitre} permet d'afficher un lien vers la section surtitre de l'aide de SPIP.

#BOITE_OUVRIR, #BOITE_PIED et #BOITE_FERMER permettent d'utiliser les boites stylées de l'espace privé :

#BOITE_OUVRIR{titre,classe} ouvre une boîte. le titre peut être omis. Les classes stylées dans l'espace privé sont : simple, info, note, raccourcis et important ;
le HTML qui suit est inclus dans la boîte ;
#BOITE_PIED permet de passer au pied de la boîte quand un pied est nécessaire.
#BOITE_FERMER ferme la boîte.

Pour de nombreux exemples, voir la page de l'espace privé ecrire/?exec=charte_boites proposée par le plugin http://plugins.spip.net/dev

#FORMULAIRE_RECHERCHE_ECRIRE affiche le formulaire de recherche de l'espace privé. On peut lui indiquer en premier argument l'url vers laquelle il doit pointer, et une classe en second argument. En présence de javascript le formulaire se comporte comme un lien vers url avec le paramètre recherche fourni par la saisie. Si on indique la classe ajax en second argument, le formulaire provoque le rechargement du bloc ajax incluant, comme un lien ajax donc : #FORMULAIRE_RECHERCHE_ECRIRE{#SELF, ajax}

#CHEMIN_IMAGE{article-24.png} renvoie le chemin vers l'icône article-24.png du thème de l'espace privé en cours d'utilisation par l'auteur connecté.

Filtres

|lien_ou_expose permet de construire simplement un menu de plusieurs liens en exposant celui qui est sélectionné par un et en gardant un lien sinon. Exemple : [(#URL_PAGE{mapage}|lien_ou_expose{libelle, #ENV{page}|=={mapage}, classe, title, rel})]

|singulier_ou_pluriel affiche une chaîne ou une autre en fonction du nombre sur lequel il est appliqué : [(#TOTAL_BOUCLE|singulier_ou_pluriel{1_article,nb_articles})]. 1_article et nb_articles sont des chaînes de langue qui reçoivent le nombre en argument @nb@. Si le nombre est zéro, le filtre n'affiche rien.

|balise_img permet de construire rapidement une balise HTML à partir d'un nom de fichier en renseignant systématiquement le width et le height pour accélérer le rendu de la page : [(#CHEMIN{monimage.png}|balise_img{alt,class})]

|affdate_debut_fin affiche sous forme sympathique un intervalle de temps entre une date de début et une date de fin, en prenant en compte le fait que la date de début et la date de fin sont ou non le même jour, le même mois, la même année, et en prenant en compte l'affichage de l'heure ou non (second argument, oui ou non). Exemple :
[(#DATE_DEBUT|affdate_debut_fin{#DATE_FIN,horaire})]

|timestamp ajoute au nom d'un fichier un horodatage sous la forme ?1234567890 où le nombre représente la date du fichier compté en secondes depuis le 1er janvier 1970. Ce filtre est utile pour référencer par exemple des feuilles de styles en s'assurant que le navigateur les rechargera quand leur url change :
[]

|objet_icone renvoie l'icône standard d'un objet de SPIP. Par défaut, la taille 24px est renvoyée sauf si la taille 16 ou 32 est demandée en argument : [(#OBJET|objet_icone{16})]

|objet_info renvoie une propriété d'un objet de SPIP telle que déclarée (ou automatiquement renseignée par SPIP) via l'API declarer_tables_objets_sql

|objet_afficher_nb affiche le nombre d'objets en prenant en compte le nombre auquel le filtre s'applique et les chaînes de langue déclarées pour l'objet : [(#TOTAL_BOUCLE|objet_afficher_nb{auteur})] affichera par exemple 1 auteur ou 23 auteurs.

|wrap encadre un texte d'une balise html : [(#TITRE|wrap{
})] produit le même résultat que [(#TITRE) ]

|generer_info_entite affiche le champ d'un objet SPIP : [(#ID_ARTICLE|generer_info_entite{article,titre})] renvoie le titre mis en forme de l'article #ID_ARTICLE. C'est équivalent ici à [(#INFO_TITRE{article,#ID_ARTICLE})].

Dans l'espace privé :

|icone_horizontale affiche une icône de l'espace privé au format horizontal. La syntaxe est : [(#URL|icone_horizontale{libelle,icone,fonction})]. icone peut être désigné en abrégé (article) et sera alors au format 24px ou explicitement (article-24.png). Le 3ème argument fonction précise une famille d'action associée à l'icône et peut être au choix add, del, edit, new, ou omis. Exemple [(#URL_ECRIRE{auteur_edit,new=oui}|icone_horizontale{<:icone_creer_nouvel_auteur:>,auteur,new})]

|icone_verticale affiche une icône de l'espace privé au format vertical. La syntaxe est la même que pour |icone_horizontale

|bouton_action_horizontal utilise la même syntaxe que |icone_horizontale et affichera un résultat visuellement semblable. Cependant le markup HTML sera du même type que celui de #BOUTON_ACTION pour déclencher un POST vers l'url et est donc utile quand l'url modifie la base de données.

|sinon_interdire_acces placé à n'importe quel endroit de la page permet de bloquer l'accès à celle-ci quand l'expression à laquelle il s'applique est fausse. Dans ce cas une page d'erreur est affichée, sauf si une url de redirection est fournie en argument (on peut aussi alors fournir un status http de redirection en second argument). On l'utilise généralement sur une vérification d'autorisation [(#AUTORISER{modifier,article,#ID_ARTICLE}|sinon_interdire_acces)]

JavaScript

SPIP 3 utilise la version 1.7.2 de jQuery et intègre désormais jQuery UI en version 1.8.20. Il devient possible d'utiliser une version différente de jQuery dans le site public en surchargeant simplement javascript/jquery.js dans le dossier squelettes/ sans risquer de casser l'espace privé.

Liens ajax :
Les liens .ajax ne cassent plus l'historique de navigation sur les navigateurs qui supportent l'API HTML5 History (Firefox, Safari, Chrome à la date de cet article). C'est-à-dire que lorsqu'on clique sur un lien ajax de SPIP qui recharge une partie de la page, l'URL est mise à jour dans le navigateur et le visiteur peut cliquer sur Précédent pour revenir en arrière.

Classes spéciales sur les liens ajax :

.nohistory indique que le lien n'affecte pas l'historique de navigation lorsqu'il est cliqué ;
.preload indique à SPIP que le contenu du lien ajax doit être préchargé au moment où la page est chargée. Ainsi le clic sur le lien produira une mise à jour immédiate ;
.nocache indique à SPIP que le contenu du lien ajax ne doit pas être mis en cache. Ainsi plusieurs clics sur le même lien provoqueront autant de chargements depuis le serveur (par défaut, seul le premier chargement à lieu pour une url donnée et le contenu est ensuite mémorisé par le navigateur).

Rechargement télécommandé de blocs ajax :
Les liens .ajax permettent par défaut le rechargement du bloc ajax qui les contient, mais il est parfois nécessaire de provoquer le rechargement d'un autre bloc ajax de la page.

Pour cela, il devient possible de nommer les blocs ajax au moment de leur inclusion :
. Le bloc ajax ainsi nommé peut ensuite être rechargé via l'appel de ajaxReload('nomdubloc');. Il est possible de passer en second argument une liste d'options contenant :

callback : fonction callback qui doit être appelée après le chargement ajax du bloc
args : liste d'argument qui seront passés à l'url lors du chargement du bloc (permet de modifier le #ENV du bloc mis à jour) ;
history : indique si le rechargement affecte ou non l'historique de navigation (faux par défaut).
Exemple :
ajaxReload('nomdubloc', { callback:function(){alert('fini');}, args:{id_article:3}, history:false });

ajaxReload peut être utilisé également sur un sélecteur jQuery auquel cas il provoquera le rechargement du plus petit bloc ajax qui contient l'élément ciblé. Il ne prend alors qu'un argument possible (le tableau d'options) : $('#contenu').ajaxReload({args:{id_article:3}})

Animations javascript :
Lors des interactions déclenchées par l'utilisateur, il est possible de déclencher plusieurs animations type qui s'appliquent toutes sur un sélecteur jQuery :

jQuery('#monid').animateLoading() déclenche l'animation de chargement sur #monid (automatiquement déclenchée lors des rechargements ajax)
jQuery('#monid').endLoading() arrête l'animation de chargement sur #monid (automatiquement déclenchée lors des rechargements ajax)
jQuery('#monid').animateAppend() anime le bloc #monid pour montrer qu'il vient d'être ajouté par l'interaction
jQuery('#monid').animateRemove() anime le bloc #monid pour montrer qu'il est supprimé par l'interaction

Fonctions utilitaires :
parametre_url() s'utilise comme sa version PHP de parametre_url pour ajouter, supprimer, récupérer des arguments d'une URL :

parametre_url(url,arg,value) ajoute arg=value à url et retourne l'url modifiée ;
parametre_url(url,arg,'') supprime la valeur de arg dans url et retourne l'url modifiée ;
parametre_url(url,arg) retourne la valeur de arg dans url

$('a').followLink() suit le lien en simulant un clic dessus (prend en compte le fait que le lien est ou non un lien ajax).

Popin dans l'espace privé :
Un lien vers une page de l'espace privé avec une classe .popin provoque l'ouverture d'une popin qui contient le coeur de la page pointée (bloc contenu/). Le lien conserve sa capacité à être ouvert dans un autre onglet via clic droit et la page complète est affichée dans ce cas.

API

SPIP 3 introduit plusieurs API génériques dans la gestion des objets éditoriaux :

une gestion générique des tables de liens d'un objet avec n'importe quel autre objet : c'est l'API editer_liens
La création de nouveaux objets éditoriaux est simplifiée par une API déclarative
une gestion générique des fonctions d'insertion, modification ou publication des objets éditoriaux : l'API editer_objet
objet_test_si_publie($objet, $id_objet) permet de tester facilement si un objet est publié ou non en fonction de son statut tel que déclaré (et en fonction d'une éventuelle post-publication)
generer_url_ecrire_objet($objet,$id_objet,$args, $ancre) renvoie l'url vers la page de l'objet dans l'espace privé. $args et $ancre sont optionnels.
le pipeline optimiser_base_disparus est appelé lors du nettoyage en base des objets à la poubelles et des liens morts qui en résultent

SPIP 3 dispose également d'une gestion de file de tâches qui permet de programmer l'exécution future ou simplement asynchone (ASAP mais sans faire attendre l'utilisateur) de fonctions.

La mise en place de configuration des plugins est simplifiée par la prise en charge automatisée des formulaires #FORMULAIRE_CONFIGURER_XXX et par l'utilisation des fonctions lire_config, ecrire_config, effacer_config (voir Configurer une fonctionnalité de votre site, ou un plugin).

Les formulaires CVT permettent facilement de faire des formulaires en plusieurs pages, et supportent également la sauvegarde automatique de la saisie par simple déclaration.
Un pipeline formulaire_fond permet de personnaliser le fond des formulaires (pour modifier le HTML du formulaire) [14]

Dans l'API SQL :

la fonction sql_skip est ajoutée et permet de sauter un certain nombre de résultats.
Les valeurs null dans sql_updateq et sql_insertq sont traduites en NULL SQL et ne sont plus assimilées à une chaîne vide.
les fonctions sql_demarrer_transaction et sql_terminer_transaction permettent respectivement comme leur nom le suggère de démarrer ou de clôturer une transaction SQL [15].

Introduction d'un point d'entrée bac-à-sable, (public/sandbox.php) pour la compilation des squelettes, permet à un plugin de gérer la compilation des squelettes dans un ensemble de filtres et fonctions en liste blanche ou liste noire, et d'interdire le PHP dans les squelettes.

Spécialisation des critères :
Il est possible de préfixer par le nom du serveur et/ou le nom de la table le nom de la fonction critère. La recherche se fait dans l'ordre :

critere_serveur_TABLE_moncritere_dist,
critere_serveur_TABLE_moncritere,
critere_serveur_moncritere_dist,
critere_serveur_moncritere,
critere_TABLE_moncritere_dist,
critere_TABLE_moncritere,
critere_moncritere_dist,
critere_moncritere

Dans le fichier options.php d'un plugin ou dans le fichier mes_options.php, $GLOBALS['marqueur_skel'] .= ":prefixe" permet de différencier le cache des squelettes compilés comme $GLOBALS['marqueur'] .= ":prefixe" permettait déjà de différencier le cache des squelettes.

[1] Outre le Porte-plume déjà intégré dans SPIP 2 et qui initiait ce mouvement, on peut citer notamment les plugins Afficher_objets, Base CSS, Navigation du privé, CVT multi-étapes, Forum, Job-queue, Mediabox, Médiathèque, TextWheel, URLs éditables, Comments, qui ont, pour certains, inspiré fortement le développement de SPIP lui-même ; pour d'autres été intégrés, avec quelquefois certaines évolutions.

[2] Ce chantier avait été amorcé depuis quelque temps sur la Zone, et celles et ceux qui d'entre vous utilisaient déjà le plugin Navigation du privé ou la médiathèque retrouveront vite leurs marques.

[3] Par exemple, le passage en édition sur un article devient instantané grâce au pré-chargement Ajax.

[4] http://core.spip.org/projects/spip/repository/revisions/17650

[5] en SPIP 2.1 ils étaient placés dans le dossier extensions/ désormais inutile.

[6] Voir le pipeline associé sur programmer.spip.org

[7] C'est une alternative aux plugin Thickbox, LightBox... qui repose sur la librairie Colorbox

[8] Connu pour SPIP 2 sous le nom "Médiathèque"

[9] en revanche le support de PostGreSQL doit être considéré comme expérimental et incomplet pour un usage en production

[10] Par exemple, pour l'envoi d'un mail "dès que possible" qui permet de rendre la main à l'utilisateur immédiatement sans devoir attendre que le mail soit effectivement envoyé

[11] dans tous les navigateurs modernes à l'exception de Internet Explorer qui ne la supporte pas encore

[12] Voir Utiliser les modèles

[13] La balise n'est plus utilisée en HTML5.

[14] http://core.spip.org/projects/spip/repository/revisions/18754

[15] Est ajouté de manière expérimentale également sql_preferer_transaction présent plutôt pour contourner un problème de lenteur sur des insertions multiples avec SQLite, qui sont exécutées plus rapidement en mode transactionnel. Cette fonction renvoie true uniquement en SQLite

API de gestion de la file des travaux [ redirection ]

cerdic — 2012-05-19T09:50:41Z

SPIP intègre nativement une interface de programmation (ou API) de gestion de file de travaux (« job queue »). Elle permet de programmer des tâches à exécuter dans le futur, ou simplement le plus tôt possible mais sans faire attendre l'utilisateur.

Sommaire
Ajouter un travail dans la file
Supprimer un travail de la file
Associer un travail à un objet éditorial
Les travaux programmés sont à tout moment visualisables dans l'espace d'administration via le menu Maintenance > Liste des travaux. La page de suivi permet de forcer l'exécution immédiate d'une tâche, ou de supprimer certaines tâches.

Ajouter un travail dans la file
$id_job = job_queue_add($function, $description, $arguments = array(), $file = '', $no_duplicate = FALSE, $time=0, $priority=0)

Avec les arguments :

$function : le nom de la fonction PHP qui doit être appelée
$description : une description humainement compréhensible de ce que fait la tâche (essentiellement pour l'affichage dans la page de suivi de l'espace privé)
$arguments (facultatif, vide par défaut) : les arguments qui seront passés à la fonction, sous forme de tableau PHP
$file (facultatif, vide par défaut) : nom du fichier à inclure, via include_spip($file) (exemple : 'inc/mail' : il ne faut pas indiquer .php). Si le nom finit par un / alors on considère que c'est un répertoire et SPIP fera un charger_fonction($function,$file)
$no_duplicate (facultatif, false par défaut)
si vaut true la tâche ne sera pas ajoutée si elle existe déjà en file d'attente avec la même fonction et les mêmes arguments.
si vaut 'function_only' la tâche ne sera pas ajoutée si elle existe déjà en file d'attente avec la même fonction indépendamment de ses arguments
$time (facultatif, 0 par défaut) indique la date sous forme de timestamp à laquelle la tâche doit être programmée. Si 0 ou une date passée, la tâche sera exécutée aussitôt que possible (en général en fin hit, en asynchrone).
$priority (facultatif, 0 par défaut) indique un niveau de priorité entre -10 et +10. Les tâches sont exécutées par ordre de priorité décroissante, une fois leur date d'exécution passée. La priorité est surtout utilisée quand une tâche cron indique qu'elle n'a pas fini et doit être relancée : dans ce cas SPIP réduit sa priorité pour être sûr que celle tâche ne monopolise pas la file d'attente.

La fonction renvoie le numéro de travail ajouté ou 0 si aucun travail n'a été ajouté.

Supprimer un travail de la file

job_queue_remove($id_job)

$id_job est le numéro du travail en attente, tel que retourné par la fonction job_queue_add

La fonction retourne true si le travail a bien été trouvé et supprimé, false sinon.

Associer un travail à un objet éditorial

job_queue_link($id_job,$objets)

Avec les arguments :

$id_job : le numéro de travail en attente, tel que retourné par la fonction job_queue_add
$objets une liste d'objets sous la forme d'un tableau d'objets array(array('objet'=>'article','id_objet'=>23),...)

Lorsque des travaux sont associés à un objet, ils apparaissent sur la page de l'espace privé de cet objet, et les auteurs qui ont le droit de modifier l'objet peuvent aussi supprimer le travail avant son exécution.

API « editer_objet » [ redirection ]

cerdic — 2012-05-19T09:49:54Z

L'ajout, la modification et la publication des instances d'objets éditoriaux sont simplifiés par une interface de programmation (ou API) constituée de 3 fonctions génériques qui peuvent servir pour manipuler tous les objets de SPIP.
- Guide des fonctions avancées / SPIP 3.0, Archive

API « autoriser » [ redirection ]

cerdic — 2012-05-19T09:49:00Z

L'interface de programmation (API) « autoriser » introduite dans SPIP 2.0 permet de gérer finement les autorisations données à un auteur d'effectuer une action sur un objet.

Sommaire
Vérifier une autorisation
Donner une autorisation exceptionnelle
Déclarer une nouvelle autorisation
Aide au développement
Vérifier une autorisation

La vérification d'une autorisation se fait par un appel de la forme :

include_spip('inc/autoriser'); if (autoriser('modifier', 'article', $id_article)) { ... }

La fonction autoriser($faire, $type, $id, $qui, $opt) accepte 5 arguments dont seul le premier est obligatoire :

$faire est une chaîne qui désigne l'action soumise à autorisation. C'est en règle générale un verbe simple (modifier, creer, supprimer, voir, configurer...), parfois associé à un contexte (les mots sont alors collés : changerlangue, publierdans...).
Il y a quelques exceptions où le $faire n'est pas un verbe et s'utilise sans aucun autre argument (autoriser('webmestre') par exemple, ou autoriser('ecrire') —qui désigne ici l'espace d'administration et non l'action—).
$type est une chaîne qui désigne sur quoi porte l'action. C'est en général le type d'un objet éditorial (article, rubrique, mot, groupe-mots, ...).
$id désigne l'id (la clé primaire) de l'objet sur lequel porte l'action. $id est en général un nombre entier, mais peut être une chaîne si cela correspond à la clé primaire de la table SQL concernée.
$qui désigne l'auteur (au sens SPIP) qui va faire l'action. Si il n'est pas fourni (ou null dans l'appel de la fonction autoriser, c'est implicitement l'auteur connecté qui est pris en compte. Sinon $qui peut être l'id_auteur d'un auteur dont on veut vérifier les droits, ou un tableau associatif qui décrit l'auteur (tableau qui contient alors les champs de la table spip_auteurs pour l'auteur concerné)
$opt est un tableau associatif de données supplémentaires contextuelles concernant l'action qui sont parfois utilisées par l'autorisation. Par exemple lorsqu'on veut modifier/publier un article, on appellera autoriser('instituer', 'article', $id_article, null, array('statut' => 'publie'))

La fonction autoriser retourne « true » ou « false » en fonction des droits de l'auteur à faire l'action demandée.

Dans un squelette, la vérification d'une autorisation se fait par la balise #AUTORISER.

Donner une autorisation exceptionnelle

Il arrive qu'on ait besoin de faire une action qui sera soumise à autorisation pour un auteur qui normalement n'en a pas le droit. Cela peut se produire, par exemple, dans le cas d'une action programmée qui sera alors exécutée anonymement.

Dans ce cas, il existe un mécanisme via la fonction autoriser_exception qui donne une autorisation exceptionnelle, le temps de réaliser l'action concernée.

include_spip('inc/autoriser'); // donner une autorisation exceptionnelle temporaire autoriser_exception('modifier', 'article', $id_article); // réaliser l'action désirée include_spip('action/editer_objet'); objet_modifier('article', $id_article, array('titre' => 'Nouveau titre')); // retirer l'autorisation exceptionnelle autoriser_exception('modifier', 'article', $id_article, false);

La fonction autoriser_exception($faire, $type, $id, $autoriser) prend 4 arguments :

$faire avec la même signification que pour autoriser()
$type avec la même signification que pour autoriser()
$id avec la même signification que pour autoriser()
$autoriser qui est un booléen et indique si l'autorisation exceptionnelle est accordée ou non :
Lorsque $autoriser vaut « true » ou n'est pas fourni, on accorde une autorisation exceptionnelle : tous les appels suivant à autoriser() avec les mêmes arguments $faire, $type et $id renverront true
Lorsque $autoriser vaut « false » cela signifie que l'autorisation revient sous le régime normal et sera vérifiée selon la règle en vigueur (elle peut donc être encore autorisée ou effectivement interdite). Le false n'indique donc pas ici qu'on interdit l'action, mais simplement qu'il n'y a plus d'exception.

Depuis SPIP 4.0 autoriser_exception accepte un argument * en guise d'id :

quand on autorise une exception avec *, cela l'autorise pour tout id
quand on annule une exception avec *, cela annule toutes les exceptions pour cet objet, même celles qui auraient été posées individuellement avec des ids
Déclarer une nouvelle autorisation

Lorsque la fonction générique autoriser() est appelée, elle cherche une fonction nommée à laquelle déléguer la vérification.

Si aucun $type n'est fourni dans l'appel à autoriser(), la recherche de la fonction se fait dans l'ordre suivant :

autoriser_$faire
autoriser_$faire_dist
autoriser_defaut
autoriser_defaut_dist

Si un $type est fourni dans l'appel à autoriser(), la recherche se fait dans l'ordre suivant :

autoriser_$type_$faire
autoriser_$type_$faire_dist
autoriser_$type
autoriser_$type_dist
autoriser_$faire
autoriser_$faire_dist
autoriser_defaut
autoriser_defaut_dist

Dans les deux cas, la recherche va du plus précis vers le plus général. Cela permet de définir des familles d'autorisation avec une règle générale (pour une action par exemple), que l'on précise ensuite pour certains objets qui suivent une règle différente.

Pour définir une autorisation, il suffit donc de créer une fonction avec l'un des noms de la liste ci-dessus. La fonction recevra en arguments ceux envoyés à la fonction autoriser() et doit renvoyer « true » ou « false ».

On peut définir une autorisation générique. Lorsque c'est une autorisation qui n'est pas encore définie, on la suffixe en général par un _dist qui permet toujours à un webmestre de la surcharger dans son fichier mes_options.php (en déclarant la fonction de même nom, mais sans son suffixe _dist).

Attention : on voit que dans le nom de la fonction, l'ordre de $faire et $type est inversé par rapport à celui de l'appel à autoriser().

À noter également qu'à partir de SPIP 3.0 le $type est présumé correspondre à un objet, et est normalisé lors de l'appel : vérification qu'il correspond bien à un type d'objet et sinon suppression du « s » final. Cela permet d'assurer qu'on appellera bien la bonne fonction d'autorisation même si on utilise un synonyme du $type (syndic au lieu de site par exemple, ou groupes_mot au lieu de groupe_mots qui est une exception de nommage).
Il est cependant possible d'échapper à cette normalisation en préfixant le $type par un '_' (underscore) dans l'appel à autoriser(), lorsque cet argument est le nom d'une page de ecrire.

Dans tous les cas, tous les autres caractères '_' sont retirés du $type

Ainsi un appel à autoriser('modifier', 'groupes_mots', $id_groupe) délèguera à la fonction autoriser_groupemots_modifier() (ou l'une des variantes selon la règle ci-dessus si cette fonction précise n'existe pas).
Dans les versions antérieures à SPIP 3.0 il convient de toujours faire très attention à bien utiliser le nom de l'objet sans erreur, car sinon l'autorisation par défaut sera appelée ce qui peut conduire à une erreur d'autorisation plus ou moins grave selon le cas.

Exemple de fonction d'autorisation :

/** * Autoriser a creer un article : * Il faut qu'une rubrique existe et qu'on ait le statut necessaire pour creer * * @return bool */ function autoriser_article_creer_dist($faire, $type, $id, $qui, $opt) { return (sql_countsel('spip_rubriques')>0 AND in_array($qui['statut'], array('0minirezo', '1comite'))); }

Aide au développement

Lors du développement d'un plugin, il peut être utile de comprendre comment sont appelées les autorisations et dans quel ordre d'enchaînement.

Pour cela il suffit d'ajouter la ligne suivante dans le fichier mes_options.php :

define('_DEBUG_AUTORISER', true);

Chaque appel à autoriser() sera alors tracé dans le fichier spip.log avec le nom de la fonction appelée et le résultat qu'elle a retourné.

Formulaire CVT avec sauvegarde automatique

cerdic — 2012-05-19T09:31:05Z

Sommaire
Activer la fonction
Ou sont sauvegardées les données ?
De la vie privée ...
Pour éviter que les utilisateurs ne perdent le bénéfice de leur saisie en cas de perte de connexion ou de fausse manipulation, il est possible d'activer une fonction de sauvegarde automatisée dans les formulaires CVT.

Activer la fonction

Pour activer la prise en charge, il suffit que la fonction charger() du formulaire renvoie un identifiant unique qui désigne le formulaire.

Il y aura une sauvegarde différente par identifiant unique (et par formulaire), celui-ci doit donc dépendre du contexte de la saisie. Par exemple sur un formulaire de forum en réponse à un article on choisira de passer comme identifiant l'id_article de l'article auquel on répond.

Cet identifiant peut être un entier, une chaine ou un tableau, et doit être envoyé dans le champ '_autosave_id' :

function formulaires_repondre_article_charger_dist($id_article){ ... return array( ..., '_autosave_id' => $id_article ); }
Ou sont sauvegardées les données ?

Lorsqu'on active cette fonction, le formulaire va envoyer à chaque modification de saisie une requête à SPIP avec la liste de tous les champs saisis. SPIP va alors stocker cette information dans la session de l'utilisateur, sur le serveur.

Lorsque la saisie est complète et que l'utilisateur valide le formulaire, SPIP va alors vider cette sauvegarde (lors du traitement du formulaire).

Mais si l'utilisateur rencontre une erreur ou un problème et oublie de valider le formulaire, la sauvegarde est conservée 72H. Si l'utilisateur revient sur le même formulaire, il va retrouver le formulaire pré-rempli avec toutes les informations qu'il avait saisi auparavant.

De la vie privée ...

Attention cependant à ne pas utiliser cette sauvegarde automatique dans un formulaire qui collecte des données personnelles dans une session anonyme.

Si l'utilisateur est sur un poste de consultation public et ne valide pas, ses données seront alors disponibles pour quiconque revient sur la même page avec son poste de consultation.

Par ailleurs, il est possible de personnaliser la durée de 72H de conservation des données saisies en précisant dans le fichier mes_options.php par exemple (pour une durée de 24h) :

define('_AUTOSAVE_GB_DELAY',24*3600)

{tri} et #TRI dans les boucles

cerdic — 2012-05-19T09:31:01Z

SPIP dispose d'un critère et d'une balise qui permettent de faire facilement des listes triables.

Le critère {tri} simplifie la réalisation de listes triables de la même façon que le critère {pagination} simplifie la réalisation de listes paginées.

Dans une boucle simple, il permet de définir le critère de tri en lui indiquant en argument le champ à utiliser par défaut :

Jusque là rien de nouveau par rapport au critère {par}. Mais {tri} peut être associé à la balise #TRI qui permet de générer un lien pour changer le critère de tri. La balise #TRI prend en premier argument le champ de tri, et en second argument le libellé du lien cliquable pour utiliser ce champ pour le tri :

#TRI{titre,'Trier par titre'} | #TRI{date,'Trier par date'} | #TRI{date_redac,'Trier par date de rédaction'}

Ce faisant l'internaute se voit proposer un menu pour modifier le tri de la boucle. Le tri actuellement utilisé est exposé en gras. Un clic active les tris non utilisés. Depuis SPIP 4.2, un clic inverse un tri actif.

Si la boucle est dans une inclusion ajax, il suffit de renseigner la classe ajax en troisième argument de la balise #TRI pour que les liens se comportent avec un rechargement partiel de la page :

#TRI{titre,'Trier par titre',ajax} | #TRI{date,'Trier par date',ajax} | #TRI{date_redac,'Trier par date de rédaction',ajax}

Le critère {tri} permet également d'indiquer le sens du tri par défaut en second argument. Il faut indiquer la valeur direct ou 1 pour indiquer un tri croissant par défaut, et inverse ou -1 pour un tri décroissant par défaut :

#TRI{titre,'Trier par titre'} | #TRI{date,'Trier par date'} | #TRI{date_redac,'Trier par date de rédaction'}

Par ailleurs il est aussi possible de proposer le choix du sens de tri. Cela se fait en passant > pour un tri croissant et < pour un tri décroissant en premier argument de la balise #TRI :

#TRI{>,'Tri croissant',ajax} | #TRI{<,'Tri décroissant',ajax} | #TRI{titre,'Trier par titre',ajax} | #TRI{date,'Trier par date',ajax} | #TRI{date_redac,'Trier par date de rédaction',ajax}

Cela dit, plutôt que de proposer des boutons de tri systématique, une alternative est possible : adapter automatiquement le sens du tri à la colonne utilisée pour le tri. Cela se fait en passant en second argument de la balise tri un tableau avec le sens par défaut pour chaque colonne :

#SET{defaut_tri,#ARRAY{ titre,1, date,-1, date_redac,-1 }} #TRI{titre,'Trier par titre',ajax} | #TRI{date,'Trier par date',ajax} | #TRI{date_redac,'Trier par date de rédaction',ajax}

Ainsi quand l'internaute choisira le tri par titre, celui-ci sera dans un ordre croissant. Mais quand il choisira la date ou la date de rédaction, le tri se fera dans un ordre décroissant.

Un troisième argument commençant par session permet d'indiquer de stocker l'ordre de tri dans la session de l'internaute. Celle-ci ou celui-ci pourra dès lors retrouver son tri favori lors de son retour sur la page.

#SET{defaut_tri,#ARRAY{ titre,1, date,-1, date_redac,-1 }} #TRI{titre,'Trier par titre',ajax} | #TRI{date,'Trier par date',ajax} | #TRI{date_redac,'Trier par date de rédaction',ajax}

Multilinguisme

La balise tri peut trier selon un champ même lorsque celui ci contient des chaînes multilingues (exemple : [fr]Irak [en]Iraq).

Il suffit pour cela de préfixer le nom du champ par 'multi' dans l'appel de la balise #TRI.

Exemple : #TRI{multi titre,'Titre', ajax}

API de gestion des liaisons [ redirection ]

cerdic — 2012-05-19T09:30:48Z

SPIP 3 introduit une gestion générique des tables de liens d'un objet avec n'importe quel autre objet.

Sommaire
Table de lien
API
objet_associable
objet_associer
objet_dissocier
objet_qualifier_liens
objet_trouver_liens
objet_optimiser_liens
objet_dupliquer_liens
Interface d'édition
Table de lien

Les liens sont structurellement non symétriques : il partent d'un objet source pour aller vers n'importe quel objet destination.

Pour être associable en tant que source, un objet bidibule stocké dans une table spip_bidibules doit posséder une table spip_bidibules_liens qui possèdera un champ id_bidibule (même nom que la clé primaire de spip_bidibules) et deux champs id_objet et objet.
La table peut aussi comporter d'autres champs pour qualifier les liens.

API

L'API permet de gérer simplement les liens sans manipuler directement des requêtes SQL, et en offrant systématiquement des points d'entrée aux plugins qui peuvent ainsi savoir quand un lien est ajouté, supprimé, ou modifié et agir en conséquence.

Pour utiliser l'API il faut inclure action/editer_liens.php :

include_spip('action/editer_liens');
objet_associable

objet_associable($objet) teste si un objet peut être associé à d'autres via sa table de liens.

Si l'objet n'est pas associable (il n'a pas de table de liens dédiée), la fonction renvoie false.

Si l'objet est associable, la fonction renvoie un tableau composé du nom de la clé primaire (commune à la table de liens et à la table de l'objet), et le nom de la table de liens.

Par exemple (et par défaut dans SPIP) les auteurs, les documents, les mots sont des objets associables car ils disposent tous d'une table spip_xxx_liens.

Par contre, les articles ne sont pas associables car ils ne disposent pas de table spip_articles_liens. Cela signifie qu'on ne peut pas créer de liens partant des articles vers un autre objet quelconque. En revanche on peut créer un lien depuis un mot, un auteur ou un document vers un article.

objet_associer

objet_associer($objets_source, $objets_lies[,$qualif]) permet d'associer les $objets_lies aux $objets_source via leurs table de lien propres.

$objets_source
Les $objets_source doivent être tous associables au sens de la fonction objet_associable(). Les objets sources sont donc les pivots sur lesquels portent les liens.

Le format de $objets_source est commun a toutes les fonctions de manipulation de liens.
C'est un tableau dont

chaque clé correspond au nom de l'objet à associer
chaque valeur décrit le ou les id pour chaque objet. Les valeurs peuvent être :
le joker "*" qui désigne "tous les id déja dans la table de lien" (il a donc peu d'intérêt dans le cas de l'ajout de liens comme ici)
une valeur scalaire autre désigne un id précis
un tableau désigne une liste d'id (un tableau ne peut pas contenir le joker "*")
un tableau de deux éléments commençant par la valeur 'NOT' désigne une condition exclusive : tous les id déjà dans la table de lien sauf ceux décrits dans la seconde valeur (qui peut être à son tour un scalaire ou un tableau)

$objets_lies
Le format de $objets_lies est commun a toutes les fonctions de manipulation de liens.
C'est un tableau dont

chaque clé correspond au nom de l'objet à associer. La valeur joker "*" désigne "tous les objets présents dans la table de lien" (peu d'intérêt dans le cas d'ajout de lien donc)
chaque valeur décrit le ou les id pour chaque objet. Les valeurs peuvent être :
le joker "*" qui désigne "tous les id déja dans la table de lien" (il a donc peu d'intérêt dans le cas de l'ajout de liens comme ici)
une valeur scalaire autre désigne un id précis
un tableau désigne une liste d'id (un tableau ne peut pas contenir le joker "*")
un tableau de deux éléments commençant par la valeur 'NOT' désigne une condition exclusive : tous les id déjà dans la table de lien sauf ceux décrits dans la seconde valeur (qui peut être à son tour un scalaire ou un tableau)

$qualif
La fonction objet_associer peut prendre un troisième argument facultatif $qualif qui est un tableau associatif champ=>valeur avec lequel seront modifiés les liens ajoutés. Cela peut être utile si la table de lien dispose de champs supplémentaires qui décrivent les liens.

Si plusieurs liens sont créés en même temps, ils se voient appliquer tous les mêmes valeurs décrites dans $qualif

exemples
Les exemples ci-dessous sont valides :

objet_associer(array("auteur"=>3), array("article"=>5)); objet_associer(array("auteur"=>3), array("article"=>array(5,6))); objet_associer(array("auteur"=>array(3,4)), array("article"=>5)); objet_associer(array("auteur"=>array(3,4)), array("article"=>array(5,6))); objet_associer(array("document"=>3), array("article"=>5), array('vu'=>'oui'));

La fonction renvoie le nombre de liens effectivement créés (certains liens pouvant déjà exister au moment de la tentative d'ajout, qui ne sont alors pas comptés).

objet_dissocier

objet_dissocier($objets_source,$objets_lies) permet de supprimer les liens entre les $objets_source et $objets_lies.

$objets_source
voir le format identique à celui décrit dans objet_associer

$objets_lies
voir le format identique à celui décrit dans objet_associer

exemples
Les exemples ci-dessous sont valides :

objet_dissocier(array("auteur"=>3), array("article"=>5)); /* Exemple pour associer un auteur à une liste d'article et uniquement à ceux là */ objet_associer(array("auteur"=>3), array("article"=>array(5,6))); objet_dissocier(array("auteur"=>3), array("article"=>array('NOT', array(5,6))));

La fonction renvoie le nombre de liens effectivement supprimés.

objet_qualifier_liens

objet_qualifier_liens($objets_source,$objets_lies,$qualif) permet de modifier les valeurs des champs décrits dans $qualif sur les liens entre $objets_source et $objets_lies

$objets_source
voir le format identique à celui décrit dans objet_associer

$objets_lies
voir le format identique à celui décrit dans objet_associer

$qualif
voir le format identique à celui décrit dans objet_associer

exemples
Les exemples ci-dessous sont valides :

objet_qualifier(array("document"=>3), array("article"=>5), array('vu'=>'oui'));

La fonction renvoie le nombre de mise à jour en base ou false en cas d'échec.

objet_trouver_liens

objet_trouver_liens($objets_source,$objets_lies) permet de retrouver tous les liens de $objets_source vers $objets_lies.

$objets_source
voir le format identique à celui décrit dans objet_associer

$objets_lies
voir le format identique à celui décrit dans objet_associer

La fonction renvoie un tableau constitué d'un tableau associatif pour chaque lien trouvé. Ce dernier contient l'ensemble des champs du lien, auquel sont ajoutés une entrée objet=>id pour la source et la destination du lien, pour simplifier le traitement au retour (évite d'avoir à connaitre les clés primaires par exemple).

objet_optimiser_liens

objet_optimiser_liens($objets_source,$objets_lies) nettoie les liens restant entre $objets_source et $objets_lies lorsque l'un des deux n'existe plus (suppression en base de données).

Cette fonction est classiquement utilisée dans des fonctions crons de nettoyage de la base de données.

$objets_source
voir le format identique à celui décrit dans objet_associer

$objets_lies
voir le format identique à celui décrit dans objet_associer

La fonction renvoie le nombre de liens obsolètes nettoyés

objet_dupliquer_liens

objet_dupliquer_liens($objet,$id_source,$id_cible) va dupliquer tous les liens de l'$objet $id_source sur l'$objet $id_cible.

Pour cela, toutes les tables de liens de tous les objets connus seront parcourues pour trouver les liens depuis et vers l'$objet $id_source.

Chaque lien trouvé sera dupliqué en substituant $id_cible à $id_source

La fonction retourne le nombre de liens dupliqués.

Interface d'édition

Une interface générique #FORMULAIRE_EDITER_LIENS utilisable dans les squelettes permet l'édition des liens. #FORMULAIRE_EDITER_LIENS{auteurs,article,23} installera le formulaire pour associer/dissocier des auteurs de l'article N°23.

Les liens sont portés par la table lien du premier objet passé en argument du formulaire (auteurs dans l'exemple ci-dessus).

On peut utiliser ce formulaire de plusieurs façons :

#FORMULAIRE_EDITER_LIENS{auteurs,article,23} pour associer des auteurs à l'article N°23, sur la table pivot spip_auteurs_liens
#FORMULAIRE_EDITER_LIENS{auteur,12,articles} pour associer des articles à l'auteur N°12, sur la table pivot spip_auteurs_liens
#FORMULAIRE_EDITER_LIENS{mot,15,auteurs} pour associer des auteurs au mot N°15, sur la table pivot spip_mots_liens
#FORMULAIRE_EDITER_LIENS{auteurs,mot,15} pour associer des auteurs au mot N°15, sur la table pivot spip_auteurs_liens

On peut donc, par la syntaxe d'appel, définir quels objets sont associé entre eux, ainsi que la table qui supporte les liens.

Remarque : il est possible de filtrer la liste des objets présentés selon la valeur de certains de leurs champs en passant celles-ci en 4ème argument dans un tableau associatif champ=>valeur :

#FORMULAIRE_EDITER_LIENS{auteurs,article,23,#ARRAY{statut,6forum}}

Ne proposera que les auteurs dont le statut est 6forum.

Pour fonctionner, ce formulaire nécessite 2 squelettes correspondant au type d'objet associé. Par exemple pour pouvoir associer ou dissocier des auteurs de n'importe quel autre objet, les squelettes prive/objets/liste/auteurs_lies.html et prive/objets/liste/auteurs_associer.html sont nécessaires au fonctionnement du formulaire. Ils présentent la liste des objets déjà associés ainsi que la sélection des objets à associer. SPIP inclue nativement les vues nécessaires pour les auteurs, les rubriques, ainsi que les mots via le plugin mots. Des plugins peuvent rendre cette interface disponible pour de nouveaux objets éditoriaux par la définition de ces deux squelettes.

API de déclaration d'objets éditoriaux [ redirection ]

cerdic, _Eric_ — 2012-05-19T09:30:18Z

La création de nouveaux objets éditoriaux est simplifiée par une interface de programmation (ou API) déclarative [1] qui permet à SPIP de construire de façon automatisée une grande partie de l'interface d'édition de ces objets.

Article déplacé : Voir https://programmer.spip.net/1018

[1] qui regroupe notamment en une seule, plusieurs déclarations existantes auparavant

La fonction verifier() des formulaires CVT

cerdic, xdjuj — 2010-04-06T09:34:27Z

Sommaire
Comment définir la fonction
Les arguments de la fonction
Que doit faire la fonction
Champs particuliers
Personnalisation
Comment définir la fonction

La fonction verifier() d'un formulaire XXX (qui sera affiché dans les squelettes par #FORMULAIRE_XXX) est définie dans le fichier formulaires/xxx.php ou dans le fichier formulaires/xxx/verifier.php. Le dossier formulaires/ pouvant être rangé dans le dossier d'un plugin, ou dans le dossier squelettes.

Cette fonction devra être nommée
function formulaires_xxx_verifier_dist(). Le suffixe _dist permettant lors du développement de surcharger la fonction pour changer son comportement, en créant une fonction function formulaires_xxx_verifier()

Les arguments de la fonction

La fonction verifier() reçoit automatiquement la valeur de chaque argument qui sont passés à la balise #FORMULAIRE_XX, dans le même ordre.
Par exemple en écrivant

#FORMULAIRE_XX{#ID_ARTICLE,#ID_RUBRIQUE}

et la fonction

formulaires_xxx_verifier_dist($arg1,$arg2){ ... }

$arg1 vaudra #ID_ARTICLE, et $arg2 vaudra #ID_RUBRIQUE.

Que doit faire la fonction

La fonction verifier() doit renvoyer un tableau d'erreurs de saisies résultant de la vérification des données saisies.

Si toute la saisie est correcte, le tableau sera vide, et SPIP appellera alors la fonction traiter() du formulaire, chargée de finir le travail.

Si le tableau renvoyé par la fonction verifier() n'est pas vide, alors la fonction traiter() ne sera pas appelée, le formulaire sera de nouveau affiché avec les messages d'erreur éventuels pour correction par l'utilisateur.

Il convient donc de faire toutes les vérifications nécessaires au traitement dans la fonction verifier() pour assurer la meilleure interactivité possible.

Chaque erreur est renvoyée sous forme d'une association cle=>valeur, et il est d'usage d'utiliser comme clé le nom de la variable saisie dans le formulaire.

Exemple de fonction verifier()
Voyons un exemple

function formulaires_xxx_verifier_dist() { $erreurs = array(); if (!_request('nom')) { $erreurs['nom'] = _T('info_obligatoire'); } include_spip('inc/filtres'); if ($email = _request('email') AND !email_valide($email)) { $erreurs['email'] = _T('form_email_non_valide'); } return $erreurs; }

Ici, la fonction

vérifie que le nom a bien été renseigné, et produit un message d'erreur dans le cas contraire ;
regarde si une adresse mail a été saisie, et dans ce cas vérifie sa validité, avec un message d'erreur si l'adresse mail est incorrecte.
Champs particuliers

La fonction verifier() peut renvoyer certaines valeurs particulières dans le tableau :

message_erreur
Cette valeur est utilisée dans le squelette du formulaire pour afficher un message d'erreur général, qui concerne tout le formulaire. Il peut être judicieux de renseigner ce message dès qu'une erreur sur un champ a été identifiée

message_ok
Cette valeur permet de renvoyer un message de succès. Ce message peut-être utile quand par exemple l'internaute a entré une première valeur qui permet de vérifier certaines informations, sans que la saisie du formulaire ne soit finie pour autant.
La présence de ce message empêche l'appel à la fonction traiter() du formulaire, qui n'est appelée que si, et seulement si, le tableau retourné par verifier() est vide.

Personnalisation

Comme la fonction charger(), la fonction verifier() d'un formulaire existant peut être personnalisée par deux mécanismes

Surcharge
Comme indiqué ci-dessus, il est possible de redéfinir la fonction verifier() par défaut en définissant sa propre fonction
function formulaires_xxx_verifier()
qui sera appelée à la place de la fonction par défaut qui comporte le suffixe _dist.
Cette fonction surchargée pourra être définie dans le fichier formulaires/xxx/verifier.php, ou dans un fichier options.php appelé à chaque hit de façon à ce que la fonction soit définie au moment où SPIP va la chercher.

Pipeline
Le pipeline formulaire_verifier permet de modifier le résultat de la fonction verifier() par défaut de n'importe quel formulaire CVT.

C'est la méthode qu'il faut privilégier dans un plugin.

Le pipeline reçoit en argument un tableau de cette forme :

array( 'args'=>array('form'=>$form,'args'=>$args), 'data'=>$erreurs )

En écrivant la fonction pipeline sous cette forme

function monplugin_formulaire_verifier($flux) { ... }

Alors vous trouverez dans $flux les éléments suivants :

$flux['args']['form'] nom du formulaire (xxx dans notre exemple)

$flux['args']['args'] arguments de la fonction charger() dans l'ordre où ils ont été passés à la balise #FORMULAIRE_XXX

$flux['data'] tableau $erreurs renvoyé par la fonction verifier() par défaut

Tous les formulaires passent par le même pipeline. Il faut donc tester la valeur de $flux['args']['form'] pour ne modifier que le comportement du formulaire xxx.

voir aussi les fonctions charger() et traiter()

La fonction traiter() des formulaires CVT

cerdic — 2010-04-06T09:34:14Z

Sommaire
Comment définir la fonction
Les arguments de la fonction
Que doit faire la fonction
Exemple de fonction traiter()
Cas particuliers
Personnalisation
Voir aussi
Comment définir la fonction

La fonction traiter() d'un formulaire XXX (qui sera affiché dans les squelettes par #FORMULAIRE_XXX) est définie dans le fichier formulaires/xxx.php ou dans le fichier formulaires/xxx/traiter.php. Le dossier formulaires/ pouvant être placé dans le dossier d'un plugin, ou dans le dossier squelettes.

La fonction devra être nommée
function formulaires_xxx_traiter_dist(). Le suffixe _dist permettant lors du développement de redéfinir la fonction pour changer son comportement, en créant une fonction function formulaires_xxx_traiter()

Les arguments de la fonction

Comme les fonctions charger() et verifier(), la fonction traiter() reçoit automatiquement, dans le même ordre, la valeur de chacun des arguments passés à la balise #FORMULAIRE_XX.
Par exemple en écrivant

#FORMULAIRE_XX{#ID_ARTICLE,#ID_RUBRIQUE}

et la fonction

formulaires_xxx_traiter_dist($arg1,$arg2) { ... }

$arg1 vaudra #ID_ARTICLE, et $arg2 vaudra #ID_RUBRIQUE.

Que doit faire la fonction

La fonction traiter() fait tous les traitements nécessaires suite à la saisie de l'internaute, et après les vérifications faites par la fonction verifier().

Le point important ici est que la fonction traiter() sera toujours appelée juste après la fonction verifier() et uniquement si celle-ci a bien renvoyé un tableau vide signifiant l'absence d'erreurs.

Une fois les actions réalisées (par exemple : enregistrement des données, écriture dans un fichier, envoi de mail ...), la fonction traiter() doit renvoyer un tableau de valeurs décrivant le résultat de l'action.

Ce tableau renvoyé par traiter() doit renseigner au moins une des deux valeurs message_ok ou message_erreur pour indiquer le succès ou l'échec éventuel du traitement.

message_ok
Si tout c'est bien déroulé, l'indiquer dans un message permet à l'utilisateur d'être rassuré sur l'action réalisée. C'est une bonne pratique de toujours renvoyer un message, même si tout se passe bien !

message_erreur
Malgré les vérifications réalisées par la fonction verifier(), le traitement peut échouer pour d'autres raisons non détectables à l'avance. Dans ce cas la fonction traiter() indique la cause de l'erreur dans message_erreur, et l'utilisateur sera informé du problème.

editable
Par défaut, après la saisie du formulaire et son traitement avec succès, la saisie du formulaire ne sera pas re-proposée, seul le message de succès ou d'erreur étant affiché.

En renvoyant une valeur true pour ce champ, cela permet de demander à l'utilisateur de remplir à nouveau le formulaire.

id_xx
Si le traitement a inséré ou modifié une (ou plusieurs) donnée en base, il est judicieux de renvoyer les clé primaires, généralement commençant par id_, des enregistrements concernés.

Ainsi, un plugin qui veut intervenir à la suite du traitement par défaut sait sur quel objet a porté l'opération, et peut agir en complément.

redirect
Il suffit d'indiquer une url dans ce champ pour rediriger l'internaute sur une autre page après la saisie.

Attention, il est important que la fonction traiter() ne fasse pas elle-même la redirection, car cela empêcherait tout intervention d'un plugin à la suite de la fonction traiter().

Exemple de fonction traiter()

Voyons un exemple

function formulaires_xxx_traiter_dist() { $res = array(); $nom = _request('nom'); $prenom = _request('prenom'); $email = _request('email'); include_spip('action/editer_auteur'); if ($id_auteur = insert_auteur()) { auteurs_set($id_auteur,array('nom'=>"$nom $prenom",'email'=>$email)); $res['message_ok'] = "Enregistrement réussi !"; $res['id_auteur'] = $id_auteur; } else { $res['message_erreur'] = "Un probleme a été rencontré, impossible d'enregistrer votre saisie"; } return $res; }

Ici, la fonction

récupère les informations saisies ;
ajoute un auteur dans la table des auteurs de SPIP ;
enregistre les nom, prénom et email saisis pour cet auteur ;
indique dans le résultat l'id_auteur ajouté, ainsi que le message de succès.

Si l'auteur ne peut être ajouté, un message d'erreur est renvoyé.

Cas particuliers

Les formulaires peuvent être facilement ajaxés en les incluant dans une classe ajax. Les fonctions charger(), verifier() et traiter() n'en savent rien, et ne voient pas de différence.

Cependant, il est parfois nécessaire que la fonction traiter() ne soit pas appelée en ajax. Par exemple parcequ'elle va modifier fortement la base de données et qu'il est préférable que toute la page soit ré-affichée après la saisie, pas seulement le formulaire.

Dans ce cas, il faut commencer la fonction traiter() par un appel à la fonction
refuser_traiter_formulaire_ajax().

Si le formulaire n'a pas été soumis en ajax, cette fonction ne fera rien, et la suite de la fonction traiter() sera exécutée normalement.

Si le formulaire a été soumis en ajax, alors cette fonction va tout arrêter en renvoyant un code spécifique au javascript de la page. Lorsque le javascript reçoit ce code, il provoque à nouveau un envoi des données du formulaire, mais sans ajax cette fois-ci. SPIP va alors de nouveau appeler la fonction verifier(), puis la fonction traiter(), qui cette fois s'exécutera complètement et pourra réaliser ses opérations.

Il est donc primordial que la fonction traiter() commence par cet appel à refuser_traiter_formulaire_ajax(), et ne fasse aucune manipulation avant d'appeler cette fonction, car sinon ces éventuelles opérations seraient exécutées deux fois.

Personnalisation

Comme les fonctions charger() et verifier(), la fonction traiter() d'un formulaire existant peut être personnalisée par deux mécanismes

Surcharge
Comme indiqué ci-dessus, il est possible de redéfinir la fonction traiter() par défaut en définissant sa propre fonction
function formulaires_xxx_traiter()
qui sera appelée à la place de la fonction par défaut qui comporte le suffixe _dist.
Cette fonction surchargée pourra être définie dans le fichier formulaires/xxx/traiter.php, ou dans un fichier options.php appelé à chaque hit de façon à ce que la fonction soit définie au moment où SPIP va la chercher.

Pipeline
Le pipeline formulaire_traiter permet de modifier le résultat de la fonction traiter() par défaut de n'importe quel formulaire CVT.

C'est la méthode qu'il faut privilégier dans un plugin.

Le pipeline reçoit en argument un tableau de cette forme :

array( 'args'=>array('form'=>$form,'args'=>$args), 'data'=>$res) )

En écrivant la fonction pipeline sous cette forme

function monplugin_formulaire_traiter($flux) { ... }

Alors vous trouverez dans $flux les éléments suivants :

$flux['args']['form'] nom du formulaire (xxx dans notre exemple)

$flux['args']['args'] arguments de la fonction charger() dans l'ordre où ils ont été passés à la balise #FORMULAIRE_XXX

$flux['args']['data'] tableau $res renvoyé par la fonction traiter() par défaut

Tous les formulaires passent par le même pipeline. Il faut donc tester la valeur de $flux['args']['form'] pour ne modifier que le comportement du formulaire xxx.

Voir aussi

Les fonctions

charger()
verifier()

Sur programmer.spip.net

le pipeline formulaire_traiter
les formulaires CVT
d'autres exemples

`$flux['args']['form']`	nom du formulaire (xxx dans notre exemple)
`$flux['args']['args']`	arguments de la fonction charger() dans l'ordre où ils ont été passés à la balise #FORMULAIRE_XXX
`$flux['data']`	tableau `$erreurs` renvoyé par la fonction verifier() par défaut