SPIP

|set

Fil — 2015-12-19T13:49:42Z

Le filtre |set{nom} affecte la valeur courante à la variable nom. C'est une alternative, parfois plus commode à écrire, à la balise #SET{nom,valeur}.

Sommaire

Exemples

[(#TEXTE|mb_strlen|set{longueur})] [(#GET{longueur}) caractères]

est l'équivalent de

[(#SET{longueur,[(#TEXTE|mb_strlen)]})] [(#GET{longueur}) caractères]

Le deuxième argument du filtre |set{}, s'il est non nul, indique qu'il faut « continuer », c'est-à-dire passer la valeur dans la suite des filtres, ou l'afficher si on est en bout de chaîne :

[(#TEXTE*|set{brut,1}|propre|set{traite,1}|mb_strlen|set{longueur,1})]

…stockera le texte brut dans la variable brut, le texte traité dans traite, le nombre de caractères dans longueur, et affichera in fine la valeur longueur.

Voir aussi

|debug

Fil — 2014-08-14T08:24:13Z

Le filtre |debug peut servir à la mise au point d'un squelette ; il affiche directement à l'écran (pour le webmestre seulement) la valeur courante qui lui est passée. On la retrouve aussi dans le fichier de log debug.log.

L'éventuel argument qu'on lui passe permet de mieux se repérer si on a plusieurs points de debogage sur la même page.

[(#ID_ARTICLE|debug{id_article})] [(#ID_RUBRIQUE|debug{id_rubrique})]

affichera :

'id_article' = 12 'id_rubrique' = 4

Attention : Ce filtre doit être retiré une fois la mise au point effectuée.

Les itérateurs de SPIP - la boucle (DATA)

Fil, Matthieu Marcillaud — 2012-05-19T09:30:50Z

SPIP 3.0 a apporté une notion générale de boucle, basée sur les itérateurs de PHP.

Sommaire

Les boucles (DATA) ne portent plus exclusivement sur des requêtes SQL [1], mais elles peuvent tourner sur toutes sortes de listes de données.

Par exemple :

un tableau de données produit par une fonction quelconque (dont les itérateurs PHP)
le contenu d'un fichier local au format XML, CSV, JSON, YAML, etc.
une liste de fichiers dans un répertoire du serveur
une requête sur un webservice
une requête SQL (telle que calculée par SPIP, par ex.)
etc. (LDAP...).

Syntaxe et formats de la boucle `(DATA)`

C'est une boucle capable d'itérer n'importe quel tableau de données. Sa syntaxe de base est la suivante :

 #BALISES

Le critère {source format, données} définit les données sur lesquelles la boucle va itérer.

La définition d'une source de données nécessite deux éléments :

— La partie données : cet élément peut être de plusieurs natures :
- un tableau de données, par exemple #ENV*
- le chemin d'un fichier sur le disque dur, ex : sources/definitions.csv
- l'URL d'un fichier ou d'un webservice, ex : http://per.sonn.es/bases/phobia.fr.yaml
- ou encore, une chaîne quelconque que le format saura transformer en tableau de données, ex : "select * from flickr.photos.search where text='spip'"

— La partie format est à prendre dans la liste ci-dessous :
- table (alias array ou tableau), pour un tableau déjà créé
- csv, json, yaml pour un fichier composé dans l'un de ces formats
- file pour boucler sur les lignes d'un fichier
- glob ou pregfiles pour boucler sur les fichiers d'un répertoire (et plus...)
- rss (alias atom) pour lire un flux de nouvelles
- plugins pour lister les plugins actifs sur le site
- yql pour envoyer une requête sur le webservice de Yahoo Query Language
- sql pour envoyer une requête brute au serveur SQL . Attention dans ce cas : 1) la chaîne spécifiant la requête ne doit pas contenir de fins de lignes 2) utiliser la syntaxe {source sql, connecteur:requete} pour envoyer la requête sur une base externe
- ics pour boucler sur des calendriers (nécessite le plugin icalendar : lire Plugin iCalendar)
- etc.

Tous ces formats sont déjà disponibles, et il est très aisé d'en ajouter un nouveau, en créant une simple fonction inc_FORMAT_to_array($u). A titre d'exemple voici la fonction qui transforme un fichier JSON en tableau de données :

function inc_json_to_array_dist($u) { if (is_array($json = json_decode($u)) OR is_object($json)) return (array) $json; }

On peut déclarer une nouvelle boucle DATA dans un fichier inc/ma_source_to_array.php

function inc_ma_source_to_array_dist($data,$param1='',$param2='') { // $data contient le contenu du fichier (local | distant) ou bien la valeur de la variable passée dans le critère. // $param1, $param2... sont des paramètres facultatifs ... }

et l'afficher ensuite :

 #VALEUR

Cache :
- Le critère {datacache 3600} permet de spécifier la durée pendant laquelle le résultat d'une boucle DATA est enregistré en cache. On peut donc désactiver tout cache avec le critère {datacache 0}
- Voir plus d'infos sur les caches des boucles DATA

Filtrage, tri, pagination, fusion

Filtres. Comme les boucles SQL, les boucles (DATA) peuvent être filtrées par des critères du type {valeur=x} ; les opérateurs disponibles sont =, >, <, >=, <=, == (expression rationnelle) et LIKE.

Cependant ce filtrage s'effectue non pas en amont lors de la requête, comme en SQL, mais en aval, sur le tableau de données initialement récupéré.

Tris. Les tris {par xx} sont également possibles, avec leur variante {!par xx} pour trier en ordre inverse.

Pagination. La pagination fonctionne normalement, ainsi que le critère {offset,limite}.

Fusion. Le critère {fusion /x/y} fonctionne aussi. Par exemple, pour un fichier d'adresses au format CSV, si l'email est le champ n° 3, on pourra ne retenir qu'un seul enregistrement par email avec la boucle suivante :

 '}> #VALEUR{0} : #VALEUR{3}

La fusion se fait après le tri, et retient le premier élément rencontré. De cette manière, si un tableau est trie {!par date} puis fusionné sur l'email, l'enregistrement retenu pour chaque email sera le plus récent.

Le critère `{liste ...}`

Pour simplifier l'écriture de tableaux de données, lorsqu'il s'agit d'une simple liste d'éléments qu'on veut indiquer manuellement, la boucle (DATA) accepte le critère {liste ...}, qui permet de constituer un tableau de données en séparant celles-ci par des virgules.

Boucle :

"}>  [(#VALEUR|mult{#_i:VALEUR})]

Résultat :

18 21 24
24 28 32
30 35 40

A noter : on a utilisé #_i:VALEUR pour référencer dans la boucle j la valeur calculée par la boucle i.

Voir aussi Deux itérateurs simples : les listes et les énumérations

Le critère `{enum ...}`

 #VALEUR

Résultat :

2 4 6 8 10

 #VALEUR

Résultat :

g, h, i, j, k, l, m

val1 et val2 sont 2 valeurs numériques, ou bien 2 caractères. SPIP déterminant laquelle des 2 valeurs est la plus petite, cette boucle va énumérer les valeurs entre val1 et val2. Dans la première forme, le pas n'est pas précisé : il vaut 1 par défaut.

Voir aussi Deux itérateurs simples : les listes et les énumérations

Protection des données manipulées par les itérateurs

La boucle (DATA) protège automatiquement toutes les balises qui sont à l'intérieur, car les données qu'on y manipule sont en général de provenance inconnue et potentiellement dangereuse. Cela impacte aussi les balises des formulaires (#FORMULAIRE_xx) qu'il faut donc utiliser avec un * comme expliqué dans l'article sur les balises étoilées.

 #FORMULAIRE_XXX*{#VALEUR}

A noter : si vous utilisez le plugin "Bonux", il suffira d'utiliser une boucle (POUR), qui elle n'a pas ce comportement.

 #FORMULAIRE_XXX{#VALEUR}

Lire la suite : régalez-vous avec des exemples de boucles (DATA) !

[1] Sans surprise, l'itérateur classique de SPIP s'appelle SQL : il exécute la requête telle que SPIP l'a calculée, et sait parcourir la liste de résultats pour les envoyer à la boucle.

Exemples de `BOUCLE(DATA)`

Fil — 2012-05-19T09:30:11Z

Quelques exemples de boucles (DATA) permises par les itérateurs de SPIP.

Boucler sur un tableau

On peut boucler arbitrairement sur un tableau tel que ceux renvoyés par les balises suivantes : #ARRAY, #GET, #SESSION, etc.

Boucle sur les données de la session de l'utilisateur connecté :

 #CLE: #VALEUR

Boucle sur un tableau contenant des mots défini avec #SET / #GET [1] :

 #VALEUR

Boucle sur un tableau quelconque contenant des couleurs :

"} > [(#VALEUR{couleur})] est équivalent à [(#COULEUR)]

Résultat :

vert est équivalent à vert
bleu est équivalent à bleu

À noter : quand #VALEUR est un tableau, on peut accéder à #VALEUR{ma_cle} qui est équivalent à #MA_CLE

Lister les `plugins` actifs

Le format de source plugins ne nécessite pas de jeu de données en entrée.

Boucle :

 #VALEUR

Résultat :

crayons memoization icalendar

Filtrer les données avec `{cle==...}`

Itérons sur la balise #CONFIG qui comporte tous les éléments de configuration du site enregistrés dans la table spip_meta.

Comme la balise #CONFIG est un tableau de données, on va employer le format table. Un critère {cle==version} filtre le tableau en ne retenant que les valeurs de configuration dont la clé contient le mot « version ».

Boucle :

 #CLE
 #VALEUR

Résultat :

version_installee
16428

revisions_base_version
1.1

Indexation_base_version
0.4

...

Lister le contenu d'un répertoire

La fonction glob() de PHP permet de lister les fichiers correspondant à un masque ; elle a été transposée pour la boucle (DATA).

Boucle qui liste par ordre alphabétique les sous-répertoires de IMG :

 [(#VAL{Y-m-d H:i:s}|date{#MTIME})] - [(#FILE)] - [(#FILENAME)]

Résultat :

2018-02-28 17:33:25 - IMG/gif 2018-02-28 18:44:14 - IMG/jpg 2018-02-28 17:33:20 - IMG/png

Boucle qui liste par date inverse les 3 fichiers les plus récents de IMG/jpg :

 [(#VAL{Y-m-d H:i:s}|date{#MTIME})] - [(#FILE)]

Résultat :

2018-02-28 18:45:39 - IMG/jpg/IMG011.jpg 2018-02-23 12:22:15 - IMG/jpg/IMG003.jpg 2018-02-23 12:21:47 - IMG/jpg/IMG004.jpg

Lister des fichiers correspondant à un masque

La fonction preg_files de SPIP permet de lister des fichiers selon une expression régulière et de manière arborescente. [2]

Exemple : les fichiers plugin.xml du site.

Boucle :

 #VALEUR[ - (#VAL{Y-m-d H:i:s}|date{#VALEUR|filemtime})]

Résultat :

 ../plugins/a2a/plugin.xml - 2011-04-16 20:47:02 ../extensions/simplog/plugin.xml - 2010-09-05 16:08:39 ../extensions/vertebres/plugin.xml - 2011-03-19 16:49:51 ../extensions/z-core/plugin.xml - 2010-09-05 16:08:47

Lire un fichier CSV

Nous allons cette fois afficher un fichier au format CSV se trouvant sur notre disque dur. Le fichier adresses.csv contient un carnet d'adresses :

Fil,Philippe,fil@rezo.net,http://rezo.net/ Marcimat,Matthieu,marcimat@rezo.net,http://marcimat.magraine.net/

Boucle :

"}> #VALEUR{0} : #VALEUR{3}

Résultat :

Marcimat: http://marcimat.magraine.net/
Fil: http://rezo.net/

À noter : le critère de tri {par /3} permet de trier sur la colonne n° 3, contenant les adresses web. Le / initial est obligatoire dans le cas d'un tri sur une clé numérique ou commençant par un chiffre.

Dans la démo de CSV livrée avec le plugin itérateurs, on trouvera un exemple beaucoup plus complet permettant de gérer proprement les clés du fichier CSV, et même de trier ou de fusionner sur ces clés.

Un document Google (spreadsheet)

Dans Google Documents il est possible de « Partager > Publier un document ». Une fois cela fait, on peut récupérer l'adresse du document au format CSV, et l'afficher sous forme de table HTML.

Boucle :

#SET{key,0AolUP3c6K9JodGwxRjJzb2hyTGZLU29qRVItRXk1VXc}     #VALEUR{0}  #VALEUR{1}  #VALEUR{2}

Résultat :

Pays PIB Population
Rémitanie 12 1
Baldoghistan 23 2
Républiques Unies 43 3
Diloduristan 12 4
Zarlatie 9 5

Pays	PIB	Population
Rémitanie	12	1
Baldoghistan	23	2
Républiques Unies	43	3
Diloduristan	12	4
Zarlatie	9	5

D'autres modes d'extraction sont possibles, notamment sous forme de liste, ou de cellules :

Liste :

Rémitanie pib: 12, population: 1 Baldoghistan pib: 23, population: 2

...

Cellules :

A2: Rémitanie B2: 12 C2: 1 A3: Baldoghistan B3: 23 C3: 2

...

Une page HTML

Lire une page HTML, isoler une ligne avec un certain marquage et y sélectionner une valeur interressante pour l'afficher proprement ? C'est possible ! Ici nous allons afficher le nombre de followers sur un compte twitter.

Boucle :

#SET{followers,'data-nav="followers"'}  [(#VALEUR|match{title="(.*)",1}|replace{ abonnés}|trim|replace{ \d+$, k})]

Résultat :
1 k

Un webservice au format YAML

Le site http://per.sonn.es/ propose une API permettant de lire chaque profil au format YAML. On va donc interroger le site sur l'un de ces profils, et parcourir le résultat pour afficher la liste des amis de la personne concernée.

Commençons par analyser mon profil (à l'adresse http://per.sonn.es/Fil.yaml) :

name: Fil sex: F birthday: '1966-08-17' job: Calorifugeur friends: - 'Maude Guérin' - 'Zohra Robin' - 'Pierre-Yves Philippe' - 'Lauriane Bertin' - 'Jeannine Pichon' - 'Vanessa Michel' - 'Wendy Allard' ... city: 'Mouxy (Rhone-Alpes)'

Si l'on charge cette adresse avec le format yaml, on obtient un tableau de données un peu plus complexe que dans l'exemple précédent. En effet, certains items sont des chaînes de caractères, d'autres, comme la liste d'amis, des listes de chaînes.

(name => Fil, sex => F, friends => ( Maude Guérin, Zohra Robin, ...), ... ).

Parcourons ces données :

Boucle :

 #CLE
 [(#VALEUR|print)]

Résultat :

name

Fil

sex

F

birthday

1966-08-17

job

Calorifugeur

friends

Maude Guérin, Zohra Robin, Pierre-Yves Philippe, Lauriane Bertin, Jeannine Pichon, Vanessa Michel, Wendy Allard, Sylvie Michaud, Gwenaël Voisin, Paule Mary, Maia Ribeiro, Josianne François, Lucas Fernandes

...

Maintenant, nous voulons boucler sur les amis de Fil. Pour cela il y a deux possibilités. La première consiste à récupérer les données avec notre boucle (DATA) au format yaml, puis à stocker le tableau d'amis dans une variable que nous allons parcourir avec une autre boucle (DATA), cette fois au format table :

Boucle :

  #VALEUR

Résultat :

Maude Guérin - Zohra Robin - Pierre-Yves Philippe - Lauriane Bertin - Jeannine Pichon - Vanessa Michel - Wendy Allard - Sylvie Michaud - Gwenaël Voisin - Paule Mary - Maia Ribeiro

Le critère `{datapath ...}`

On voit bien dans l'exemple ci-dessus que, plus le tableau de données est complexe, plus les boucles qu'il va falloir imbriquer seront pénibles à coder. C'est là qu'intervient le critère {datapath ...}, qui permet d'indiquer à la boucle (DATA) le chemin (au sens de Xpath) vers le tableau de données qui nous intéresse [3].

Avec cette balise notre liste d'amis s'écrit en une seule boucle (et on en profite pour ajouter une pagination) :

Boucle :

 #VALEUR  #PAGINATION

Résultat :

Maude Guérin - Zohra Robin - Pierre-Yves Philippe - Lauriane Bertin - Jeannine Pichon - Vanessa Michel - Wendy Allard - Sylvie Michaud - Gwenaël Voisin - Paule Mary
0 | 10 | 20 | 30 | 40 | ...

Une API en json

Pour afficher des images d'écureuils issues d'Instagram (du temps où instagram proposait une API json, mais cette fonctionnalité a été retirée) :

  [(#THUMBNAIL_SRC|balise_img)]

Résultat :

Un fichier XML

Le plugin « citations aléatoires » contient un fichier de citations, au format XML Ce plugin non maintenu n'est pas migré sur la forge GIT mais on peut le trouver sur cette archive (https://github.com/Cerdic/spip-zone-plugins/blob/master/citation_aleatoire/trunk/citations/citations_fr.xml). La boucle (DATA) permet de l'exploiter directement :

Boucle :

[(#REM) Récupérer le fichier au format txt de la zone - mieux vaut l'enregistrer localement sur le serveur] [(#SET{c,https://github.com/Cerdic/spip-zone-plugins/blob/master/citation_aleatoire/trunk/citations/citations_fr.xml?format=txt})]   [(#VALEUR{0/auteur/0})
] [(#VALEUR{0/texte/0})
]

Résultat (au hasard donc) :

L'idéal quand on veut être admiré, c'est d'être mort.

(Michel Audiard)

Utiliser un webservice comme YQL — Yahoo Query Language)

YQL est un webservice permettant d'interroger de façon simple de nombreux sites comme google, twitter, flickr, etc. Avec la boucle (DATA), SPIP facilite grandement son intégration sous forme de boucles : Cf. http://zzz.rezo.net/Exemples-de-bou....

Les Itérateurs PHP

SPIP est capable d'utiliser les itérateurs PHP standards. Il convient de se reporter à leur documentation, qui est souvent très succincte, et de vérifier que les itérateurs en questions sont disponibles sur votre système.

Notons, par exemple, DirectoryIterator, qui permet de lister les fichiers d'un répertoire :

Boucle :

 [(#VAL{Y-m-d H:i:s}|date{#GETMTIME})] / #VALEUR  
 #PAGINATION

Résultat :

2008-02-01 23:27:23 / arton2135.jpg 2008-08-21 11:12:58 / DSC03420.jpg 2008-08-21 11:13:11 / DSC03421.jpg 2009-08-27 11:20:11 / hash-1.jpg 2009-08-27 11:20:04 / hash.jpg

Il convient d'indiquer à SPIP qu'il s'agit d'un itérateur PHP, en indiquant (php:...) avant le nom de l'itérateur.

Le critère {args xx,yy} définit les arguments que l'on va passer à l'itérateur lors de son initialisation. Pour DirectoryIterator, il s'agit du chemin du répertoire à lister.

Les méthodes de cet itérateur (cf. http://php.net/manual/fr/class.directoryiterator.php) sont disponibles sous forme de balises (ici, #GETMTIME).

Remarque : pour lister le contenu d'un répertoire, le format glob de la boucle (DATA) est sans doute plus facile à utiliser que cet itérateur PHP.
...

Un calendrier au format iCalendar/ics

Cette fonctionnalité nécessite l'activation du plugin iCalendar. Il est alors possible d'itérer sur les événements d'un calendrier publié au format iCalendar/ics. L'article consacré sur SPIP-Contrib au plugin icalendar donne un exemple complet.

[1] Voir : #SET et #GET

[2] Plus versatile, mais plus lente que glob.

[3] Pour vous aider à déterminer le datapath, vous pouvez visualiser le tableau des résultats en insérant le code [

(#VALEUR|print_r{1})

] dans votre boucle data/

#DOUBLONS

cam.lafit, denisb, Fil — 2010-07-08T22:28:27Z

#DOUBLONS{mots} donne l'état des doublons (MOTS) à cet endroit, sous forme de tableau d'id_mot array(1,2,3,...)

#DOUBLONS tout seul donne la liste brute de tous les doublons

#DOUBLONS*{mots} donne la chaîne brute ",1,2,3,..."
(changera si la gestion des doublons évolue)

Pour des doublons « nommés » (exemple : 100}{doublons A}>) on utilisera :
#DOUBLONS{articles, A} pour avoir le tableau des id_articles.

Pour passer le ou les tableaux de doublons à un INCLURE, on notera :

#INCLURE{fond=noisette, env, doublons=#DOUBLONS{articles, A}}

pour un tableau nommé {doublons A} d'une BOUCLE(ARTICLES)
et

#INCLURE{fond=noisette, env, doublons}

pour tous les tableaux de doublons déclarés dans le squelette appelant (avant l'appel de l'INCLURE).

Pour récupérer un tableau de doublons depuis un INCLURE, il conviendra de ne faire retourner par cet INCLURE que #DOUBLONS*{articles, B} et, dans le squelette appelant, d'utiliser

#SET{ret, #INCLURE{fond=noisette, env, doublons}|explode{','}}

le #GET{ret} résultant pouvant alors être utilisé dans un critère de boucle ({id_article IN #GET{ret}}).

Écran de sécurité

Fil — 2009-08-05T20:13:17Z

L'écran de sécurité est un fichier php unique, qui protège vos sites en bloquant certaines attaques liées à des trous de sécurité. Ce système permet de réagir très rapidement lorsqu'un problème est découvert, en colmatant le trou sans pour autant devoir mettre à niveau tout son site ni appliquer un « patch » complexe.

Version courante : 1.6.7

Sommaire

Télécharger

Philosophie

Lorsqu'elle découvre ou qu'on lui signale un « trou » de sécurité, l'équipe de développement de SPIP s'efforce de corriger le problème au plus vite dans sa version de développement et dans ses versions stables, afin de ne plus diffuser de code fautif.

Cependant, la majorité des utilisateurs n'a pas toujours le temps ou la possibilité de faire la mise à jour, et a tendance à peser le pour et le contre face au risque d'avoir, lors d'une mise à jour même minime, des incompatibilités ou des décalages avec le code testé et validé qu'elle a mis en ligne.

Pour un hébergeur, l'information concernant un problème de sécurité est également à double tranchant : d'un côté il ne souhaite pas laisser de « trou » sur un de ses sites hébergés, de l'autre il n'a pas toujours l'autorisation de modifier les sites. Et les mettre hors-ligne n'est bien souvent pas envisageable, sauf chez les hébergeurs cheap ou paranos.

L'écran de sécurité est là pour répondre à cette problématique. Il s'agit d'un fichier php unique et séparé de SPIP, que l'on peut mettre à jour indépendamment du reste du code, et qui est compatible avec toutes les versions de SPIP, même les plus anciennes.

Ce fichier ne se substitue pas a une véritable mise à niveau de votre version de SPIP, mais il peut permettre de bloquer certaines attaques en attendant une migration propre.

De fait, cet écran peut être activé au niveau du serveur sur l'ensemble des scripts php (SPIP ou pas), et garantit, s'il est à jour, que toutes les failles connues de quelque version de SPIP que ce soit sont impossibles à exploiter. D'où son nom d'« écran » : il se place entre le visiteur et SPIP, et vérifie que le visiteur n'est pas en train d'essayer d'exploiter une attaque connue.

Lorsqu'une nouvelle faille est découverte, il suffit donc de mettre à jour cet écran pour parer toute attaque via ladite faille ; ça laisse le temps de mettre à jour les scripts SPIP à tête reposée au moment idoine.

Téléchargement

Télécharger l'écran de sécurité :
https://git.spip.net/spip-contrib-o...

Le code de cet écran est consultable à l'adresse suivante :
https://git.spip.net/spip-contrib-o...

On peut aussi le récupérer et le synchroniser avec GIT :
git clone https://git.spip.net/spip-contrib-outils/securite.git

Le fichier est nommé ecran_securite.php

Installation

Il y a plusieurs méthodes pour installer cet écran :

Au niveau d'un site SPIP donné :

Il suffit de déposer le fichier ecran_securite.php dans le répertoire config/ du site pour qu'il soit pris en compte automatiquement.

Au niveau du serveur :

Déposer ce fichier dans un répertoire lisible par tous les sites (par exemple /usr/share/php/ecran_securite/).

Modifier php.ini, en ajoutant les lignes suivantes :

auto_prepend_file '/usr/share/php/ecran_securite/ecran_securite.php'

ou bien, modifier httpd.conf, en ajoutant :

php_admin_value auto_prepend_file '/usr/share/php/ecran_securite/ecran_securite.php'

Dans ces deux cas, l'écran est inclus à chaque « hit » php avant le lancement du script normal. Il peut donc bloquer tout appel « malfaisant ».

Configuration

Outre la sécurité, l'écran a la capacité de moduler les accès des robots d'indexation aux scripts php, de manière à leur dire de « revenir plus tard » lorsque le serveur est saturé.

Pour les versions récentes, ce comportement est configurable, en indiquant dans le fichier config/ecran_securite_options.php :


Ce réglage active la protection anti-robots quand la charge du serveur (load) excède la valeur X. La valeur par défaut est 4 ; pour désactiver, mettre 0.

NB : à partir de SPIP 5.0, la valeur par défaut sera de 0.

Note :

Il ne faut pas confondre un load de 4 et une charge CPU de 400% : il n'y a pas de correspondance directe.

En particulier le load reflète les processus en attente, ce qui n'est pas forcément dû à la CPU (parfois ce sont les I/O —notamment d'un NFS—. cf Load_average)
Aussi la valeur de _ECRAN_SECURITE_LOAD ne doit pas s'évaluer uniquement à l'aune du nombre de processeurs de la machine.

D'autant plus que le mécanisme d'allègement de l'écran de sécurité s'active progressivement au fur et à mesure que le load dépasse la valeur seuil : à 4.01 de load il n'y aura quasiment aucune 503 d'envoyée.
4 représente une bonne valeur : elle permet de garder une performance serveur satisfaisante ; elle évite de faire attendre le visiteur.

`Fonctionnement de l'écran`


L'écran intervient le moins possible, il ne fait que bloquer des variables dont on sait qu'elles ont été, à un moment donné de l'histoire de SPIP, mal contrôlées, et qu'elles pouvaient par conséquent donner lieu à une attaque. Il est donc compatible avec toutes les versions de SPIP.
Toutefois, l'écran verrouille systématiquement certaines variables. Ainsi, par exemple, les variables nommées id_xxx sont toutes contrôlées comme étant obligatoirement des valeurs numériques entières, afin d'éviter toute injection de code SQL via ce genre de variable très courante.
Par ailleurs il bloque l'accès, pour les robots seulement, aux pages comportant plusieurs paginations simultanément (car la combinatoire issue de plusieurs paginations peut entraîner un trop grand nombre de requêtes).

`Vérification et test`


Pour vérifier la bonne exécution du script, appeler le site public en ajoutant à l'url soit ?test_ecran_securite=1, soit &test_ecran_securite=1.
l'affichage résultant devrait être :


Error 403

You are not authorized to view this page (test 1.6.7)



#AUTORISER
cam.lafit, Fil — 2009-05-25T20:24:59Z
Une balise #AUTORISER permet de demander des autorisations dans un squelette.
		
Sommaire
 Voir aussi
Elle renvoie un espace si l'autorisation est donnée, et une chaîne vide dans le cas contraire. On met autant d'arguments (et les mêmes) qu'on en mettrait dans la fonction autoriser().
Par exemple, pour savoir si le visiteur courant peut accéder aux statistiques de l'article :
[(#AUTORISER{voirstats,article,#ID_ARTICLE}) voir les stats ] 
Comme pour la fonction autoriser(), on peut passer un #ID_AUTEUR en argument pour demander si l'auteur en question est autorisé à .... .
Par exemple pour signaler d'une étoile les administrateurs et rédacteurs dans une liste d'auteurs :
 #NOM [(#AUTORISER{ecrire,'','',#ID_AUTEUR}) *]  
Un autre exemple, ci dessous, si le visiteur a des droits de modifications sur l'article, afficher un formulaire pour l'éditer, qui, une fois validé, retourne sur la page de l'article en question :
[(#AUTORISER{modifier, article, #ID_ARTICLE}) #FORMULAIRE_EDITER_ARTICLE{#ID_ARTICLE, #ID_RUBRIQUE, #URL_ARTICLE} ] 
Rappel : les arguments de autoriser sont, dans l'ordre, (faire, quoi, id, qui, options).
Voir aussi
 API « autoriser » [ redirection ]
 La gestion des autorisation sur Programmer.spip.net


Utiliser les modèles
Fil — 2006-08-29T23:04:16Z
Un modèle est un petit squelette SPIP qui décrit un fragment de HTML facile à insérer dans un autre squelette ou — et c'est là le principal intérêt — dans le texte d'un article.
		
Sommaire
 Des usages multiples
 En pratique
 Des paramètres à foison
 Un emploi possible dans les squelettes
 Les modèles par défaut
 Quelques conseils pour écrire un modèle
 Voir aussi
Inspiré des modèles de Wikipédia, le système des modèles offre de nouvelles capacités aux webmestres et aux rédacteurs.
Les modèles sont une extension des classiques raccourcis  et . Ceux-ci correspondent désormais aux modèles /plugins-dist/medias/modeles/img.html et /plugins-dist/medias/modeles/doc.html.
Leur syntaxe a été étendue, et il est possible de spécifier, outre l'alignement (,  ou ), une classe plus générique, qui soit correspond à un squelette précis, s'il existe, soit à une classe CSS ( ira chercher le modele modeles/img_classe.html, si ce fichier existe, sinon utilisera le modèle modeles/img.html, mais avec un paramètre class="classe").
Mais les modèles ne se limitent pas aux images et documents ; il est ainsi possible de créer de nouveaux raccourcis de la forme , simplement en ajoutant un squelette dans le répertoire modeles/ de son dossier de squelettes !

On prendra soin de nommer son fichier en lettres minuscules (« bas de casse »). Pour éviter les différenciations sur certains systèmes serveur entre le_fichier01.html et Le_Fichier01.html, SPIP ne recherchera que des fichiers nommés en minuscules.

En l'absence de tout modèle correspondant au raccourci indiqué (par exemple, ), le gestionnaire de modèle de SPIP regarde s'il connaît l'objet demandé (ici, breve), et si ce dernier a une URL.
 Dans ce cas (vérifié ici, car les brèves sont connues du système et disposent d'une fonction d'URL), SPIP remplace le raccourci  par un petit encadré flottant, avec un lien vers la brève, et l'affichage de son titre, comme si l'on avait indiqué [->breve1].
Si l'objet n'est pas connu, SPIP laisse le raccourci intact, pour qu'il soit éventuellement traité par la suite (par un plugin ou un filtre supplémentaire), ou tout simplement ignoré.

Il est par ailleurs possible de passer des paramètres supplémentaires aux modèles. La syntaxe en est généralisée et accepte même du HTML, comme dans l'exemple :
Count Basie |photo=12> 
qui pourrait appeler un modèle modeles/son.html, lequel exploiterait les paramètres pour afficher la photo numéro 12, dans un cadre de couleur #ff0000, avec une légende comportant des mots en italique.
Des usages multiples
- Changer l'aspect des raccourcis de documents. Il suffit de recopier plugins-dist/medias/modeles/img.html dans un sous-répertoire modeles/ de son répertoire de squelettes, et de modifier ce fichier. Idem pour les raccourcis  et , bien que ce dernier soit d'une complexité qui peut rebuter...

Attention :  ne vous lancez pas dans la modification des modèles pour des modifications mineures du rendu de ces raccourcis — il est souvent plus facile de modifier les styles spip_documents_xx à partir des fichiers CSS de votre site.
- Afficher un tableau CSV (Excel). Il suffit de charger le fichier, puis de l'appeler avec ainsi  pour afficher les données du fichier CSV sous forme de tableau HTML !
- Associer un site à un article. En ajoutant dans ses squelettes un modèle modeles/site_box.html, on crée immédiatement un nouveau raccourci . On écrit alors le modèle (avec des boucles classiques) de manière à lui faire afficher le nom du site, suivi de liens vers les 3 derniers articles syndiqués, dans une boîte flottant sur la droite, et voici une infobox facile à placer dans un article. Un paramètre pourrait indiquer le nombre d'articles à afficher, la présence ou non de résumés, etc.
- Afficher une image timbrée. Une fois qu'on sait faire un squelette qui affiche une photo sous forme de timbre-poste (voir Un site dûment timbré), il suffit de le nommer modeles/timbre.html pour créer le raccourci . Avec, pourquoi pas, des paramètres de taille, de couleur, de choix du tampon, etc [1].
Bien entendu on peut imaginer de la même façon des modèles affichant les images en sépia, en version réduite, etc. Gageons que tout cela sera rapidement disponible sous forme de plugins.
- Créer un article composite. Supposons qu'on ait besoin d'un article composé du « chapo » de l'article 1 et du texte de l'article 2. Rien de plus simple : on crée deux modèles, qui renvoient tout simplement, pour l'un, le chapo de l'article demandé, pour l'autre son texte, et dans notre article composite on indique, dans le champ chapo : , et dans le champ texte : . On peut y ajouter filtres, balises et bidouilles à volonté...
- Installer un article dans plusieurs rubriques. En programmant des modèles ,  etc, il devient envisageable de mettre une copie d'un article dans un autre article, sans dupliquer les données. On obtient ainsi un article « fantôme » qu'on peut installer dans une nouvelle rubrique (avec, en plus, la possibilité de le titrer différement ou de lui ajouter des éléments).
- Faire un sondage. Le plugin Formidable, qui permet de créer des formulaires et de les exploiter dans des articles avec le raccourci , a été réécrit à partir des modèles.
- Afficher une citation aléatoire. Si on a mis des citations dans ses brèves, un raccourci  peut en extraire une au hasard (critère {par hasard}{0,1} sur une boucle de brèves), et l'afficher dans un encadré flottant à côté du paragraphe courant.
- Insérer un document dans une autre langue que la langue de l'article. Les modèles fonctionnant comme des inclusions, le paramètre lang=xx y est toujours disponible. Si l'un de vos documents est bilingue (par exemple avec un « bloc multi » dans le descriptif), vous pouvez afficher le descriptif en espéranto, dans un article en japonais, en appelant . Si le squelette du modèle contient des chaînes de langue, elles seront interprétées, le cas échéant, dans la langue passée en paramètre.
- Afficher un graphique. On passe une table de données au modèle, qui se débrouille ensuite pour créer le graphique et l'insérer dans le flux de texte.
- Un intertitre sous forme d'image. Pourquoi ne pas envisager un raccourci  ?

En pratique
Pour éviter toute collision avec les balises HTML, un modèle ne peut pas être appelé par un raccourci comme  !
Pour appeler un modèle simple sans paramètre il faut nécessairement :
 soit lui affecter un identifiant numérique : 1> ;
 soit faire suivre son nom d'un pipe | : |>)

Dans le premier cas, l'identifiant passé sera récupérable à l'intérieur du squelette le_modele.html avec #ENV{id} ou encore #ENV{id_le_modele} (qui vaudront donc « 1 » dans notre exemple) ;
Dans le second cas #ENV{id} comme #ENV{id_le_modele} vaudront respectivement « 0 » (zéro).
Des paramètres à foison

La syntaxe des raccourcis de modèles est de la forme
 
 
 filtre|parametre1=valeur>.

Les paramètres peuvent être composés de HTML et de raccourcis SPIP (à condition, bien sûr, que les modèles appelés aient prévu de les traiter).
Les paramètres peuvent s'étendre sur plusieurs lignes, ce qui permet l'écriture relativement aérée :
Das Lied der Deutschen |url=http://fr.wikipedia.org/wiki/Allemagne > 
Le squelette récupère tous ces paramètres dans la balise #ENV, ainsi #ENV{population} vaut 82000000. Cette balise étant sécurisée contre toute injection de javascript, si on veut permettre du HTML dans un paramètre, il convient d'utiliser la notation #ENV*{hymne} ; si l'on veut en plus appliquer la typographie de SPIP, on peut employer [(#ENV*{hymne}|typo)] ou [(#ENV*{hymne}|propre)].
Le paramètre principal (ici, 10), est passé sous deux formes : #ENV{id}=10, et #ENV{id_modele}=10. Ce qui permet d'accéder, pour un modèle appelé par , au chapo de l'article 3 en faisant :
#CHAPO 
ou bien aux brèves liées au mot-clé numéro 3, par ;
#TITRE 
Comme on le voit, chaque modèle devra avoir sa propre documentation, car le raccourci n'indique rien en lui-même sur l'exploitation faite des éléments passés par le raccourci.

Un emploi possible dans les squelettes

Les modèles ne sont pas limités à des raccourcis dans les articles. Il est possible de les appeler depuis un squelette, en utilisant la balise #MODELE{modele}.
Exemple :
[(#MODELE{modele, p1=truc, p2=chose, p3=etc}|filtre...)] 
Note : c'est équivalent à une inclusion (statique) de squelette également permise par la balise #INCLURE. Cet inclusion étant statique (= stockée en cache) on veillera à ne pas mettre d'éléments dynamiques dans un modèle, en particulier pas de balises #FORMULAIRE_XYZ.
Les modèles par défaut

SPIP est livré avec les modèles suivants :
- img, doc, emb,
- article_mots et article_traductions, qui donnent respectivement la liste des mots-clés associés à un article, et de ses traductions (raccourcis :  et , mais ces modèles sont aussi appelés par le squelette par dist/article.html) ;
- lesauteurs, qui définit le produit de la balise #LESAUTEURS, mais ne peut pas être appelé comme un raccourci ;
- et une série de modèles de pagination (voir Le système de pagination).
Les formulaires
Il est également possible d'appeler les formulaires en tant que modèles insérés dans un contenu éditorial.
Exemple :


Quelques conseils pour écrire un modèle

Il est conseillé de commencer par réfléchir à la syntaxe que l'on veut adopter : ce modèle est-il lié à un article précis ? Si oui, on partira sur un .
Une fois cette syntaxe établie, on crée le fichier modeles/article_xxx.html, et on y entre simplement la balise suivante : #ENV. Puis, dans un article de test, on tape notre raccourci  ; on voit alors (sous une forme un peu cryptique, il s'agit d'un tableau sérialisé) l'environnement tel qu'il est passé au modèle. On peut par exemple y distinguer notre identifiant d'article (sous le nom #ENV{id} et #ENV{id_article}).
Ensuite on peut commencer à entrer le squelette de notre fragment de page :
 
ou
 
. Et c'est parti...
Pour que notre modèle soit complet, il faut essayer les syntaxes  et [->www.spip.net].
Dans le premier cas, c'est le paramètre align=left qui est passé au modèle (et il est souhaitable que le modèle s'aligne alors du côté demandé).
Dans le second cas, le lien est passé dans un paramètre lien=http://www.spip.net, et la classe du lien dans lien_class=spip_out. Il est recommandé de prendre en compte l'url demandée, en la transformant en lien, quelque part dans le modèle (par exemple sur le titre ou l'icone) ; dans ce cas, il faut ajouter dans la première balise HTML du modèle une class="spip_lien_ok", qui signalera au gestionnaire de modèle que le lien a été pris en compte (faute de quoi le gestionnaire ajoutera un ... autour du modèle produit.
En ce qui concerne les paramètres, la balise #ENV{x} a été conçue de manière à éviter toute injection de HTML ou de javascript non désirée. Dans un modèle, on peut souhaiter autoriser le HTML dans les paramètres : il faut alors utiliser #ENV*{x} pour récupérer les données, et éventuellement les filtrer par |propre ou |typo, selon le type de données (texte pouvant comporter plusieurs paragraphes, ou simple ligne de texte).
Sur le plan de la programmation, il est recommandé de concevoir ses modèles tout en boucles, sans aucun code php ni balise dynamique. A noter toutefois : dans un modèle comportant du php, c'est le résultat du calcul qui est mis en cache, et non le script lui-même (comme c'est le cas avec les squelettes).
Voir aussi
  d'autres squelettes
 La balise #ENV

Lors du déploiement de SPIP 4.0, un gros travail a été fait sur les documents et logos. Retrouver les explications détaillées des changements ici :
 la refonte des documents dans l'annonce de la release de SPIP 4.0
 le commit PHP qui introduit et documente cette refonte des modèles de document

		
		
[1] Si l'on préfère que le raccourci s'appelle , on nommera le modèle modeles/img_timbre.html.



Le système de pagination
Fil, François Schreuer, James, Maïeul — 2006-07-01T08:06:14Z
Lorsqu'une boucle renvoie plusieurs dizaines d'articles (ou, pour une pétition, plusieurs milliers de signatures), il n'est pas souhaitable, voire impossible, de tout afficher sur une seule page.
		
Sommaire
 Syntaxe de base
 Ancres de pagination
 Accès direct à un élément particulier
 Le nombre total de résultats
 Changer le pas de la {pagination}
 La pagination dans les squelettes inclus
 Styles de la pagination
 Choisir le modèle de pagination
 Personnaliser le modèle de pagination
La pagination permet de répartir des résultats trop nombreux sur plusieurs pages.
SPIP propose donc un système simplifié de pagination des résultats d'une boucle.
Syntaxe de base
Au plus simple, ce système est composé d'un critère et d'une balise :
 le critère {pagination} s'ajoute sur la boucle à paginer ;
 la balise #PAGINATION, placée dans une des parties optionnelles (« avant » ou « après ») de la boucle, affiche la « pagination ».
 [(#PAGINATION)
]   #TITRE
  
  
Si le site comporte 90 articles publiés, cette boucle affichera la liste des dix plus anciens articles, surplombée de liens conduisant vers la page qui affiche les dix suivants, les dix d'après, etc. Ces liens sont numérotés comme suit :
0 | 10 | 20 | 30 | 40 | 50 | 60 | 70 | 80 | ...

Le numéro à partir duquel les résultats sont affichés est passé dans l'url via un paramètre {debut_page=x} portant le même nom (ici, « page ») que la boucle concernée. (Ce paramètre est exploitable dans une autre boucle via le critère classique {debut_page,10}.)
A noter : le nombre total de liens affichés est limité ; des points de suspension permettent, le cas échéant, d'aller directement à la toute fin de la liste, ou de revenir au tout-début.

Ancres de pagination
La balise #PAGINATION comporte une ancre HTML qui permet au navigateur d'afficher directement la partie de la page qui est paginée ; toutefois si l'on veut mettre les liens de pagination en dessous de la liste des articles, il faut pouvoir placer l'ancre au-dessus de la liste.
C'est à cela que sert la balise #ANCRE_PAGINATION, qui retourne l'ancre en question, et interdit à la balise #PAGINATION suivante d'afficher son ancre.
 #ANCRE_PAGINATION   #TITRE
  
 [(#PAGINATION)
]  
Inversement, pour ne pas ancrer, on précisera [(#ANCRE_PAGINATION|vide)] dans la boucle.

Accès direct à un élément particulier
Pour permettre de donner une URL permanente vers un élément précis d'une liste paginée on utilisera &debut_abc=@xxx où « abc » est le nom de la boucle de pagination et « xxx » l'id de l'objet dans la table sur laquelle porte la pagination.
Exemple : Dans une boucle
 [(#PAGINATION)
]   #ID_ARTICLE : #TITRE
  
  
&debut_pagi=10 place la pagination sur la deuxième page (à partir du dixième élément de la liste)
&debut_pagi=@231 place la pagination sur la page qui contient l'id_article « 231 ».

Le nombre total de résultats
Dans une boucle avec le critère {pagination}, #TOTAL_BOUCLE affiche le nombre d'éléments effectivement retournés, c'est-à-dire 10 sur les pages pleines, et 10 ou moins sur la dernière page de résultats.
Pour afficher le nombre d'éléments qui auraient été retournés si le critère {pagination} n'avait pas été là, utilisez la balise #GRAND_TOTAL.
 #ANCRE_PAGINATION  #TITRE 
  Il y a au total #GRAND_TOTAL articles, cette page en affiche #TOTAL_BOUCLE  
indiquera : « Il y a au total 1578 articles, cette page en affiche 10. »

Changer le pas de la {pagination}
Le nombre standard de 10 éléments par page peut être modifié par un paramètre supplémentaire dans le critère.
Ainsi
 #TITRE
  
retournera les titres de cinq articles à partir de debut_page.
Le paramètre en question peut lui-même être composé comme on le souhaite à partir d'autres balises, notamment #ENV{xx}, ce qui permet de faire un affichage à la demande très complet.
 La pagination dans les squelettes inclus
Si votre pagination doit fonctionner dans un squelette inclus, vous devez passer en paramètre de la commande INCLURE la formulation {ajax, env} ; ceci permet au squelette inclus de se calculer avec la bonne valeur du paramètre debut_xxx, et se justifie qui plus est par un besoin de sécurité (la balise #PAGINATION est en effet calculée à partir de l'URL complète de la page).


Nommer le critère de pagination
Lorsque l'on utilise des squelettes inclus plusieurs fois dans la même page comme :
   
et que cet INCLURE possède une pagination (d'où l'utilisation du critère {env}), lorsque vous cliquerez sur une pagination, vous verrez toutes les paginations se modifier en même temps.
Pour éviter cela, il suffit de nommer le critère pagination à l'intérieur du fichier inclu par un nom qui sera différent à chaque inclusion :
 #ANCRE_PAGINATION  #TITRE
  [(#PAGINATION)
]  
On peut aussi vouloir spécifier dès l'appel de l'INCLURE le nom que l'on veut donner au critère pagination :
  
dans page_paginee.html :
 #ANCRE_PAGINATION  #TITRE
  [(#PAGINATION)
]  
Styles de la pagination
La pagination est constituée d'une série de liens, et d'un numéro de page correspondant à la page actuelle doté de la class « .on » : on définira donc les styles pour a et .on pour en personnaliser l'apparence.
Choisir le modèle de pagination
La balise #PAGINATION accepte un paramètre {modele}, qui permet de modifier le résultat de la balise.
#PAGINATION{precedent_suivant} affichera des liens vers les pages précédentes et suivantes. Les liens seront les suivants
page précédente | page suivante

#PAGINATION{page} affichera quelque chose de la forme suivante
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | ...

#PAGINATION{page_precedent_suivant} affichera quelque chose comme
page précédente 1 | 2 | 3	| 4 | 5 | 6 | page suivante

#PAGINATION{prive} affichera quelque chose comme
0 | 10 | 20 | 30  | Tout afficher

Il est possible de définir d'autres modèles de pagination dans le dossiers modeles/ de votre jeu de squelettes. Ils devront s'appeler pagination_nomdumodele. On pourra, pour les fabriquer, s'inspirer de ceux livrés de base avec SPIP et situés dans le répertoire prive/modeles/
Personnaliser le modèle de pagination
Chaque modèle possède des paramètres qu'il est possible de personnaliser.
Par exemple, #PAGINATION{page_precedent_suivant} affiche par défaut :
page précédente 1 | 2 | 3	| 4 | 5 | 6 | page suivante

#PAGINATION{page_precedent_suivant, label_precedent=<, label_suivant=>} affiche :
< 1 | 2 | 3	| 4 | 5 | 6 | >

Configurer l'adresse des liens de #PAGINATION
À partir de SPIP 3.2.8, il devient possible de spécifier quelle URL doit servir de base pour les liens générés par la balise #PAGINATION.
Par exemple, cela permet, si nécessaire, de nettoyer une variable d'URL indésirable : 

#PAGINATION{prive,self=#SELF|parametre_url{...}}
Configurer le nombre de liens 
Depuis SPIP 4.0, les différents modèles de pagination acceptent un paramètre nombre_liens_max qui, passé a la balise #PAGINATION permet de définir le nombre de lien de pagination maximum affiché par le modèle. On peut également employer la constante _PAGINATION_NOMBRE_LIENS_MAX.
Définir un nouveau modèle de pagination
Il est possible de surcharger un modèle de pagination existant ou d'en définir un nouveau dans le dossier modeles de votre squelette ou plugin. Pour cela, créez le fichier de ce nouveau modèle avec le nom désiré. Ainsi le modèle legere.html, vous permet d'utiliser #PAGINATION{legere} dans vos squelettes.
Les modèles de paginations reçoivent des variables d'environnement dont ils peuvent faire usage : page_courante, nombre_pages, bloc_ancre. Ils peuvent aussi utiliser le filtre |bornes_pagination qui renvoie les bornes de la pagination créée.

Pour vous faciliter la tâche, vous pouvez commencer en reprenant le code d'un modèle de pagination livré avec SPIP et l'adapter à vos besoins.
Ne pas enregistrer dans l'historique du navigateur
Il faut pour cela associer la classe CSS nohistory au lien ajax (voir `ajax` pour les `inclure`) :
[ (#PAGINATION{precedent_suivant}|replace{lien_pagination,lien_pagination nohistory}) 
] 


La syndication de contenus
Fil — 2006-07-01T01:48:19Z
Le système de syndication (voir l'article « Les fichiers backend ») s'enrichit : il est désormais possible d'échanger l'adresse des documents joints aux articles (podcasting), de transporter d'un site à l'autre les mots-clés (tags) associés aux articles ainsi que leur rubrique (ou catégorie). On peut aussi, si on le désire, syndiquer le contenu intégral des articles.
		
Sommaire
 Référencement rapide du site
 Décider ce que l'on veut émettre
 Décider ce que l'on veut récupérer
 Décider ce que l'on veut afficher
 Manipuler le contenu HTML des articles syndiqués
 Références
Dans tout ce qui suit, on considère que le flux de syndication offert par le site source est suffisamment riche pour avoir prévu toutes les possibilités qu'offre notamment le squelette dist/backend.html de SPIP.
Référencement rapide du site
On repère d'abord sur le site source l'URL de son flux de syndication au format RSS (ou Atom). Selon les cas, cette adresse est indiquée directement sur la page, et/ou est « découverte » automatiquement par le navigateur, qui affiche alors une icône caractéristique. Si les squelettes du site source le prévoient, SPIP peut aussi découvrir cette adresse de syndication, et il suffit d'indiquer l'adresse du site pour se voir proposer de le syndiquer.
Une fois la syndication activée, les articles présents dans le flux de syndication du site source sont repris sur le site récepteur.
Décider ce que l'on veut émettre
Le webmestre du site source peut décider de ce qu'il met dans son flux RSS : ce choix peut bien évidemment se faire en modifiant le squelette dist/backend.html, ou en s'en inspirant pour créer un nouveau flux.
Mais la page de configuration dans l'espace privé propose une option très importante pour la syndication : elle permet de décider si le flux RSS du site comportera l'intégralité du contenu des articles, au format HTML, ou seulement un petit résumé (au format texte). Dans le premier cas (qui est la configuration par défaut du système), les articles récents du site sont entièrement lisibles avec un lecteur RSS : ils sont aussi entièrement « recopiables » d'un site à l'autre. Cela permet par exemple de réaliser automatiquement des sites miroirs, ou des sites composés d'un contenu produit sur d'autres sites.
Décider ce que l'on veut récupérer
Si le site source ne diffuse pas son contenu intégral, il est bien évident que la syndication ne pourra pas en récupérer plus. Mais dans le cas d'une diffusion intégrale, SPIP peut récupérer ce contenu HTML et l'afficher, images comprises.
Site par site, on peut choisir ce que l'on veut récupérer par la syndication : le contenu HTML des articles (issu de l'entrée  du flux RSS, si elle y est présente) ou un simple résumé au format texte (trouvé dans l'entrée  ou 
 du flux rss).
On peut également décider de ce que l'on fait des articles qui disparaissent des flux (qui sont en général limités aux 15 articles les plus récents du site) : on peut décider que SPIP les élimine de la base de données (après une période de deux mois), et/ou les passe immédiatement en mode « refusé ». Ces dernières options permettent par exemple de gérer un portail sur des flux très rapides (agences de presse, tags très populaires de sites de photographie, etc) ; ou encore de maintenir un miroir fidèle d'un site (en éliminant les articles qui seraient dépubliés).
SPIP considère que si la date d'un élément de flux RSS est « très vieux » (plus d'un an) ou trop loin dans le futur (plus de 48 heures), c'est qu'il s'agit probablement d'une erreur. Il inscrit donc la date du jour à la place de celle qu'il a trouvé. On pourrait avoir besoin, cependant, de syndiquer des informations qui, à dessein, fournissent une date située à plus de 2 jours dans le futur. Par exemple, on peut se servir de fils RSS pour annoncer des évènements qui auront lieu dans le futur.
Pour syndiquer ses rendez-vous via le flux RSS dédié, une variable de personnalisation nommée $controler_dates_rss, qui vaut vrai par défaut.
Pour cela, dans votre fichier config/mes_options.php, ajouter la ligne
$GLOBALS['controler_dates_rss'] = false; 
le test n'est plus effectué et les dates du futur, ou du « lointain » passé, seront bien prises en compte.
Décider ce que l'on veut afficher
La boucle SITES permet de parcourir les sites syndiqués, tandis que la boucle SYNDIC_ARTICLES permet de récupérer les champs descriptifs des articles fournis par l'un des sites syndiqués
- la source : 
De manière habituelle, #NOM_SITE représente le nom du site syndiqué, qui est donc la « source » de l'article. Cependant avec le développement des agrégateurs de contenu (les portails par exemple), la véritable source de l'article peut être un autre site. Le format RSS a prévu ce cas en définissant un champ  indiquant la véritable source de l'article. Le moteur de syndication de SPIP récupère ces données quand elles sont présentes, et les balises #SOURCE et #URL_SOURCE permettent d'afficher respectivement le nom et l'adresse de la source.
- les tags : 
Si les mots-clés affectés aux articles sont correctement renseignés dans le flux RSS, ils sont récupérés par le site récepteur ; ils n'arrivent pas individuellement dans la table des mots-clés, mais sont stockés en vrac dans le champ tags de la table spip_syndic_articles.
Si le flux de syndication utilise la notation standard Tag, le tag est noté tel quel. SPIP pousse cette notion un peu plus loin en transmettant aussi l'adresse de la page du mot-clé, grâce aux microformats. Le tag est alors récupéré avec son lien, sous la forme :

Mot-clé.
Sur le site destinataire, ces tags sont affichés dans l'espace privé sous le descriptif de l'article, et sont affichables sur le site public grâce à la balise #TAGS (on verra plus loin comment la filtrer pour faire un affichage sélectif des tags).
Note : SPIP prévoit une gestion spécifique des tags en provenance du site flickr (photographie) de manière à pouvoir leur attribuer un URL qui n'est pas prévu dans son flux RSS.
- la rubrique :
Dans de nombreuses applications (systèmes de blogs, répertoire de liens...) la catégorie (ou encore directory) d'un article est l'équivalent de ce que SPIP appelle la rubrique. Il était donc naturel d'utiliser la notion RSS standard de ... pour faire connaître l'appartenance de notre article à telle ou telle rubrique.
De même qu'avec les tags, SPIP récupère cette information et l'affiche via #TAGS.
- les documents joints :
Les documents qui, dans l'espace privé, figurent en bas de la page de visualisation d'un article, soit dans la section « Documents » soit, pour les images, dans la section « Portfolio », sont eux aussi transmis dans le flux RSS, en utilisant la notion . C'est ce qu'on appelle le podcasting, désormais une fonction standard de SPIP [1].
L'information sur les enclosures est elle aussi récupérée dans la balise #TAGS, mais elle est affichée de façon différenciée dans l'espace privée, sous forme d'un petit trombone pour chaque fichier.
Utiliser la balise #TAGS
Comme on l'a vu ci-dessus, la balise #TAGS affiche en vrac les liens vers les mots-clés, la rubrique et les documents joints. Mais par la grâce des microformats, les liens vers chacun de ces concepts sont « marqués » de la façon suivante :

-  pour les tags/mots-clés

-  pour la rubrique/catégorie

-  pour les documents joints/podcast

Si l'on veut n'afficher que l'un de ces types de tags, on utilisera le filtre afficher_tags en précisant le type souhaité en argument :
[(#TAGS|afficher_tags{directory})] 
[(#TAGS|afficher_tags{tag})] 
[(#TAGS|afficher_tags{enclosure})] 
Par défaut [(#TAGS|afficher_tags)] est équivalent à [(#TAGS|afficher_tags{'tag,directory'})].
Pour les documents joints, le filtre spécifique afficher_enclosures permet d'afficher les trombones plutôt que des liens classiques :
[(#TAGS|afficher_enclosures)] 
Manipuler le contenu HTML des articles syndiqués
Cas pratique : notre site syndique un photoblog, qui diffuse systématiquement un petit commentaire suivi de la photographie. Cette dernière se présente sous la forme d'une balise HTML . Une fois ce photoblog syndiqué en version HTML complète dans notre site, nous pouvons décider de n'afficher que la photo, sans le commentaire. Il nous faut alors extraire la balise  ; cela peut se réaliser grâce au filtre extraire_balise{xxx}, qui récupère la première balise HTML  d'un contenu.
A partir de là tout est possible :
[(#DESCRIPTIF|extraire_balise{img})] 
…affiche la photo ;
[(#DESCRIPTIF|extraire_balise{img}|extraire_attribut{src})] 
…son URL ;
[(#DESCRIPTIF|extraire_balise{img}|extraire_attribut{width})] 
…sa largeur ;
On peut même en modifier le style avec, par exemple :
[(#DESCRIPTIF|extraire_balise{img}|inserer_attribut{style,'border: double red 4px;'})] 

Remarque : les contenus HTML provenant d'un site extérieur sont par définition considérés comme « non contrôlés », et donc potentiellement problématiques s'ils contiennent des balises mal fermées, ou du javascript ; SPIP leur applique donc systématiquement le filtre safehtml avant affichage.

Autres filtres liés à la syndication
Ces filtres permettent de convertir les tags de syndication d'un format à un autre, afin de pouvoir par exemple remettre au format RSS des « tags » récupérés par syndication, et enregistrés dans notre base de données sous forme de microformats : tags2dcsubject, enclosure2microformat, microformat2enclosure.
Références
- microformats

- rel=tag

- rel=enclosure

- rel=directory
		
		
[1] Attention les fichiers eux-mêmes ne sont pas recopiés : seules leur URL et les données associées (titre, taille, format) sont récupérées. Par ailleurs il faut signaler, pour les puristes, qu'on prend ici quelque liberté avec la norme RSS, qui interdit normalement d'avoir plusieurs enclosures dans un même article.

SPIP

|set

Sommaire

Exemples

Voir aussi

|debug

Les itérateurs de SPIP - la boucle (DATA)

Sommaire

Syntaxe et formats de la boucle (DATA)

Filtrage, tri, pagination, fusion

Le critère {liste ...}

Le critère {enum ...}

Protection des données manipulées par les itérateurs

Exemples de `BOUCLE(DATA)`

Sommaire

Boucler sur un tableau

Lister les plugins actifs

Filtrer les données avec {cle==...}

Lister le contenu d'un répertoire

Lister des fichiers correspondant à un masque

Lire un fichier CSV

Un document Google (spreadsheet)

Une page HTML

Un webservice au format YAML

Le critère {datapath ...}

Une API en json

Un fichier XML

Utiliser un webservice comme YQL — Yahoo Query Language)

Les Itérateurs PHP

Un calendrier au format iCalendar/ics

#DOUBLONS

Écran de sécurité

Sommaire

Philosophie

Téléchargement

Installation

Configuration

Fonctionnement de l'écran

Vérification et test

#AUTORISER

Sommaire

Voir aussi

Utiliser les modèles

Sommaire

Des usages multiples

En pratique

Des paramètres à foison

Un emploi possible dans les squelettes

Les modèles par défaut

Quelques conseils pour écrire un modèle

Voir aussi

Le système de pagination

Sommaire

Syntaxe de base

Ancres de pagination

Accès direct à un élément particulier

Le nombre total de résultats

Changer le pas de la {pagination}

La pagination dans les squelettes inclus

Styles de la pagination

Choisir le modèle de pagination

Personnaliser le modèle de pagination

La syndication de contenus

Sommaire

Référencement rapide du site

Décider ce que l'on veut émettre

Décider ce que l'on veut récupérer

Décider ce que l'on veut afficher

Manipuler le contenu HTML des articles syndiqués

Références

Syntaxe et formats de la boucle `(DATA)`

Le critère `{liste ...}`

Le critère `{enum ...}`

Lister les `plugins` actifs

Filtrer les données avec `{cle==...}`

Le critère `{datapath ...}`

`Fonctionnement de l'écran`

`Vérification et test`

`Des paramètres à foison`

`Un emploi possible dans les squelettes`

`Les modèles par défaut`

`Quelques conseils pour écrire un modèle`

`Voir aussi`

Changer le pas de la `{pagination}`