Geekographie Maïeulesque

Jouons un peu avec |image_masque

Maïeul — 2012-08-13T18:04:23Z

Les lecteurs réguliers de ce site auront remarqué, outre le changement de style, que désormais les logos des articles possèdent une petite images dans le coin inférieur droit.

L'image principale correspond au logiciel dont il est question en priorité : par exemple SPIP. L'image secondaire correspond à la rubrique principale de l'article. Ainsi pour notre article, il s'agit de la rubrique Images. Enfin, dans certains cas, une image est mise dans le coin supérieur gauche : il s'agit de l'image correspondante au logiciel utilisé de manière secondaire dans l'article. Par exemple l'article "Gérer beaucoup de sites SPIP en local sous MacOsX" parle d'abord du logiciel SPIP, et ensuite du logiciel SVN. On a donc le logo de SVN en petit dans le coin supérieur gauche.

La composition de ces images est effectuée automatiquement par SPIP à partir des logos des différentes rubriques, grâce au filtre |image_masque. Cependant ce filtre manque de documentation, et j'ai du fouiller le code pour le comprendre. En attendant une documentation plus complète, voici déjà un tutoriel expliquant comment j'ai procédé dans le cas présent.

Principe

Il n'y a pas de logo sur les articles.
Les logos d'articles sont calculés à l'aide de l'arborescence de l'article :
- Le logo principal correspond au logo du secteur.
- Le logo en bas à droite correspond au logo de la rubrique
- Le logo en haut à gauche correspond au logo du premier secteur secondaire configuré avec le plugin polyhierarchie.
Comme il s'agit d'un logo, je n'ai pas jugé utile d'ajouter une balise alt autre que vide.
Nous allons faire un squelette inclure/logo-rubriques que nous appellerons via la balise #INCLURE. Ce squelette calculera le logo, pour l'afficher, sans le réduire
Le logo sera réduit au cas par cas en filtrant #INCLURE grâce à image_reduire.

Mise en œuvre

Dans notre boucle ARTICLES, à l'endroit où nous souhaitons afficher notre logo, nous mettons :

[(#INCLURE{fond=inclure/logo-rubriques,id_article}|image_reduire{xxx})]

en remplaçant xxx par la taille souhaité du logo au final.

Maintenant, il nous reste à créer notre squelette inclure/logo-rubriques.html.

Dans ce squelette, nous procéderons ainsi :

Extraction des différents logos de rubriques, et stockage dans des variables.
Calcul de la taille des logos secondaires.
Fabrication de l'image finale.

Il ne faut pas oublier de mettre une boucle englobante dans le squelette :

Tout le code qui va suivre devra se mettre dans cette rubrique. Donc, première étape :

 #SET{rubrique,#LOGO_RUBRIQUE}   #SET{secteur,#LOGO_RUBRIQUE}    #SET{autre_secteur,#LOGO_RUBRIQUE}

Commentaires :

L. 1-3 : On sélectionne le logo de la rubrique de l'article (celui qui sera affiché en bas à droite) et on le stocke dans rubrique.
L. 5-7 : On sélectionne le logo du secteur de l'article (celui qui sera affiché en gros) et on le stocke dans secteur.
L. 9-13 : On sélectionne le logo du second secteur de l'article (celui qui sera affiché en haut à gauche), et on le stocke dans autre_secteur. L'imbrication des boucles s'expliques par le fait qu'il n'est pas possible de combiner {racine} et parents_indirects.

Maintenant, nous sommes prêts pour la seconde étape : calculer les hauteurs et largeurs maximales de nos logos secondaires. En ce qui concerne la hauteur, j'ai opté pour 1/3 de l'image principale ; en ce qui concerne la largeur, j'ai opté pour 1/2.

On utilise pour cela les filtres |hauteur, |largeur pour déterminer la hauteur et la largeur de l'image principale, |div pour procéder à une division, et |floor pour arrondir à l'entier inférieur.

Cela donne donc :

#SET{largeur,#GET{secteur}|largeur|div{2}|round}

Il ne nous reste plus qu'à fabrique nos images finales. Pour ce faire nous utiliserons les filtres suivants :

|==, |non et |oui, pour vérifier la présence des différents logos.
|image_reduire qu'on ne présente plus.
|image_masque, qui peut recevoir beaucoup de paramètres en troisième argument, que la documentation ne détaille pas. Ces paramètres sont à séparer par des virgules. Dans le cas présent, ceux qui nous intéressent sont :
- mode=normal pour que l'image du dessus masque totalement l'image du dessous.
- text-align pour le positionnement horizontal.
- vertical-align pour le positionnement vertical.

Au niveau des possibilités de combinaison, nous en avons quatre possibilités :

L'article ne se trouve pas dans une rubrique à la racine. Dans ce cas il nous faut tester s'il dispose d'un secteur secondaire :
- S'il ne dispose pas de secteur secondaire, le logo final correspond au logo du secteur sur lequel on ajoute en bas à droite le logo de la rubrique (cas 1).
- S'il dispose d'un secteur secondaire, le logo final correspond au logo du secteur principal sur lequel on superpose (cas 2) :
  - Le logo de la rubrique en bas à droite.
  - Le logo du secteur secondaire en haut à gauche.
L'article se trouve dans une rubrique à la racine. Dans ce cas, nous testons s'il dispose d'un secteur secondaire :
- S'il n'en dispose pas, alors le logo correspond tout simplement au logo du secteur (cas 3).
- S'il en dispose, alors le logo correspond au logo du secteur, sur lequel on superpose le logo du secteur secondaire (cas 4).

Au final, cela donne :

[(#GET{rubrique}|=={#GET{secteur}}|non) [(#GET{autre_secteur}|non) [(#REM)] [(#GET{secteur}|image_masque{ #GET{rubrique}|image_reduire{#GET{largeur},#GET{hauteur}}, mode=normal, text-align=right, vertical-align=bottom})] ] [(#GET{autre_secteur}|oui) [(#REM)] [(#GET{secteur}|image_masque{ #GET{rubrique}|image_reduire{#GET{largeur},#GET{hauteur}}, mode=normal, text-align=right, vertical-align=bottom }|image_masque{ #GET{autre_secteur}|image_reduire{#GET{largeur},#GET{hauteur}}, mode=normal, text-align=left, vertical-align=top})] ] ] [(#GET{rubrique}|=={#GET{secteur}}|oui) [(#GET{autre_secteur}|non) [(#REM)] #GET{secteur} ] [(#GET{autre_secteur}|oui) [(#REM)] [(#GET{secteur}|image_masque{ #GET{autre_secteur}|image_reduire{#GET{largeur}, #GET{hauteur}}, mode=normal, text-align=left, vertical-align=top})] ] ]

Et donc notre squelette inclure/logos-rubriques final est :

 [(#REM)]  #SET{rubrique,#LOGO_RUBRIQUE}   #SET{secteur,#LOGO_RUBRIQUE}    #SET{autre_secteur,#LOGO_RUBRIQUE}   [(#REM)] #SET{hauteur,#GET{secteur}|hauteur|div{3}|round} #SET{largeur,#GET{secteur}|largeur|div{2}|round} [(#REM)] [(#REM)] [(#GET{rubrique}|=={#GET{secteur}}|non) [(#GET{autre_secteur}|non) [(#REM)] [(#GET{secteur}|image_masque{ #GET{rubrique}|image_reduire{#GET{largeur},#GET{hauteur}}, mode=normal, text-align=right, vertical-align=bottom})] ] [(#GET{autre_secteur}|oui) [(#REM)] [(#GET{secteur}|image_masque{ #GET{rubrique}|image_reduire{#GET{largeur},#GET{hauteur}}, mode=normal, text-align=right, vertical-align=bottom }|image_masque{ #GET{autre_secteur}|image_reduire{#GET{largeur},#GET{hauteur}}, mode=normal, text-align=left, vertical-align=top})] ] ] [(#GET{rubrique}|=={#GET{secteur}}|oui) [(#GET{autre_secteur}|non) [(#REM)] #GET{secteur} ] [(#GET{autre_secteur}|oui) [(#REM)] [(#GET{secteur}|image_masque{ #GET{autre_secteur}|image_reduire{#GET{largeur}, #GET{hauteur}}, mode=normal, text-align=left, vertical-align=top})] ] ]

Gérer le statut des articles directement depuis le site public sous SPIP 3

Maïeul — 2012-08-12T19:43:32Z

J'avais publié il y a plus d'un an et demi un article sur la manière de gérer directement le statut des articles depuis le site public.

Voici son adaptation pour SPIP 3. Comme vous pourrez le voir, le code est beaucoup plus simple.

Il suffit en effet de mettre dans son squelette, dans la boucle (ARTICLES) :

[(#AUTORISER{publier,article,#ID_ARTICLE}|oui)
#FORMULAIRE_INSTITUER_OBJET{article,#ID_ARTICLE,#SELF|parametre_url{var_mode,preview}}
]

L. 1 et 3 : On vérifie que la personne connectée à bien le droit de publier l'article en question. Voir la documentation sur #AUTORISER.
L. 2 : appel du formulaire permettant de changer le statut d'un objet. Ici on précise que l'on veut pouvoir modifier le statut d'un article, dont l'identifiant est #ID_ARTICLE Le troisième argument SELF|parametre_url{var_mode,preview} sert à ne pas tomber sur une erreur 404 si on dépublie l'article : il indique qu'après l'exécution du formulaire on retourne sur la même page, en mode previsualisation [1].

[1] Attention, cela ne fonctionne pas si l'on passe le statut à « refusé » ou « à la poubelle ».

Les différents modes d'inclusion de SPIP

Maïeul — 2012-01-26T10:25:35Z

Suite à une remarque de Tetue après mon article sur les pratiques de développements avec SPIP et à une question d'un théologien sur twitter, je fais ici un point sur les deux modes d'inclusion de squelettes dans SPIP.

Rappel : principe de l'inclusion

Inclure un squelette A dans un squelette B, c'est dire à B de reprendre le contenu du squelette A à l'endroit de l'inclusion.

L'interêt d'une telle pratique est de mettre en commun des morceaux de codes utilisés par plusieurs squelettes. Le cas le plus classique étant l'affichage du menu, mais plus le temps passe, plus le devellopeur SPIP aguerri aura tendance à multiplier les inclusions, voyant qu'il utilise beaucoup de code en commun.

Le principe des squelettes Z pousse à l'extrême cette idée d'inclusion / mutualisation du code.

Mais attention : il ne faut pas croire qu'on imite ainsi un « copier-coller » de B dans A.

Ainsi si je met dans le squelette A :

XXXXXX

et dans le squelette B

YYY

Cela ne revient pas au même que mettre dans A :

XXXYYYXXX

Pourquoi ? Parce qu'il faut considérer que le contexte de chaque squelette est indépendant. Par contexte, j'entend l'ensemble des paramètres techniques qui lui sont passés, par exemple un numéro d'article. Ce contexte est récupérable via la balise #ENV et sert à l'interprétation des critères de boucles de premier niveaux. J'explique plus en détails cette notion de contexte dans un article sur contrib.

ou `#INCLURE` ?

Il existe deux modes principaux d'inclusion :

#INCLURE{fond=B}

Historiquement, le premier modèle est apparu d'abord. Quelle est la différence technique entre les deux ? Soit un squelette A appelant un squelette B.

Dans le cas d'une inclusion avec INCLURE le squelette B possède son propre cache. Lorsque le squelette A est appelé, il produit son cache à lui. Le résultat du cache de A est retourné au navigateur, et c'est à ce moment là que le cache du squelette B est inséré.
Dans le cas d'une inclusion avec #INCLURE, il n'existe pas de cache du squelette B. Le morceau de PHP / HTML lié à l'interprétation par SPIP du squelette B est mis directement dans le cache du squelette A.

Puisqu'il paraît qu'il faut mettre des schémas, voici un schéma qui tente d'expliquer cette différence [1].

ou #INCLURE ?

Inclusion statique ou inclusion dynamique ?

Conséquences techniques

Du point de vue de la taille des caches :
1. produit plus de fichiers de cache, mais moins gros.
2. #INCLURE produit des fichiers de cache plus gros, mais en moindre quantité.
Du point de vue de la durée des caches :
1. permet d'avoir un squelette fils n'ayant pas la même durée de cache que le squelette père.
2. #INCLURE ne permet pas cela, puisque le squelette fils n'a pas vraiment de cache propre.
Du point de vue des techniques SPIP applicables :
1. On peut pas filtrer le résultat d'une inclusion par [2].
2. Par contre avec #INCLURE on peut appliquer un filtre [(#INCLURE{fond=B}|filtre)].
3. Dans tout les cas on peut utiliser AJAX.
Du point de vue de la performance j'avoue ne pas trop savoir. Avoir un cache propre () permet d'avoir une vrai mutualisation des caches, dont un gain en terme de requête SQL, en revanche on a une perte de temps au moment où le cache de B est « reinjecté » dans le fichier A renvoyé à l'internaute. C'est donc au développeur de juger au cas par cas, mais il me semble que dans 90 % des cas, il vaut mieux utiliser .

Et `#MODELE`

On peut aussi utiliser #MODELE. Pour ce faire, il faut que le fichier inclu se situe dans le dossier modeles.

Techniquement, faire

#MODELE{B}

revient, à peu de chose près, à la même chose que faire #INCLURE{fond=modeles/B}. Une différence toutefois : dans le cas de #MODELE l'identifiant de l'objet courant est automatiquement passé en paramètre.

Exemple, j'ai un squelette modeles/B.html :

 #ID_ARTICLE #TITRE

Dans mon squelette A, je cherche à appeler ce squelette pour tout les articles d'une rubrique.

Je peux faire soit :

 #MODELE{B}

soit :

 #INCLURE{fond=modeles/B,id_article}

Personnellement je n'aime pas trop #MODELE, je trouve qu'il induit une confusion. Le seul cas où l'emploi de modèle est justifiable, c'est lorsque l'on souhaite permettre à un auteur d'inclure un tel morceau dans son article, en utilisant :

Par exemple le plugin Gravatar propose un modèle gravatar, que l'on peut appeler :

soit dans un squelette #MODELE{gravatar}{id_auteur}.
soit dans un article .

On consultera la documentation sur les modèles pour plus de détails.

Pour aider à y voir plus clair dans les différents squelettes inclus, on utilisera la fonction var_mode=inclure.

[1] Toute suggestion d'amélioration est la bienvenue.

[2] Une solution pour contourner ce problème est de mettre #FILTRE{nom du filtre} dans le squelette inclus.

Sept bonnes pratiques de développement avec SPIP

Maïeul — 2012-01-05T00:39:57Z

Je travaille en ce moment sur un squelette qui n'est pas de moi. Il semble que la personne qui l'a créé n'était pas au courant des bonnes pratiques de développement sous SPIP. Il est vrai que ces bonnes pratiques ne sont pas nécessairement accessibles aux premiers abords de la documentation webmaster de SPIP.

Voici sept règles que je juge indispensables

1. Ne pas mettre de PHP dans les squelettes

Le but de SPIP était de permettre de ne pas avoir à connaître le PHP pour concevoir un site. Tout un système spécifique a été prévu, pour faire des requêtes SQL, mais aussi des tests. C'est parfois perturbant pour les utilisateurs venant du monde PHP.

Mais pour autant, c'est une très bonne pratique de ne quasiment-jamais mettre de PHP dans un squelette. En réalité, c'est une mauvaise pratique d'en mettre.

2. Ne rien mettre dans le dossier IMG

Le dossier IMG ne doit contenir que les images et documents ajoutés par l'utilisateur depuis l'interface privé. En aucun cas il ne doit contenir des images propres aux squelettes, qui doivent se trouver dans le même dossier que les squelettes.

Choisir de mettre les images dans IMG (comme je l'ai vu dans ce squelette), c'est compliquer les réutilisations des squelettes, et mélanger les couches utilisateurs et webmestres de SPIP.

3. Utiliser `#CHEMIN`

La balise #CHEMIN est une balise indispensable de SPIP. Elle permet d'indiquer l'adresse d'un fichier sans se préoccuper du nom du dossier parent. En effet, SPIP va cherche le fichier passé en argument dans l'ordre suivant [1] :

squelettes
plugin B dépendant du plugin A
plugin A
squelettes-dist
prive
ecrire

Exemple : j'ai une image dans le dossier squelettes, je ne fais pas :

mais bien

mieux, je met mon image toto.png dans le dossier img du dossier squelettes.

Je peux alors faire :

L'avantage d'un tel système est évident : permettre d'avoir un dossier squelettes qui ne s'appelle pas squelettes, par exemple lorsqu'on utilise ma sixième recommandation : les squelettes sous forme de plugins. Mais aussi permettre à SPIP de gérer correctement les URLS arborescentes (le cas échéant).

4. Utiliser `|balise_img`

Il est recommandé lorsqu'on insère une balise de lui mettre des attributs height et with pour améliorer les performances du navigateur lors de l'affichage de la page.

On peut bien sûr indiquer cela manuellement :

Mais supposons que je réduise la taille de toto.png : je dois dans ce cas modifier les attributs height et width à chaque fois que je l'utilise.

Pour éviter cela, SPIP prévoit le filtre |balise_img qui, lorsqu'il est appliqué au chemin d'un fichier image, crée automatiquement la balise , avec la hauteur et la largeur du fichier. Ainsi, pas besoin de corriger si on réduit la taille du fichier.

Le filtre s'utilise de manière très simple :

[(#CHEMIN{toto.png}|balise_img)]

On peut même mettre en argument le contenu de l'attribut alt

[(#CHEMIN{toto.png}|balise_img{0+0})]

Voir en deuxième argument la valeur de l'attribut class :

[(#CHEMIN{toto.png}|balise_img{0+0,blague_pour_enfants})]

Ce code au final me produit :

5. Utiliser les chaînes de langues

Bien que cela puisse paraître inutile et fastidieux pour un site monolingue, utiliser les chaînes de langue est quand même utile pour trois raisons :

on ne sait jamais : si le site devient multilingue, c'est toujours cela de fait.
il est plus facile d'uniformiser les textes.
il est plus facile de corriger en cas de faute ou de changement d'avis.

6. Utiliser

C'est un principe de base de l'informatique : dès qu'une séquence d'instructions est utilisée plusieurs fois, il faut non pas la dupliquer, mais la mettre dans un morceau qu'on appelle plusieurs fois.

En SPIP ce morceau, c'est un fichier inclus.

Typiquement supposons que j'affiche sur toutes les pages de mon site les sites amis.

Au lieux de copier-coller le code suivant dans les squelettes :

   #NOM

Je le met dans un fichier sites-amis.html, situé dans un dossier inclure du dossier contenant les squelettes.

Et je met le code suivant là où je souhaite afficher les sites amis :

Cela me permet si je dois modifier les critères de cette liste de ne les modifier qu'à un endroit [2].

La logique est donc : diviser son site en briques réutilisables. Chaque brique correspondant à fichier et à un morceau logique de page. Ensuite assembler ces briques dans des fichiers plus globaux [3].

Le modèle de squelettes Z pousse à l'extrême cette logique des inclusions. Je conseille de le suivre : on gagne largement en maintenance ce qu'on perd en temps d'apprentissage initial.

Une règle importante dans les inclusions : les balises html qui s'ouvrent dans un fichier doivent se fermer dans le même fichier. Il est très mauvais d'ouvrir une balise dans un fichier puis de la fermer dans un autre : on y est perd en lisibilité du code, et donc en maintenance [4].

7. Mettre ses squelettes sous formes de plugins

Cela peut paraître un luxe ou coquetterie, mais cela facilite énormément le déploiement d'un même squelette sur plusieurs sites ou le déménagement depuis la version locale vers la version en ligne :

en indiquant les dépendances aux plugins.
en incluant le fichier mes_options.php dans le même dossier.
en permettant même le cas échéant d'ajouter automatiquement un contenu pré-défini.

Un précédent article détaille comment fabriquer ces squelettes-plugins.

Amis SPIPeurs, j'attends vos remarques et ajouts !

[1] Liste tirée du site Programmer avec SPIP.

[2] En outre, cela diminue les requêtes SQL et donc la charge du serveur SQL, mais la contrepartie est de multiplier les fichiers de caches ainsi que les inclusions PHP.

[3] Pour comprendre comment passer des paramètres lors de ces inclusions, pour par exemple connaître l'article courant, je renvoie à mon article sur la balise #ENV. Cet article devrais être mis à jour pour parler des dernières nouveautés. Mais l'essentiel est là.

[4] J'ai crû à un moment qu'une structure html était incorrecte du fait qu'un fichier avait plus de

ouvrantes que fermantes. En réalité, le dernier

manquant se trouvait ailleurs.

Archivage avec redirection

Maïeul — 2011-06-24T13:15:24Z

Sur ce site, certains articles sont considérés comme « obsolètes » parce que j'ai trouvé une meilleure méthode pour obtenir le même résultat.

Je souhaitais que google n'indexe plus ces articles, mais soit redirigé vers leurs remplaçants respectifs. En même temps, je souhaitais qu'une personne qui s'amuse à fouiller dans les archives de ce site puisse le cas échéant retrouver l'article.

Voici la manière dont j'ai procédé. Je remercie xdjuj pour m'avoir fourni l'idée de départ.

Principe

Pour arriver à mes fins, j'utilise le plugin A2A qui me permet d'indiquer quel est l'article remplaçant d'un article obsolète.

En interne, les liens vers les articles archivés portent la variable GET archive=oui. Par exemple Un index des sources primaires (1).

Si une personne arrive sur une page archivée sans passer la variable archive=oui alors elle est redirigée vers la nouvelle version, par une redirection HTTP 301 (redirection permanente).

En revanche si la variable est passée, il reste sur cette page, mais celle-ci possède une meta-donnée qui indique de ne pas l'indexer.

Ceci permet donc d'accéder aux archives du site via la navigation interne de ce site, tout en réorientant les liens externes, dont ceux des moteurs de recherches.

La méthode : la modification des liens

Il existe deux types de liens internes pointant éventuellement vers des archives : ceux générés avec #URL_ARTICLE dans un squelette et ceux générés avec des raccourcis de la forme [texte->xx] ou [texte->artxx] ou [texte->articlexx], dans le texte d'un article.

Comment faire pour ajouter des arguments à ces liens seulement si l'article de destination est un article « obsolète » ?

Dans les squelettes

Pour les liens dans les squelettes, c'est relativement simple :

[(#URL_ARTICLE|parametre_url{archive,oui})] me rajoute ma variable. Sauf que cela le fait sur tous les articles.

Il va donc falloir conditionner. Pour ce faire je crée un squelette inclure/obsolete.html. Celui-ci renvoie 1 si un article est lié à l'article passé en argument, donc si cet article est « obsolète ». Il ne renvoie rien dans le cas contraire.

Voici le code de ce squelette

Je remplace dans mes squelettes toutes les références à #URL_ARTICLE par :

[(#INCLURE{fond=inclure/obsolete}{id_article}|?{#URL_ARTICLE|parametre_url{archive,oui},#URL_ARTICLE})]

Ce qui en gros veut dire : on utilise le squelette inclure/obsolete en lui donnant l'id_article courant comme valeur. Si ce squelette retourne quelque chose, alors on renvoie #URL_ARTICLE|parametre_url{archive,oui}, sinon on renvoie simplement #URL_ARTICLE.

À noter qu'ici je filtre un squelette appelé via #INCLURE, ce que je ne peux faire avec .

Pour les raccourcis typographiques

Il faut qu'avant que SPIP interprète les raccourcis typographique, je modifie, si cela est pertinent, les formes [texte->artxx] par [texte->artxx?archive=oui]. SPIP s'occupera ensuite de la question des urls propres.

Pour faire cela, j'utilise la pipeline pre_liens, que je déclare dans mon fichier plugin.xml

 pre_liens geek_maieul.php

Sur la pipeline pre_liens, je renvoie à l'article de Marcimat.

Je la déclare dans mon fichier geek_maieul.php.

function geek_maieul_pre_liens($texte){ $match = array(); if (!preg_match("#->(?:art)?(?:article)?([0-9]+)\]#",$texte,$match)){ //trouer les liens vers les articles, sans rien derrière return $texte; } $obsolete = sql_getfetsel('id_article_lie','spip_articles_lies','id_article='.$match[1]); // y a-t-il un article lié ? if ($obsolete){ $texte = str_replace($match[1].']',$match[1].'?archive=oui]',$texte); // on } return $texte; }

Commentaires :

ligne 1 : nom de la fonction / pipeline.
ligne 2 à 5 : je teste si mon lien interne est bien un lien de type article. Si jamais ce n'est pas le cas, je ne modifie rien et renvoie le lien comme il était avant. Sinon je stocke le numéro de l'article dans le tableau $match, dans l'entrée 1. Pour ce faire, j'utilise une expression régulière.
ligne 7 : je regarde si mon article a un article lié. J'utilise pour cela la fonction de SPIP sql_getfetsel()
ligne 8 et 9 : si mon article a un article lié, je modifie le lien, en ajoutant ?archive=oui.
ligne 11 : je renvoie le tout.

Redirection

Dans mon fichier article.html, je teste si mon article a un article lié, et si c'est le cas, j'appelle filtre sur l'URL de l'article lié :


[(#URL_ARTICLE{#ID_ARTICLE_LIE}|redirect301)]

Le filtre |redirect301 est écrit par moi. C'est une fonction php relativement simple

function redirect301($url){ if (_request('archive')!='oui'){ header("Status: 301 Moved Permanently", false, 301); header("Location:$url"); exit(); }
}

Avant de faire une redirection, je vérifie que je n'ai pas la valeur archive=oui passée dans l'url [1]

Si c'est le cas, je procède à la redirection.

Méta donnée pour indiquer de ne pas indexer

Dans l'entête de mon squelette d'article, je met

[(#INCLURE{fond=inclure/obsolete}{id_article}|oui)].

Ce qui a pour conséquent de placer la balise si mon article est obsolète, afin que les moteurs de recherches ne l'indexent plus.

Il est évident que si je fais pointer l'article A vers l'article B et l'article B vers l'article A je risque d'avoir des problèmes de renvois mutuels. Mais comme je suis le seul rédacteur sur ce site, le risque est minimum.

[1] J'utilise la fonction SPIP _request().

Afficher plusieurs fois un même objet SPIP

Maïeul — 2010-12-19T22:11:04Z

Dans le cadre d'un projet associatif, je me sert de SPIP pour gérer une base de donnée. Cette base de donnée contient un certain nombre d'objets — des cartes de jeux en fait, que j'ai « traduites » en SPIP par des articles — que j'ai besoin d'afficher plusieurs fois. Le nombre d'affichages nécessaires est propre à chaque cartes / articles.

Pour arriver à mes fins, voici comment j'ai fait :

J'ai ajouté un champ extra nombre à la table articles.
Dans ce champ je précise le nombre de fois où je souhaite afficher un article. C'est donc un champs de type INT.
J'utilise ensuite le plugin SPIP-Bonux pour boucler sur un tableau PHP que je génère grâce à la fonction array_fill() de PHP. Ce tableau contient #NOMBRE fois la valeur ''.
A l'intérieur de cette boucle, je peux récupérer les informations de l'article directement avec les balise #CHAMP dont SPIP reconnaitra qu'elle font allusion à la boucle « mère ».

Cela nous donne donc :

  J'affiche le titre de l'article #TITRE qui porte le numéro #ID_ARTICLE etc.

Le code exposé ici n'est pas tout à fait celui que j'utilise pour mon projet, car dans celui-ci je dois mélanger de manière aléatoire les différents articles. Je passe donc par un tableau global que je remplis des valeurs des #ID_ARTICLE le nombre de fois nécessaires.

Pourquoi ne pas mettre de PHP dans un squelette, sauf exception

Maïeul — 2010-12-10T00:16:19Z

Je tombe régulièrement sur des squelettes, faits par des gens venant du monde PHP, qui sont pleins de PHP.

Voici quelques bonnes raisons de ne pas faire cela. Et puis aussi des pistes sur comment s'en passer.

Raison 1 : On ne profite pas du cache de SPIP

SPIP dispose d'un système de cache, qui évite de refaire trop souvent des calculs, et donc accélère les pages. Les parties PHP d'un squelette SPIP ne sont pas soumis à ce système, du coup on perd un des avantages de SPIP.

Raison 2 : C'est illisible

Bien souvent, pas toujours, ces « squelettes » sont illisibles, car le code PHP n'est pas bien structuré. Ce n'est pas toujours le cas, mais très souvent. Je pense que les personnes qui utilisent cela « bidouillent » car ils n'arrivent pas à faire ce qu'ils veulent en SPIP. Bien sûr, on pourrait imaginer un squelette SPIPHP lisible, mais je n'en ai jamais vu.

Raison 3 : Ce n'est pas optimisé

Il m'est arrivé de voir des requêtes SQL directement dans un squelette SPIP ! Alors même que SPIP est un méta-langage de requêtes SQL, qui les optimise automatiquement. J'ai vu par exemple des appels via mysql_query() à des champs qui ne seront jamais utilisés dans la page. SPIP lui n'appel que les champs réellement utiles (ceux qu'on insère dans la page avec #CHAMP).

Raison 4 : On ne profite pas de la souplesse des boucles de SPIP

Les boucles de SPIP possèdent des ressources insoupçonnées : récursivité des requêtes, requêtes imbriquées. Certe il est possible de faire cela en SQL / PHP, mais pourquoi ré-inventé la roue, d'autant plus que SPIP, la lecture sera plus claire.

Raison 5 : On ne profite pas de SPIP

Et oui, SPIP c'est prévu pour pouvoir faire directement les requêtes SQL dans la « trame », dans le « moule » de l'affichage souhaité. Si on en profite pas, alors pourquoi prendre SPIP et pas un autre CMS ?

Une exception : pour gérer certains élèments de session

Toute règle à ses exceptions. C'est le cas de la présente règle. On lira un article qui explique pourquoi, pour gérer les sessions, mettre du PHP dans certains squelettes peut-être une solution.

Comment faire

Ceci n'est pas exhaustif, mais je tenterai de donner quelques indications pour les gens venant du monde PHP pour se « convertir » en SPIP.

Une requête SQL = Une Boucle SPIP. Pour ceux qui ont besoin d'une explication formaliste, grammaticale de ce qu'est une boucle SPIP : http://programmer.spip.org/-Les-boucles-
Pour modifier le résultat d'une balise SPIP = d'un champ SQL : un filtre = une fonction à définir dans mes_fonctions.php. Définition formelle d'une balise : http://programmer.spip.org/-Les-balises-, définition formelle d'un filtre : http://programmer.spip.org/-Les-filtres-de-balises-
Une variable de compteur :
- Si c'est pour compter les résultats d'une requête SQL : #COMPTEUR_BOUCLE. Ex : itération #COMPTEUR_BOUCLE
- Si la variable est plus compliquée : #SET{variable,valeur}, #GET{variable} et les filtres mathématiques : |plus, |mult etc. http://www.spip.net/fr_article901.html
- Une variable tout court : voir ci dessus.
Des tests conditionnels :
- filtres de comparaison et filtres de test : http://programmer.spip.org/Filtres-de-comparaison http://programmer.spip.org/Les-filtres-de-tests.
- Et pour conditionner en fonction du résultat de la requête SQL : la syntaxe complète des boucles : http://programmer.spip.org/Syntaxe-complete-des-boucles
- Des tableaux : la balise #ARRAY : http://www.spip.net/fr_article4009.html

Voilà, avec ça vous avez les bases pour ne plus mettre de PHP dans vos squelettes (bien sûr, il faut lire les liens ! Ceci n'est pas un tutoriel).

Si d'autres SPIPeurs voient des bonnes raisons, ne pas hésiter à les signaler.

Gérer le statut des articles directement depuis le site public

Maïeul — 2010-12-07T23:20:00Z

J'utilise sur ce site le plugin de prévisualisation en cours de rédaction, qui me permet de voir le résultat de ma rédaction sur le site public, avant que l'article soit publié.

Du coup j'ai voulu pouvoir changer le statut de l'article directement sur le site public.

Remarque : sous SPIP 3, c'est beaucoup plus simple.

Pour ce faire, je me suis rendu dans l'espace privé de spip, et j'ai ajouté un &var_mode=inclure sur la page d'un article. J'ai ainsi reperé que le bloc qui m'intéressait se situait dans prive/infos/article.html.

En ouvrant ce fichier, j'ai reperé la ligne qui m'intéressait :

[(#ID_ARTICLE|instituer_article{#ID_RUBRIQUE,#STATUT})]

Cela affiche le bloc de changement de statut.

J'ai donc recopier cela dans mon squelette article.html [1].

Mais comme je ne voulais pas que n'importe qui voit ce bloc, j'ai testé l'autorisation

[(#AUTORISER{instituer,article,#ID_ARTICLE}|oui) [(#ID_ARTICLE|instituer_article{#ID_RUBRIQUE,#STATUT})]]

Seulement voilà, le filtre |instituer_article n'existe pas dans tout SPIP. Il est défini dans le fichier prive/statuts/article_fonctions.php, ce qui veut dire qu'il n'existe que pour le squelette prive/infos/article.html.

function instituer_article($id_article, $id_rubrique, $statut){ $instituer_article = charger_fonction('instituer_article', 'inc'); return $instituer_article($id_article, $statut, $id_rubrique);
}

J'ai donc recopié cela dans un fichier article_fonctions.php [2]

Le problème est que la fonction instituer_article() renvoi des liens dans l'espace privé, et non le lien de l'article dans l'espace public. Du coup, après avoir changé le statut d'un article, je me retrouvais sur page 404 du type : http://http://geekographie.maieul.net/ecrire/ecrire/?exec=articles&id_article=10, ce qui était génant.

Comme il n'existe pas de pipeline pour cette fonctions, j'ai du faire quelquechose de « sale », en modifiant son résultat.

Et du coup mon fichier articles_fonctions.php contient :

function instituer_article($id_article, $id_rubrique, $statut){ $instituer_article = charger_fonction('instituer_article', 'inc'); return str_replace('ecrire%2Fecrire%2F%3Fexec%3Darticles%26id_article%3D','spip.php%3Farticle',$instituer_article($id_article, $statut, $id_rubrique));
}

Par ailleurs, la fonction instituer_article de inc contient un appel à fonction puce_statut(). Il a donc fallu que je rajoute une inclusion supplémentaire auparavent.

include_spip('inc/puce_statut');

Et voilà, cela fonctionne ! Je peux modifier le statut d'un article depuis le site public, mais les autres ne voient pas ce bouton.

En résumé

Dans le fichier article.html, à l'endroit souhaité

[(#AUTORISER{instituer,article,#ID_ARTICLE}|oui) [(#ID_ARTICLE|instituer_article{#ID_RUBRIQUE,#STATUT})]]

Dans le fichier article_fonctions.php

Évidement, avec la balise #AUTORISER, cela double le cache de article/extra.html : un cache pour moi connecté, un pour les visiteurs non connectés.

[1] En fait comme j'ai un squelette « Z », j'ai mis dans extra/article.html, mais cela ne change pas grand chose.

[2] En fait extra/article_fonctions.php.

Un fichier mes_options.php minimal

Maïeul — 2010-12-05T13:03:22Z

Voilà un fichier mes_options.php minimal, que je conseille à tout webmestre Spipeur.

Les quatres premières lignes permettent de supprimer automatiquement les numéros de tri des articles / rubriques / auteurs / mot / sites de SPIP [1]. Du coup plus besoin de la lame du couteau-suisse, qui est devenu une usine à gaz, et plus besoin de mettre un filtre |supprimer_numero dans tout les squelettes.

La dernière ligne augmente la taille du cache de SPIP. 10 Mo par défaut, c'est vite juste, surtout quand vous utilisez un squelette de type ZPIP.

[1] quand vous appelez un titre 1. Titre

Geekographie Maïeulesque

Jouons un peu avec |image_masque

Principe

Mise en œuvre

Gérer le statut des articles directement depuis le site public sous SPIP 3

Les différents modes d'inclusion de SPIP

Rappel : principe de l'inclusion

ou #INCLURE ?

Conséquences techniques

Et #MODELE

Sept bonnes pratiques de développement avec SPIP

1. Ne pas mettre de PHP dans les squelettes

2. Ne rien mettre dans le dossier IMG

3. Utiliser #CHEMIN

4. Utiliser |balise_img

5. Utiliser les chaînes de langues

6. Utiliser

7. Mettre ses squelettes sous formes de plugins

Archivage avec redirection

Principe

La méthode : la modification des liens

Redirection

Méta donnée pour indiquer de ne pas indexer

Afficher plusieurs fois un même objet SPIP

Pourquoi ne pas mettre de PHP dans un squelette, sauf exception

Raison 1 : On ne profite pas du cache de SPIP

Raison 2 : C'est illisible

Raison 3 : Ce n'est pas optimisé

Raison 4 : On ne profite pas de la souplesse des boucles de SPIP

Raison 5 : On ne profite pas de SPIP

Une exception : pour gérer certains élèments de session

Comment faire

Gérer le statut des articles directement depuis le site public

En résumé

Un fichier mes_options.php minimal

ou `#INCLURE` ?

Et `#MODELE`

3. Utiliser `#CHEMIN`

4. Utiliser `|balise_img`