Partager des données entre plusieurs squelettes inclus (Zpip)

Question :
Dans ZPIP, la structure de base est définie à coup d’inclusion de grands blocs logiques du style

Supposons par exemple que nous soyons dans un contexte « rubrique » http///monsite.fr/spip.php?rubriqueXX et que le squelette contenu/rubrique.html se comporte de manière à afficher l’article n°yy
Comment peut-on transmettre cet id_article dans l’inclusion extra ou dans l’inclusion navigation pour, par exemple, lister les autres articles de la rubrique ? Il faut bien que le squelette appelé connaisse l’id de l’article à exclure que seul contenu/rubrique.html connait !
Pour que extra/rubrique.html ou navigation/rubrique.html puisse tenir compte de la situation, il faut disposer d’un moyen pour leur transmettre cette valeur. Or, seul le squelette appelant peut transmettre une variable...

Réponse :
L’astuce (alambiquée) pour remonter des variables d’un squelette appelé, est d’affecter le résultat sérialisé de ce squelette à une variable tableau dans le squelette appelant :
Dans structure.html :

Dans vars/rubrique.html :

Puis dans structure.html :
<INCLURE{fond=extra/#ENV{type}, myvars=#GET{myvars}, env}>

ZPIP : faire un inclure de squelette suivant une condition

dans le body de ZPIP, charger ou non un INCLURE qui contient #ENV{type}

ne fonctionne pas à cause de accolades de #ENV, donc contourner avec

Une boucle qui ne doit être exécutée que dans un certain contexte

Tout le monde le sait (beaucoup le déplorent) :

ne fonctionne pas.

En SPIP3, le critère {si ...} permet de définir la condition d’exécution depuis la boucle elle-même.
En SPIP2, il faut utiliser le plugin « bonux » et sa boucle « CONDITION ».

Il existe néanmoins un autre moyen pour arriver à nos fins...

Explications :

• en premier lieu nous définissons notre test (présence de la variable « truc » dans l’environnement) et nous affectons à une variable « test » la valeur« 0 » ou « 999999 ».
  à ce stade, #GET{test} vaut donc soit « zéro », soit « neuf cent quatre-vingt-dix-neuf mille neuf cent quatre-vingt-dix-neuf ».
• nous lançons alors la boucle dans laquelle nous demandons que l’« id_table » soit supérieur à notre valeur de test définie juste au-dessus.
  et le tour est joué...

Afficher la date du jour

Dans un squelette, afficher la date du jour (la date courante) n’est pas toujours aisé.
deux variables peuvent entrer en jeu :

• la date retournée par la boucle dans laquelle on veut afficher notre date du jour
• une variable nommée date passée en url ou par le biais d’un formulaire

Pour chaque cas, néanmoins, il existe une possibilité d’afficher la date du jour et ce sans que cette date soit tributaire du cache du squelette (ce sera toujours la date courante qui sera affichée)

Jouons avec les dates

voir aussi saisie des dates de publication et de rédaction antérieure (spip 2.0.x et 2.1.x)

-  La date du prochain jeudi qui suit #DATE :

-  Le nom du jour de l’avant-veille de #DATE :

-  La date de lundi prochain :

-  La date du dimanche d’après lundi prochain :

-  Afficher le label nouveau ! pour un article publié ou modifié il y a moins de 10 jours :

et _fil_ (sur irc) propose encore plus simple :

Exporter au format CSV

Triton nous confie un petit exemple qui marche pour MS Excel et openOffice (il y a des particularités d’encodage de caractères) :

• le http_header indique qu’il s’agit d’un document csv encodé pour MS excel
• la premiere ligne c’est les têtières (en tete de colonne) du fichier csv
• La boucle écrit ensuite le contenu ligne par ligne

Il faut, souvent, coller toutes les lignes comme ci-dessus, sinon, on peut, ou pas, se retrouver avec des lignes vides dans le csv....

Si tu colles ça dans un squelette (nommé squelette_cvs), il suffit ensuite d’appeler la page spip.php ?page=squelette_cvs et le navigateur te proposera de sauvegarder le fichier (ici inscriptions.csv - voir le filename au dessus) ou de l’ouvrir avec le logiciel de ton choix....

Après, faut voir à quoi doit servir ton cvs, à être lu directement par une appli type MS/ Open Office (cet exemple) ou à autre chose, import dans une base sql par exemple, auquel cas, il faudra peut-être modifier l’encodage de caractères...

Par ailleurs, paulbe indique qu’il faut d’abord passer les champs par le filtre textebrut avant de les passer à la moulinette de utf8_decode

on peut aussi « jolifier » et simplifier le code (surtout dans la boucle) :

l’astuce consiste à ajouter #COMPTEUR_BOUCLE; comme premier champ de #VAL (donc aussi "ordre"; en première ligne de la feuille)

Technique de BoOz

Pour mes exports excel avec des champs utf-8 et des accents j’utilise un squelette

export.xls.html

et aussi dans un fichier export.xls_fonctions.php spécial pour le squelette une fonction de conversion en utf16LE utilisée par Excel (merci Fil)

Extraire les adresses email contenues dans un(des) texte(s)

dans mes_fonctions.php :

exemple d’utilisation dans un squelette :

Une fonction pour joliment afficher les variables de #ENV, #GET ou #SESSION

Copiée sur la fonction du débugueur debusquer_contexte() (de ecrire/public/debusquer.php), cette fonction est à déposer dans le fichier mes_options.php

ne reste plus qu’à l’appeler (que l’on soit loggé ou pas) dans un squelette avec :[(#ENV|bel_env)]
ou encore :[(#GET|bel_env)]
ou encore :[(#SESSION|bel_env)]

Noter que cette fonction est incluse dans le plugin « dev »

Connaître le niveau de profondeur d’une rubrique

-  Avec SPIP3 c’est même pas drôle :

• #PROFONDEUR dans une boucle (RUBRIQUES)
• #INFO_x{objet, id_objet} en dehors d’une boucle

-  Avec SPIP2.1 deux solutions :

• <BOUCLE_niveau(HIERARCHIE) {id_rubrique} {tout}>
  </BOUCLE_niveau>
        #SET{niveau,#TOTAL_BOUCLE}
  <//B_niveau>

et on récupère l’info avec un #GET{niveau}

• une fonction à poser dans squelettes/mes_fonctions.php :
  1. function filtre_profondeur_dist($id_rubrique) {
  2.     $id_rubrique = intval($id_rubrique);
  3.     // sauver les calculs déjà faits
  4.     static $profs = array();
  5.     if (isset($profs[$id_rubrique])) {
  6.       return $profs[$id_rubrique];
  7.     }
  8.     // récupérer le parent.
  9.     $id_parent = sql_getfetsel('id_parent', 'spip_rubriques', 'id_rubrique='.$id_rubrique);
  10.     // pas de parent : id_rubrique n'existe pas
  11.     if (is_null($id_parent)) {
  12.       return '';
  13.     }
  14.     // parent zéro : on est tout en haut (racine)
  15.     if ($id_parent == '0') {
  16.       return $profs[$id_rubrique] = 1;
  17.     }
  18.     // sinon, on trouve la profondeur du parent
  19.     $parent = filtre_profondeur_dist($id_parent);
  20.     $profs[$id_rubrique] = ($parent + 1);
  21.     return $profs[$id_rubrique];
  22. }

  Télécharger

à appeler dans un squelette avec : [(#ID_RUBRIQUE|profondeur)]

Les modèles et leur contexte en SPIP3

En spip2 le contexte d’appel d’un modèle n’était pas connu lors de la compilation de ce modèle. Ainsi un modèle appelé depuis le corps du texte de l’article 18 ne pouvait savoir qu’il était appelé depuis cet article précis.

Cela a changé avec spip3 ; désormais le modèle véhicule le contexte de son objet appelant. Cela veut dire que appelé depuis l’article 18, le modèle intègre la donnée id_article = 18 ; donnée que l’on peut donc utiliser dans le modèle avec :

• soit #ID_ARTICLE,
• soit #ENV{id_article},
• soit encore #ENV{args/id_article}.

Mais plusieurs cas peuvent se présenter :

• modèle appelé depuis un article sans argument explicite :
  <mon_modele1>
  • #ID_ARTICLE vaudra la valeur id_article de l’article appelant (celui où se trouve l’appel du modèle)
  • #ENV{id_article} vaudra la valeur id_article de l’article appelant (celui où se trouve l’appel du modèle)
  • #ENV{args/id_article} vaudra ’’ (vide)
• modèle appelé depuis un article avec argument explicite vide :
  <mon_modele1|id_article>
  • #ID_ARTICLE vaudra la valeur id_article de l’article appelant (celui où se trouve l’appel du modèle)
  • #ENV{id_article} vaudra la valeur id_article de l’article appelant (celui où se trouve l’appel du modèle)
  • #ENV{args/id_article} vaudra ’’ (vide)
• modèle appelé depuis un article avec argument explicite sans valeur :
  <mon_modele1|id_article=>
  • #ID_ARTICLE vaudra ’’ (vide)
  • #ENV{id_article} vaudra ’’ (vide)
  • #ENV{args/id_article} vaudra ’’ (vide)
• modèle appelé depuis un article avec argument explicite renseigné :
  <mon_modele1|id_article=25>
  • #ID_ARTICLE vaudra la valeur passée en argument : 25
  • #ENV{id_article} vaudra la valeur passée en argument : 25
  • #ENV{args/id_article} vaudra la valeur passée en argument : 25

Et alors ?
Connaissant l’id de l’objet (article, rubrique, mot, site...) depuis lequel notre modèle est appelé, il est désormais possible d’utiliser des boucles utilisant cette information, de telle sorte que le modèle devient ainsi contextuel en affichant des informations dépendantes de son lieu d’appel. Un même modèle appelé depuis plusieurs articles retournera ainsi des informations spécifiques différentes pour chaque article.

Attention toutefois !
Comme désormais l’id de l’objet appelant (id_article, id_rubrique, id_mot...) est toujours transmis au modèle, il devient impossible d’utiliser dans le modèle une boucle avec le critère conditionnel {id_article?} (ou {id_rubrique?}, ou {id_mot?} ...)
L’astuce consistera à utiliser 2 critères dépendants de #ENV{args/id_article} car seul #ENV{args/id_article} nous renseigne sur l’argument « id_article » passé explicitement au modèle.

Explications :

• si #ENV{args/id_article} existe c’est que id_article a été explicitement renseigné dans l’appel du modèle (exemple : <mon_modele1|id_article=25>). Dans ce cas, la boucle cherchera id_article >= 25 et id_article <= 25 ; soit (tout le monde aura trouvé) : id_article = 25 ;
• si #ENV{args/id_article} n’existe pas (id_article n’a pas été explicitement renseigné dans l’appel du modèle : <mon_modele1>), alors la boucle cherchera id_article >= 0 et id_article <= 99999999 ; soit (tout le monde aura trouvé) : tous les articles.

on reproduit bien là le comportement de {id_article?}.

Ne pas transformer en lien cliquable les urls saisies en dur dans un texte

Si l’on veut que ce soit systématique sur l’ensemble du site, il faut ajouter dans un fichier « mes_fonctions.php » à placer dans« squelettes/ » :

Mais on peut aussi vouloir ne réserver ce traitement qu’à certains articles.
Dans une copie de « article.html » que l’on aura placée dans « squelettes/ » on écrira alors :

ceci pour que sur les seuls articles 5 et 62 les urls saisies directement ne soient pas transformées en lien cliquable. Les urls saisies dans tous les autres articles continuant de recevoir le traitement standard de spip seront donc cliquables.

Utiliser une boucle DATA pour récupérer des champs en CamelCase sur une base externe

SPIP permet d’aller piocher des données dans une base externe (à condition qu’elle ait été déclarée depuis ecrire/?exec=admin_tech).
Il peut arriver que cette base externe contienne des tables dont les champs ont été définis en « CamelCase » (un mélange de minuscules et majuscules, comme par exemple : « NumOrdre »). Dans ce cas, SPIP est incapable d’afficher tant #NUMORDRE que #CHAMP_SQL{NumOrdre} dans la boucle.
Pour remédier à ça, nous fabriquerons une boucle DATA ainsi :

Dans ce code, connecteur correspond au nom de la base externe déclarée (on peut le retrouver à partir de ecrire/?exec=admin_tech dans la liste « Bases supplémentaires déjà interrogeables :» ou en parcourant le dossier config/ pour y repérer le fichier de connexion « nom_du connecteur.php »

Table des matières tout en javascript

Récupère les textes des intertitres et génère une table des matières. Comme le javascript se lance après l’affichage de la page, il peut y avoir un petit saut de l’affichage, selon l’endroit où la table des matières est insérée dans le HTML.

L’image utilisée pour le retour au sommaire encodée en base64 et transmise par le javascript.

Afficher n’importe où (hors BOUCLE) le LOGO d’une rubrique particulière

où #ID_DE_LA_RUBRIQUE peut être soit un nombre écrit « en dur » dans le squelette, soit un #ID_RUBRIQUE ou #ID_PARENT, soit encore un #GET défini antérieurement.

peut aussi s’appliquer à un article (on utilisera « arton » au lieu de « rubon ») ou un site syndiqué (« siteon ») ou un auteur (« auton »)...

Afficher le logo (même hors boucle) d’un « objet spip » en utilisant un modèle

Nous créons le modèle « squelettes/modeles/logo.html » :

Ce modèle retourne le chemin d’accès à un logo stocké à la racine de IMG/
par exemple : « IMG/arton25.png » ou « IMG/auton1.jpg » ... et ce, quel que soit l’objet (article, rubrique, auteur...) et quelle que soit l’extension du fichier logo (gif, png ou jpg).

On peut l’utiliser (y compris en dehors d’une boucle) pour afficher l’image logo de n’importe quel objet :

ou un lien vers cette image logo :

Nous pouvons ainsi avoir un logo qui pointe vers son fichier :

Pouvoir utiliser un critère conditionnel avec un nom de variable quelconque

L’usage de {critère ?opérateur #ENV{variable}} est limité par l’obligation que variable soit homonyme de critère.
On peut (on doit) écrire {titre ?= #ENV{titre}} mais pas {titre ?= #ENV{nimportequoi}}.
Pour contrecarrer cette interdiction, on peut néanmoins, dans certains cas, utiliser des écritures particulières pour chaque opérateur.

• pour le critère LIKE  :
      #SET{ok, #ENV{nimportequoi}}
      <BOUCLE_a(ARTICLES){chapo LIKE %#GET{ok}%}>
      #CHAPO
      </BOUCLE_a>

• pour le critère =  :
      #SET{ok, #ENV{nimportequoi}|sinon{.*}}
      <BOUCLE_b(ARTICLES){titre == #GET{ok}}>
      #TITRE
      </BOUCLE_b>

• pour le critère < sur un champ numérique (id_article) :
      #SET{ok, #ENV{nimportequoi}|sinon{999999}}
      <BOUCLE_c(ARTICLES){id_article < #GET{ok}}>
      #ID_ARTICLE
      </BOUCLE_c>

• pour le critère < sur un champ non numérique (texte ou date) :
      #SET{ok, #ENV{nimportequoi}|sinon{zzzzzz}}
      <BOUCLE_d(ARTICLES){titre < #GET{ok}}>
      #TITRE
      </BOUCLE_d>

• pour le critère > (là, c’est facile...) :
      <BOUCLE_e(ARTICLES){id_article > #ENV{nimportequoi}}>
      #ID_ARTICLE
      </BOUCLE_e>
      <BOUCLE_f(ARTICLES){titre  > #ENV{nimportequoi}}>
      #TITRE
      </BOUCLE_f>

Retrouver l’objet et l’id_objet concerné par la page en cours

Pouvoir afficher ou tester n’importe où dans le squelette (en dehors de toute boucle et y compris dans un MODELE ou un INCLURE) « l’objet » et l’« id_objet » concerné par la page courante.

dans mes_fonctions.php :

Afficher l’intervalle de temps entre une date donnée et la date courante

dans mes_fonctions.php :

Auto publier les articles d’une rubrique par l’intermédiaire d’un pipeline (Utilisation hors plugin)

Comme indiqué dans la documentation technique de SPIP, on peut utiliser un pipeline sans avoir à passer systématiquement par la création d’un plugin.

Après un rapide coup d’oeil dans dans la liste des pipelines, nous nous arrêtons sur le pipeline pre_insertion qui permet d’intervenir au moment de l’insertion d’un nouvel élément éditorial.

Suivant les indications mentionnées plus haut, on ajoute ceci dans le fichier config/mes_options.php :

En adaptant le contenu de la fonction ci-dessus, on peut appliquer ce traitement à tout type d’objet éditorial, ainsi que modifier un autre champ que le statut.

Pour finir, Il est recommandé de se rendre sur la page de gestion des plugins dans l’espace privé. Ceci va avoir pour effet de rafraîchir le cache pipeline (fichier tmp/cache/charger_pipelines.php). Les modifications effectuées ci-dessus seront alors prises en compte.

Automatiser un traitement particulier sur la balise #TEXTE des articles

À partir de ce qui est expliqué ici, on peut systématiser l’application d’un traitement particulier, sur les balises issues des boucles.

Dans notre exemple, si on souhaite cibler la balise #TEXTE des articles pour lui appliquer un traitement particulier avant affichage dans une boucle :

Dans le fichier config/mes_options.php, on ajoute :

Selon ses propres besoins, on peut bien évidement utiliser une fonction existante de spip (un filtre par exemple), au lieu de déclarer sa propre fonction.

Comme pour les pipelines, il est nécessaire d’aller dans l’espace privé -> gestion des plugins pour rafraîchir le cache.