Geekographie Maïeulesque

Succession d'articles avec A2A

Maïeul — 2012-09-13T19:16:57Z

La nouvelle version du plugins A2A permet de typer les relations entre articles. Je m'en sert sur ce site pour créer des succession d'articles, par exemple ma série d'articles sur les stemma.

Comment fais-je ?

Configuration du plugin

Je crée un nouveau type de relation, dont la clef est « Suivant » et le titre est « Article suivant ».

Chaque article de la chaîne, sauf le dernier, est relié à l'article suivant selon ce type.

Voilà pour l'espace privé.

Côté squelettes

Je souhaite afficher l'ensemble des articles de la chaîne dans laquelle se situe l'article courant mais :

En ne mettant pas de lien sur l'article courant.
En mettant un attribut rel=prev ou rel=next pour le liens vers l'article immédiatement précédent/suivant.

Voici comme je procéde, les commentaires suivent.

 #SET{precedent,''} #SET{suivant,''} #SET{succession,#LISTE{#ID_ARTICLE}}  #SET{succession,#LISTE{#ID_ARTICLE}|push{#GET{succession}}} [(#ID_ARTICLE_LIE|=={#_article:ID_ARTICLE}|oui) #SET{precedent,#ID_ARTICLE} ]    #SET{succession,#GET{succession}|push{#ID_ARTICLE_LIE}} #SET{suivant,#ID_ARTICLE_LIE}  #SET{succession,#GET{succession}|push{#ID_ARTICLE_LIE}}     <:geek:succession_article:> :
  {1}} >  [(#EXPOSE|non)] #TITRE [(#EXPOSE|non)]

l. 1 : la boucle englobante du squelette, je masque ici les autres contenus.
l. 2-3 : deux variables dans lesquelles on stockera les numéros de l'article précédent et de l'article suivant.
l. 4 : liste dans laquelle on va stocker les id de chaque article de la chaîne. On initialise la liste avec le numéro de l'article courant.
l. 5 et 11 : on cherche l'article précédent.
l. 6 : on ajoute l'article précédent à la liste des articles de la chaîne, en début de liste.
l. 9 : on indique l'id de l'article immédiatement précédent dans la variable precedent. Notez le test qui permet de jouer avec la récursion de la l. 10 sans changer à chaque fois precedent.
l. 13 à 20 : la même chose que l. 5 à 11, mais pour les articles qui suivent dans la chaîne. Notez qu'on étend la liste vers la fin, et non pas vers le début, comme précédement.
l. 23 à 38 : boucle (ARTICLES) classique, mais on choisit comme < code>id_article ceux listés dans le tableau. Notez que {id_article IN …}. On notera :
- l. 24 : l'utilisation de #EXPOSE pour styler différemment l'article courant, de même l. 25 et 27 pour n'afficher le liens que sur les articles différent de l'article courant.
- l. 25 [ rel="next"(#ID_ARTICLE|=={#GET{suivant}}|oui)] et son comparse [ rel="prev"(#ID_ARTICLE|=={#GET{precedent}}|oui)] qui permet d'ajouter l'attribut rel à la balise , si besoin.

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.

Notifications sur un forum plat

Maïeul — 2010-12-17T10:17:40Z

Sur ce site j'utilise le plugin Notifications, pour que les personnes reçoivent les réponses à leurs réactions.

J'ai coché dans la configuration « Fil de discussion : les participants au même fil de discussion reçoivent les notifications des forums (publics). ». Mais les personnes ne recevaient pas les notifications. Voilà comment j'ai résolu le problème.

Le problème, c'est que mes forums sont en mode {plat} [1]. Donc il n'y a pas vraiment de fil de discussion, mais seulement des messages individuels sans liens, du coup notification ne peut fonctionner.

La solution est de s'arranger pour avoir un fil de discussion unique.

Pour cela, j'appel de la manière suivante le formulaire de réaction :


#FORMULAIRE_FORUM

#FORMULAIRE_FORUM

Ainsi, le message est systématiquement posté en réaction au dernier message, et s'il n'y a pas de message, il est posté directement en réaction à l'article, et un fil de discussion est ouvert.

[1] En fait j'utilise le plugin de Romy : Comments, qui met ce mode {plat}

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.