SPIP

#ID_LOGO_XXX

RealET — 2023-11-22T07:59:21Z

Sommaire

Syntaxe

Le type d'objet est spécifié dans le nom de la balise, tel que #ID_LOGO_ARTICLE ou #ID_LOGO_SITE.

Pour les articles, ces balises ont quelques variantes :

La balise peut aussi demander explicitement le logo normal ou de survol, avec #ID_LOGO_ARTICLE_NORMAL ou #ID_LOGO_ARTICLE_SURVOL.
On peut demander un logo de rubrique en absence de logo sur l'article demandé avec #ID_LOGO_ARTICLE_RUBRIQUE

Usage pour récupérer les informations du logo

Une fois l'identifiant du logo récupéré, une boucle DOCUMENTS peut être utilisée, entre autres, pour récupérer le titre et le descriptif du logo (attention, il faut le modificateur {tout}, sinon, la boucle ne retourne rien) :

Exemple :

 #TITRE, #DESCRIPTIF

Attention, piège avec #INFO_TITRE

#INFO_TITRE{document, #ID_LOGO_ARTICLE} renvoie le titre du document si renseigné, sinon le nom du fichier [1].

_MOTS_CREATION_RETOUR_MOT_CREE

RealET — 2018-09-01T09:13:39Z

La constante _MOTS_CREATION_RETOUR_MOT_CREE permet de changer le comportement de SPIP à la création d'un mot clé : avec cette constante, on arrive sur la page des propriétés du mot nouvellement créé [1].

Il est possible de personnaliser cette valeur dans votre fichier config/mes_options.php (voir l'article qui lui est consacré).

Exemple :

// Revenir à la page de propriétés du mot après sa création if (!defined('_MOTS_CREATION_RETOUR_MOT_CREE')) define('_MOTS_CREATION_RETOUR_MOT_CREE', true);

[1] Par défaut, SPIP a un comportement dérogatoire pour la création des mots clé : alors que les autres objets de SPIP font arriver sur la page des propriétés de l'objet nouvellement créé, dans le cas des mots clés, SPIP ramène à la page qui contenait le bouton de création (soit la page listant tous les groupes de mots, soit la page du groupe)

Cette constante est disponible à partir de SPIP 3.1.9 et SPIP 3.2.2

_CNIL_PERIODE

RealET — 2010-09-08T16:54:28Z

Les adresses IP stockées dans la table « spip_forum » sont encryptées de manière non réversible (algorithme MD5) au bout de 4 mois.

Il est possible de modifier le délai avant cryptage des IPs (4 mois par défaut) en définissant cette constante dans votre fichier config/mes_options.php (voir l'article qui lui est consacré).

Par exemple :

// crypter les IP au bout de 2 mois define('_CNIL_PERIODE', 3600*24*31*2);

Pour que SPIP ne crypte jamais les IP vous pouvez définir cette constante à zéro :

// ne jamais crypter les IP define('_CNIL_PERIODE', 0);

Ce cryptage s'appuie sur l'article 226-20 du code pénal français et les bonnes pratiques éditées par la CNIL.

_DIR_PLUGINS_AUTO

RealET — 2010-04-22T14:13:55Z

_DIR_PLUGINS_AUTO définit l'emplacement du dossier qui contiendra les plugins installables par le mécanisme de téléchargement de plugins intégré à SPIP.

_DIR_PLUGINS_AUTO est une chaîne de caractères correspondant à un chemin relatif à partir de la racine de SPIP.

Il est possible de définir cette constante dans votre fichier config/mes_options.php (voir l'article qui lui est consacré).

Définir cette constante à la valeur '' (chaîne vide) permet de désactiver complètement la fonctionnalité d'installation automatique.

Exemple :

// Désactiver l'installation par téléchargement depuis l'administration de SPIP define('_DIR_PLUGINS_AUTO', '');

Par défaut, cette constante vaut :

define('_DIR_PLUGINS_AUTO', _DIR_PLUGINS.'auto/');

C'est à dire : le sous-dossier « auto/ » dans le dossier « plugins/ »

Voir aussi :
- _DIR_PLUGINS_SUPPL

Formulaires CVT par l'exemple

cerdic, RealET — 2008-12-16T09:45:17Z

Sommaire

Étape 1 : Créer le squelette de son formulaire

Dans le sous-répertoire formulaires/ de votre dossier « squelettes », créez le fichier contact.html qui va contenir le code HTML de votre formulaire de contact. Par exemple :

 #ACTION_FORMULAIRE{#ENV{action}} Votre email  
 Votre message #ENV{message}

Comme vous pouvez le constater, ce formulaire ne contient que quelques particularités :

l'attribut action de la balise
contient #ENV{action} qui est l'URL sur laquelle le formulaire sera envoyé ;
#ACTION_FORMULAIRE{#ENV{action}} indique à SPIP de transmettre aux fonctions « charger, verifier, traiter » les données saisies et celles contenues éventuellement dans l'URL (depuis SPIP 2.1 l'argument #ENV{action} est en fait inutile, étant à présent la valeur par défaut) ;
chaque input, textarea ou select contient la valeur #ENV{xxx} où xxx correspond à l'attribut name correspondant.

À ce stade, vous pouvez déjà afficher ce formulaire dans un squelette, avec la balise #FORMULAIRE_CONTACT ou directement dans le texte d'un article avec le code . Vous apprécierez de pouvoir tester et affiner le rendu et le contenu de votre formulaire sans écrire une seule ligne de PHP.

Toutefois, si vous saisissez du texte et cliquez sur le bouton OK, votre formulaire ne fait rien, et vous ne retrouvez pas votre saisie.

Étape 2 : la fonction charger

Nous allons donc maintenant indiquer à SPIP quels sont les champs que l'internaute peut remplir.

Créez pour cela un fichier contact.php dans le sous-répertoire formulaires/ (juste à côté de votre squelette contact.html, donc), et mettez-y le code suivant :

'','message'=>''); return $valeurs; } ?>

Que fait ce code ?

Il déclare la fonction charger du formulaire contact du répertoire formulaires consécutivement nommée formulaires_contact_charger.
Le suffixe _dist signale qu'il s'agit de la fonction charger par défaut de ce formulaire, mais qu'elle est éventuellement personnalisable (voir au sujet des surcharges http://programmer.spip.org/Surcharg...).

Cette fonction liste, dans la variable $valeurs, les champs de saisie de votre formulaire et, pour chaque champ, la valeur initiale par défaut.
La fonction formulaires_contact_charger_dist renvoie donc cette liste de champs.

Testez à nouveau votre formulaire : si vous remplissez les champs et validez avec le bouton OK, vous verrez que cette fois-ci le formulaire n'a pas perdu les valeurs que vous avez saisies (même s'il ne fait toujours rien).

Dans cet exemple, tous les champs sont vides par défaut. Nous pourrions améliorer notre fonction en remplissant automatiquement l'email lorsque le visiteur est identifié.
Cela nous donnerait le code suivant pour la fonction charger :

function formulaires_contact_charger_dist(){ $valeurs = array('email'=>'','message'=>''); if (isset($GLOBALS['visiteur_session']['email'])) $valeurs['email'] = $GLOBALS['visiteur_session']['email']; return $valeurs; }

Si vous testez maintenant votre formulaire, en étant identifié, vous constaterez :

que le champ email est déjà rempli avec l'email de votre compte SPIP
que les valeurs saisies ou modifiées sont conservées telles quelles après validation

Étape 3 : Vérifier que la saisie est correcte

Avant de prendre en compte les valeurs saisies par l'internaute nous devons bien évidemment vérifier que ce qu'il nous envoie est correct.

Nous allons, par exemple, définir les contraintes suivantes :

les champs email et message sont obligatoires
l'email doit être valide

Pour vérifier la saisie, nous allons créer la fonction formulaires_contact_verifier_dist (sur le même modèle que la fonction charger) toujours dans le même fichier contact.php :

function formulaires_contact_verifier_dist(){ $erreurs = array(); // verifier que les champs obligatoires sont bien la : foreach(array('email','message') as $obligatoire) if (!_request($obligatoire)) $erreurs[$obligatoire] = 'Ce champ est obligatoire'; // verifier que si un email a été saisi, il est bien valide : include_spip('inc/filtres'); if (_request('email') AND !email_valide(_request('email'))) $erreurs['email'] = 'Cet email n\'est pas valide'; if (count($erreurs)) $erreurs['message_erreur'] = 'Votre saisie contient des erreurs !'; return $erreurs; }

Remarque : l'utilisation de _request() est expliquée sur le site programmer.spip.org

La fonction verifier renvoie une liste de champs en erreurs, avec le message d'erreur correspondant à chaque champ.

À ce stade, vous ne verrez aucune différence si vous testez le formulaire : en effet, votre formulaire contact.html n'affiche pas les erreurs. Vous allez donc le compléter comme suit :

[(#ENV*{message_erreur})
]  #ACTION_FORMULAIRE{#ENV{action}} Votre email [(#ENV**{erreurs}|table_valeur{email})]  
 Votre message [(#ENV**{erreurs}|table_valeur{message})] #ENV{message}

Notez bien :

l'affichage d'un message d'erreur général renvoyé par la fonction verifier
[(#ENV*{message_erreur}) ]
les messages d'erreur devant chaque champ :
[(#ENV**{erreurs}|table_valeur{email})]

Vous pouvez maintenant tester votre formulaire en saisissant un email erroné ou en laissant un champ vide : votre formulaire commence déjà à interagir avec l'internaute !

Étape 4 : traiter !

Lorsque la fonction verifier ne renvoie aucune erreur, SPIP appelle automatiquement la fonction traiter correspondante. Déclarons cette fonction formulaires_contact_traiter_dist (toujours dans le fichier contact.php) et faisons-lui envoyer un mail au webmestre :

function formulaires_contact_traiter_dist(){ $envoyer_mail = charger_fonction('envoyer_mail','inc'); $email_to = $GLOBALS['meta']['email_webmaster']; $email_from = _request('email'); $sujet = 'Formulaire de contact'; $message = _request('message'); $envoyer_mail($email_to,$sujet,$message,$email_from); return array('message_ok'=>'Votre message a bien été pris en compte. Vous recevrez prochainement une réponse !'); }

Vous remarquerez que la fonction traiter ne fait aucune vérification : elles ont toutes été faites au préalable (dans la fonction verifier). Si la fonction traiter est appelée c'est qu'il n'y a aucune erreur.

La fonction traiter renvoie un message de succès, « message_ok », contenu dans un tableau. Comme pour les messages d'erreur, il faut compléter notre formulaire pour qu'il affiche ce message. Comme suit :

[(#ENV*{message_ok})
] [(#ENV*{message_erreur})
] [(#EDITABLE|oui)  #ACTION_FORMULAIRE{#ENV{action}} Votre email [(#ENV**{erreurs}|table_valeur{email})]  
 Votre message [(#ENV**{erreurs}|table_valeur{message})] #ENV{message}  
 ]

Notez bien :

l'affichage d'un message de succès au début
[(#ENV*{message_ok}) ]
l'affichage conditionnel du formulaire de saisie en fonction de #EDITABLE : après la saisie, il est en général plus clair pour l'internaute de ne pas réafficher le formulaire complet mais juste le message de succès. #EDITABLE sert à cela.

Astuce : Il arrive parfois que l'on veuille placer une BOUCLE dans le formulaire (pour proposer les champs d'un select depuis la base par exemple). L'utilisation de #EDITABLE et de cette boucle provoque une erreur. La solution est d'y ajouter une boucle CONDITION comme le montre l'exemple ci-après :

 [(#ENV*{message_ok})
] [(#ENV*{message_erreur})
]   #ACTION_FORMULAIRE{#ENV{action}} #TITRE Votre email [(#ENV**{erreurs}|table_valeur{email})]  
 Votre message [(#ENV**{erreurs}|table_valeur{message})] #ENV{message}

C'est fini ! Vous pouvez utiliser votre formulaire de contact.

Le bonus : des formulaires ajax simplifiés

Vous souhaitez que l'interaction entre votre formulaire et l'internaute soit plus rapide et ne passe pas par le rechargement complet de la page à chaque erreur ou lors de la validation ?

Il faut que votre formulaire soit implémenté en AJAX. D'habitude c'est là que se situe la difficulté, ce type d'implémentation étant souvent long et laborieux. Mais c'est simplifié dans SPIP, par le formalisme CVT, qui vous fait bénéficier de mécanismes automatisés, dont l'ajaxisation de vos formulaires.

Pour cela, il suffit de placer votre formulaire dans une div dotée de la class ajax :

 #FORMULAIRE_CONTACT

Et le tour est joué !

Pour aller plus loin

- Cet exemple simple ne produit pas un joli formulaire. Pour un résultat plus esthétique, sémantique et accessible, n'hésitez pas à utiliser les recommandations de structures de Structure HTML des formulaires de SPIP pour tous vos formulaires SPIP
- Tout savoir sur la fonction charger() : La fonction charger() des formulaires CVT
- Tout savoir sur la fonction verifier() : La fonction verifier() des formulaires CVT
- Tout savoir sur la fonction traiter() : La fonction traiter() des formulaires CVT

`{ajax}` pour les `inclure`

cam.lafit, cerdic, JLuc, RealET — 2008-12-16T09:22:41Z

Le critère {ajax} permet de cliquer sur un lien et de ne rafraichir dans la page que la zone qui changerait si on ré-affichait toute la page avec les nouveaux paramètres.

Sommaire

En pratique

Le principe est de rendre AJAX abordable car la complexité est cachée :

J'ai un morceau de page qui contient des liens vers cette même page et
ne provoquent de changement que dans le morceau de page considéré :

je mets ce morceau de page dans un squelette séparé
je marque les liens concernés par la class ajax : ...
j'inclus mon squelette dans la page principale avec
ou
#INCLURE{fond=monskel,ajax,env}

Et c'est tout !

Quelques petites précisions tout de même :

testez toujours d'abord votre squelette sans l'argument {ajax} ;
{ajax} devrait toujours être accompagné de {env} afin d'éviter tout risque d'injection d'urls dans le cache de SPIP ;
par defaut, les liens a contenus dans une classe pagination sont aussi ajaxés ;
il est possible de cibler d'autres liens en spécifiant leurs sélecteurs CSS jquery dans la variable javascript ajaxbloc_selecteur. Exemple : var ajaxbloc_selecteur = 'a.ajax, a.uneautreclasse'; ;
il faut bien entendu que #INSERT_HEAD figure dans le head du squelette de la page, et que le javascript soit activé dans le navigateur de l'internaute qui la consulte.

En détail

Syntaxe d'appel :

[(#INCLURE{fond=mon_fond,ajax,env})]

Cet appel inclut le squelette mon_fond en « ajaxant » automatiquement tous les liens ciblés par la variable js ajaxbloc_selecteur.

Un bloc

est inséré automatiquement autour du contenu du squelette inclus, pour le mécanisme de gestion de l'ajax.

Par défaut celle-ci cible les sélecteurs CSS .pagination a, a.ajax. Autrement dit, il faut avoir dans le code source des squelettes :

soit la gestion standard de la pagination par SPIP. A condition que la balise #PAGINATION soit inclue dans un élément de classe pagination. Ex : #PAGINATION
soit une classe ajax sur les liens ()

Le hit ajax relance automatiquement le calcul du squelette inclus seul en restaurant son #ENV, et en y ajoutant les paramètres passés dans l'url du lien

Le bloc rechargé passe en opacité 50 % et prend la class loading pendant le chargement ce qui permet de le styler à sa convenance.

Il est intéressant de noter que :

les liens ajax sont mis en cache dans le navigateur lorsqu'ils sont cliqués une fois. Le bloc n'est donc chargé qu'une fois, même si l'internaute revient plusieurs fois sur le lien concerné
certains liens peuvent être pré-chargés à l'avance en leur ajoutant la classe preload

Quelques exemples

Utilisation de liens ajax
Soit le squelette inc-liens.html
Il sera appelée dans le squelette incluant par

[(#INCLURE{fond=inc-liens,ajax,env})]

Et contiendra

  #NOM #ID_AUTEUR   [(#ENV{id_auteur}|oui) #ENV{id_auteur} ]

Utilisation de la pagination
Pour la pagination, prenons un exemple tiré de squelettes-dist/sommaire.html.

Mettons dans un squelette inc-recents.html la boucle qui liste les articles récents :

[(#REM) Derniers articles ]   [(#ANCRE_PAGINATION)] <:derniers_articles:>
    [(#LOGO_ARTICLE_RUBRIQUE|#URL_ARTICLE|image_reduire{150,100})] #TITRE
 [(#DATE|affdate_jourcourt)][, <:par_auteur:> (#LESAUTEURS)] [(#INTRODUCTION)
] 
  
 [(#PAGINATION)
]

Il suffit alors de mettre dans sommaire.html, à la place de cette boucle

Limites et cas particuliers

Ce mécanisme automatisé d'ajaxisation des blocs repose sur une hypothèse : par défaut, un lien ajax ne permet de rafraîchir que le bloc le contenant, en insérant la version modifiée au même endroit. À noter qu'il est possible, à partir d'un bloc, de recharger un autre bloc de la page, en utilisant la technique décrite plus bas.

Par ailleurs, il est important de noter que le calcul du squelette inclus ne doit reposer exclusivement que sur les paramètres passés en #ENV. En effet, lors du calcul du bloc ajax, celui-ci sera recalculé tout seul, en dehors du squelette appelant. Seules les variables contenues dans #ENV seront restaurées.

Ainsi, il n'est pas possible de faire référence à des variables php globales : celles-ci ne seront pas restaurées au moment du calcul du bloc ajax. Si vous vouliez vraiment utiliser des variables globales php, il faut les réinjecter dans le #ENV au moment de l'inclusion :

Modalités complémentaires

SPIP 3.0 améliore le mécanisme :

Historique de navigation

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).

#BOUTON_ACTION

Les #BOUTON_ACTION peuvent déclencher le rechargement du bloc incluant en ajax.

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, au moment de leur inclusion, de nommer les blocs ajax qui doivent pouvoir être rechargés :

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}})

Voir aussi

d'autres squelettes
Ajax dans un #BOUTON_ACTION
Documentation "Blocs-ajax-et-ajaxReload" sur programmer.spip.net
AjaxReload par l'exemple
et Exemple de bloc télécommandé en Ajax sur contrib.spip.net

SPIP

#ID_LOGO_XXX

Sommaire

Syntaxe

Usage pour récupérer les informations du logo

Attention, piège avec #INFO_TITRE

À lire aussi

_MOTS_CREATION_RETOUR_MOT_CREE

_CNIL_PERIODE

_DIR_PLUGINS_AUTO

Formulaires CVT par l'exemple

Sommaire

Étape 1 : Créer le squelette de son formulaire

Étape 2 : la fonction charger

Étape 3 : Vérifier que la saisie est correcte

Étape 4 : traiter !

Le bonus : des formulaires ajax simplifiés

Pour aller plus loin

`{ajax}` pour les `inclure`

Sommaire

En pratique

En détail

Quelques exemples

<:derniers_articles:>

#TITRE

Limites et cas particuliers

Modalités complémentaires

Rechargement télécommandé de blocs ajax

Voir aussi