Pourquoi ne peut-on pas insérer du code Smarty dans la bannière des pages de Piwigo ?

_{Hors-sujet : Indiquer l’url de la galerie est un peu étrange, devoir coder soi-même des balises en réutilisant en général ces mêmes informations relève d’une logique perturbante.}

Revenons à la question initiale : vos indications sont d’abord enregistrées dans la base de données, puis lors de la publication d’une page publique ces données seront placées dans une variable Smarty : $PAGE_BANNER et c’est cette variable qui se retrouve dans le header.tpl utilisé par le thème de votre site.

Comment pourrions-nous simplifier ceci ?
Nous avons déjà évoqué la solution, mais elle est passée inaperçue, je ne cherchais pas à la mettre en évidence.
Dans « Concevoir des templates évolutifs » c’est presque la même solution.
Voyons cela avec un cas précis.
Imaginons que nous voulions coder:

En utilisant des templates-extensions.
Dans ./template-extension/ nous allons créer un page_banner.tpl avec :

Et toujours dans ./template-extension/ nous allons créer un header.tpl avec :

Bien entendu on activera le template-extension/header.tpl

Comment ça fonctionne ?
Quand la page sera demandée, l’header.tpl sera sollicité. Celui-ci étant substitué par celui du répertoire template-extension, la première chose réalisée sera l’include de page_banner.tpl. Cependant au lieu de présenter immédiatement le résultat sera affecté à la variable BANNER (assign=BANNER).
Ensuite nous avons un assign var= (facultatif) qui n’est là que pour le cas où nous voudrions utiliser le texte initial de la « Bannière des pages » ultérieurement dans un autre template.
Enfin on sollicite le header par défaut (pour rester évolutif) mais cette fois nous indiquons PAGE_BANNER=$BANNER, c’est à dire que nous changeons le contenu de $PAGE_BANNER par ce que nous avions obtenu de l’include de page_banner.tpl.

Ce n’est que du Smarty tout à fait standard. C’est simple et sympa, bref c’est Smarty.

ou

Alors sans le moindre plugin, vous pouvez compléter votre galerie de fonctions diverses et variées.

Exemple :

Voyons comment utiliser cette fonction.
En premier lieu, dans une version statique c’est à dire dans n’importe quel template, vous pouvez coder par exemple :

Cette solution sera statique car quelque soit le template choisi, la présentation sera toujours identique.

Regardons maintenant une solution dynamique, en d’autres termes vous souhaitez disposer du nom du membre dans un contenu (description d’une catégorie, page additionnelle, bloc de PWG Stuffs), alors au niveau d’un template, vous devrez coder (1ère solution) :

Et maintenant à chaque fois, où vous voulez voir apparaitre le nom du membre, vous coderez :

L’autre solution dynamique (ma préférée) est à base de jQuery, et consiste en un remplacement de toute occurrence de <label class="pseudo"></label> par le nom du membre. Pour cela, au niveau d’un template, vous devrez coder (2nde solution) :

Cette fois, quand vous aurez besoin du pseudo du membre, vous devrez coder :

Un seul inconvénient commun à nos deux solutions dynamiques, Javascript doit être actif.
Bon usage à tous et, saluez vos membres de ma part.

Quand la météo est à la pluie, laisse ton appareil dans son étui.

Quand le temps se joue de nous, il nous reste la chanson:

Señor Météo
Quando dit qu’il fait beau
Señor Météo
A glagla quel frigo !
Quando mi transistor esperansa calor
Il a tort !
Que dolor

_{Claude Lemesle / Joe Dassin en 1974}
Depuis la météorologie a fait beaucoup de progrès, il faut bien le reconnaître.

Il y a quelques temps, C. Bavota a publié une révision du thème « Magazine Basic » incluant une fonction d’enregistrement en Ajax. Dans l’attente de réactions suite à sa publication sur WordPress, il a obtenu des informations sur la façon d’intégrer Ajax en utilisant le module admin-ajax.php au lieu du code qu’il avait utilisé. Toutes les fonctions principales en Ajax de WordPress s’appuient sur admin-ajax.php, et sa mise en œuvre pour des scripts personnalisés est extrêmement simple.

Regardons les éléments dont vous aurez besoin pour que cela fonctionne. Dans l’exemple ci-dessous, nous allons coder une petite fonction de mailing-list qui notifiera l’administrateur par courriel lors d’une nouvelle inscription.

Voyons le formulaire :

Voici le jQuery :

Permettez-moi de vous expliquer chaque composant.

Quand un utilisateur clique sur « S’abonner » (Envoyer), nous devons vérifier que le champ e-mail n’est pas vide. S’il est vide, nous en informerons le visiteur en lui indiquant « Merci d’indiquer votre adresse email. » et nous arrêtons le processus en incluant l’instruction « return false; ».

Ensuite, nous ferons une simple validation pour s’assurer que l’adresse e-mail contient au moins une arrobe (@) et un point. Si ce n’est pas le cas, nous renverrons un message d’erreur suivi de « return false; ».

Une fois ces contrôles élémentaires effectués et passés avec succès, nous pouvons traiter le formulaire. C’est maintenant qu’admin-ajax.php entre en jeu. Lors l’utilisation d’admin-ajax.php, vous devez ajouter une action WordPress (add_action) incluant une fonction de rappel (callback function) pour que ça fonctionne. Notre fonction de rappel sera join_mailinglist. Notre fonction PHP rendra l’ensemble fonctionnel en tâche de fond. Mais avant, nous allons créer une variable pour stocker l’action et l’adresse email du nouvel abonné.

Maintenant, nous allons cacher le bouton d’envoi et présenter un graphique animé pour indiquer qu’une tâche de fond s’exécute. Puis nous utiliserons la fonction .post de jQuery pour envoyer ces informations au module admin-ajax.php. Une fois la fonction terminée et la réponse transmise, l’animation va disparaître, le bouton « S’abonner » sera de retour avec un message de succès, ou un message d’erreur.

Avec le formulaire et le jQuery, vous aurez besoin encore d’un peu de PHP.
Le module admin-ajax.php requiert deux ancrages d’action (add_action).

La première action ne fonctionnera que pour les utilisateurs connectés. La seconde le sera pour les autres. Les visiteurs n’ont pas à être connectés pour notre besoin, et dans notre cas l’action devrait ressembler à ceci :

Voici la fonction join_mailinglist_callback, qui devra être ajoutée à votre functions.php :

Une fois tout en place, vous obtiendrez un formulaire fonctionnant comme ci-dessous.

_{En réalité, aucune lettre d’information ne vous sera adressée suite à votre inscription sur ce formulaire de démonstration (les adresses fournies peuvent être fictives, elles ne seront pas enregistrées).}

_{Translated and adapted from « Using Ajax with WordPress » article by C. Bavota (with his kind authorization).}

Pourquoi est-ce une erreur?

1 – En cas d’erreur lors du transfert de l’image, la balise est affichée sous forme d’une petite croix rouge par la majorité des navigateurs.
2 – Les moteurs de référencement cherchent à référencer les images, or trouver des petites images identiques sur des milliers de sites conduit immanquablement à appliquer une décote sur l’intérêt de nos sites.

Quelle est la portée de cette erreur?
Les templates du thème par défaut devraient être une fois encore révisés, car ceux-ci entrainent dans la même erreur les autres thèmes et leurs templates, sans compter les plugins qui ajoutent d’autres templates répétant tous ou presque cette même erreur.
Au moins une vingtaine de fichiers sont concernés, il vous suffit d’effectuer une recherche de class="button" ou de "icon" ou encore de "navButton" dans le répertoire themes/default/template/ pour vous en convaincre.

Comment l’équipe Piwigo pourrait-elle résoudre proprement cette erreur?
Un exemple simple :

En :

En tenant compte du billet suivant : Afficher une image au lieu d’un texte (en CSS) et les quelques idées suivantes :
- L’élément déclencheur pourrait être : class="button",
- le {$themeconf.button} permettrait de passer la font en 0/0, ce qui permet d’avoir des thèmes avec icones et d’autres avec textes, sans que les plugins aient à se poser des questions métaphysiques s’ils doivent/peuvent ajouter des boutons ou pas en fonction du thème.
- Quant au {$button.status}, il assurerait un décalage de l’image en fonction de :hover, :active, etc… Une technique déjà employée pour l’évaluation (rating) des images mais qui demande une révision de toutes les icones actuel(le)s ce qui pourrait fortement contrarier les créateurs de thèmes.

A titre individuel, pourrions-nous déjà anticiper un tel changement ?
Oui, c’est réalisable avec un thème personnel, en concentrant nos efforts ne serait-ce que sur trois templates :

• index.tpl
• picture.tpl
• picture_nav_buttons.tpl

Soit des templates pour lesquels vous devrez vous limiter à :

Exemple du niveau de complexité du changement :

en :

Un changement qui doit être accompagné dans votre theme.css de :

En guise d’épilogue, et pour ne pas focaliser sur Piwigo lequel présente de nombreux avantages, j’attirerai votre attention sur d’autres applications. Par exemple Contao, lequel n’utilise pas un moteur de template et présente la même erreur. Par contre, Gallery 3, zenphoto, WordPress ou Dotclear ne semblent pas concernés sauf si un thème externe ne respecte pas leurs standards.
Dernier point, quelque soit l’application, les pages d’administration peuvent utiliser des balises img car les moteurs de recherche n’accèdent pas dans ces pages.

Conclusion : Si vous devez changer de thème ou faire votre thème personnel, quelque soit votre application évitez les icones basées sur des balises img.

Condition : Le texte doit être délimité par une balise HTML (<span> ou une autre).

Exemple:

Quelques uns des avantages de cette astuce :

- L’absence de script assure un affichage immédiat avec les autres éléments de la page.
- Le HTML d’origine reste simple, sans aucune modification.
- S’il s’agit d’un lien, il demeure utilisable.
- Pour les moteurs de recherche, le texte étant présent c’est lui qui est analysé et référencé.
- En contre partie, l’image ne sera pas référencée.

Cas de remplacement :

Explications:

1. background:url(../../local/images/blog_entete.png) no-repeat scroll 0 0 transparent;
   Indique l’image à utiliser. Éventuellement des « class » différentes permettront de changer une image par une autre, n’abusez pas de ces changements dans vos pages pour autant ou assurez vous que le poids de celles-ci reste raisonnable.
2. display:block;
   Transforme l’affichage en ligne (inline) en affichage par bloc (block).
3. font:bold 0pt/0px Arial;
   L’élément principal de l’astuce : la police des caractères (font) aura une taille nulle et la hauteur des lignes sera également à zéro.
4. height:185px;
   Hauteur de l’image.
5. outline:0px;
   Dans le cas d’un lien, ce paramètre élimine le contour en pointillé lors du clic.
6. width:388px;
   Largeur de l’image.

Démonstrations :

Exemple concret :

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce in vehicula lorem. Morbi bibendum viverra sem id malesuada. Fusce eros velit, aliquet id fringilla at, adipiscing vitae quam. Praesent pretium malesuada egestas. Vivamus blandit aliquet quam, at pellentesque ante dignissim non. Mauris id nisi magna, eget fermentum metus. Mauris varius tristique turpis vitae dignissim. Phasellus tempor eleifend diam nec mollis! Ut ornare lorem vel augue molestie sodales. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Plus classique, le même texte avec en arrière plan une autre image (sans le paramètre font:bold 0pt/0px Arial;) :

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce in vehicula lorem. Morbi bibendum viverra sem id malesuada. Fusce eros velit, aliquet id fringilla at, adipiscing vitae quam. Praesent pretium malesuada egestas. Vivamus blandit aliquet quam, at pellentesque ante dignissim non. Mauris id nisi magna, eget fermentum metus. Mauris varius tristique turpis vitae dignissim. Phasellus tempor eleifend diam nec mollis! Ut ornare lorem vel augue molestie sodales. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Les T-E. de Piwigo étaient sensés permettre vos adaptations tout en autorisant les évolutions des templates standards. Donc de permettre d’identifier rapidement les différences. Afin que les évolutions puissent être également appliquées à vos adaptations.
Les T-E. sont ni plus ni moins que des templates qui sous certaines conditions remplacent les templates standards.

Pour identifier rapidement les différences, il aurait été nécessaire de proposer un outil de comparaison entre chaque T-E. et son template d’origine. Ceci afin que les évolutions soient rapidement prises en compte.
De l’absence de comparateur et pour la raison évoquée ci-après, nous assisterons à la fin programmée des T-E.
La logique de thème parent a tendance à se généraliser dans bon nombre d’applications et surtout elle a pris le pas sur l’orientation template de Piwigo.
Il s’en suit des incohérences entre les templates fournis par les thèmes, incohérences devenant bloquantes parfois pour certains plugins.
Prenons un exemple récent : RV Maps and Earth (un fabuleux plugin de rvelices) ne fonctionne pas actuellement avec le thème Luciano.
Même si cela sera sans doute vite corrigé, ce type d’incohérences conduit :
- soit à multiplier les plugins afin de répondre aux problématiques créées par un thème (et parfois tous les thèmes enfants) et pour s’en convaincre il suffit de chercher un plugin de WordPress;
- soit à faire évoluer le thème et vous faire perdre vos adaptations.

Si les thèmes parents/enfants se généralisent, il semble évident que les T-E. n’auront plus lieu d’être. Cependant, ceux-ci permettaient de présenter vos pages sur la base de conditions totalement originales comme une catégorie spéciale ou un lien permanent (permalink).
C’est là qu’intervient la fonction getParam().
Exemples:
- getParam(‘most_recent’) permettra de sélectionner un template particulier aux images récentes peut-être,
- getParam(‘category/Paris’) permettra d’ajouter un script particulier,
etc.

Comment coder un tel template (évolutif) dans son thème ?
Dans mon_theme/template/ par exemple pour créer un header.tpl évolutif…

Explications du code ci-dessus:
- si l’url contient recent_pics, on génèrera une bannière spécifique.
- si l’url contient un lien permanent de catégorie vers « Paris » un script sera ajouté à la page… avant le </head> (Page de miniatures et page picture).

Cette astuce permet de traiter la grande majorité des cas de figure traités par les T-E actuels de Piwigo.

En attendant, la fin programmée des T-E. les points restants en leur faveur sont:
1 – La sécurité (les curieux ne pourront pas découvrir l’emplacement de votre T-E. et, du fait, son contenu avant inclusion dans la page).
2 – La modification globale (Ajout d’éléments communs à toutes les pages et quel que soit le thème).
3 – La réduction du besoin de plugin (pour tous ceux qui ne maîtrisent pas assez le php), la modification globale (sans critère) permet de s’éviter d’avoir à coder un plugin personnel (lequel serait plus complexe à maintenir).

Pour la grande majorité des débutants, espérons que les T-E. (templates-extensions) aient la vie dure, même si leur utilisation semble complexe au début.

En comparaison, une application comme WordPress sans template vous privera des évolutions de thème, ou les évolutions effaceront toutes vos adaptations. En général les applications, qui n’utilisent pas de templates, auront beaucoup de thèmes mais ceux-ci resteront sans évolution.

Assurément, il n’y aurait pas de solution idéale.
Nous allons voir pour Piwigo comment coder un template évolutif dans un thème personnel.
Ci-dessous vous trouverez un exemple d’un header.tpl évolutif…

Explications du code ci-dessus :

{include file=’hello.inc.tpl’ assign=BANNER}
Le code html contenu dans votre thème ./template/hello.inc.tpl sera affecté à la variable BANNER (Un logo par exemple).

{assign var=HOME_BANNER value=$PAGE_BANNER|cat:$BANNER}
La variable HOME_BANNER va recevoir la concaténation (cat) de la bannière standard ($PAGE_BANNER) avec celle produite par hello.inc.tpl

{include file=’topbar.inc.tpl’ assign=TOPBAR}
Là encore, du code html contenu dans votre thème ./template/topbar.inc.tpl sera affecté à la variable TOPBAR (Des liens du site vers votre forum, votre blog, etc).

{include file= »../../default/template/header.tpl » theSwiftHeader=$TOPBAR PAGE_BANNER=$HOME_BANNER}

C’est là l’essentiel, au lieu de copier le header standard, le thème va l’inclure et ainsi profiter de ses évolutions.
Mais également la variable theSwiftHeader va prendre la valeur de TOPBAR (nos liens)
et la variable PAGE_BANNER prendra la valeur de HOME_BANNER (notre bannière avec son logo).
En incluant le header standard, le thème continuera à bénéficier des évolutions du header standard, tout en pouvant être différent.

C’est assez simple, mais surtout cela fonctionne bien.

Une seule réserve: lors de l’include du template d’origine faites attention à décrire le chemin relatif à partir de themes/xxxx/template/

{html_head}
<style type= »text/css » src= »{$ROOT_URL}themes/{$themeconf.id}/css/extension.css »} »>
{/html_head}
Ajout d’un style complémentaire ou plus avant la balise </head> (Cf. Javascript interprété inutilement)

Remarque: Cette astuce n’est qu’une application des fonctionnalités de Smarty (le moteur de templates utilisé par Piwigo)

.

Avant tout, nous allons étudier où introduire cette fonction dans Piwigo. Cette fonction pourrait avoir sa place à plusieurs endroits, essentiellement dans :
- un plugin, et plus précisément plugins/PersonalPlugin/main.inc.php (également éditable en ligne par LocalFiles Editor), ou
- un thème, et plus précisément dans un themeconf.inc.php (mais ceux-ci ne sont pas éditables en ligne à ce jour).

Avec de bons arguments, je considère que sa place est dans le themeconf.inc.php, car l’appel de cette fonction concerne l’affichage final.
Si nous placions cette fonction dans un plugin, il ne faudrait jamais perdre de vue que le plugin devrait rester actif.
En le plaçant dans la configuration du thème, nous n’aurons qu’à créer des templates sur lesquels nous souhaitons agir différement.

Exemples dans un thème personnel.

dès lors dans themes/mon_theme/include/functions.inc.php

Ensuite il suffira de copier et de modifier les templates standards que l’on souhaite modifier venant de themes/default/template/ dans themes/mon_theme/template/
par exemple: thumbnails.tpl afin d’y remplacer

par

Ainsi le nombre de commentaires ne sera plus indiqué que sur les pages de catégories. Ce nombre ne figurera donc pas dans les résultats de recherches, les pages de miniatures découvertes par les tags, ou les pages des catégories spéciales.

Autre exemple, picture.tpl afin d’y remplacer

par

Et cette fois, il ne s’agira pas du nombre mais des commentaires eux-mêmes qui ne seront pas affichés sur la page picture dès lors que l’image n’est pas présentée au travers de sa catégorie.

Ces 2 exemples simples de l’utilisation de getParam() ne sont que des préludes à d’autres usages également très intéressants que nous découvrirons prochainement.

Avant de l’utiliser, je me propose une explication minimaliste.
Cette fonction PHP fait appel à un preg_replace et une expression rationnelle.
L’objectif est de conserver uniquement les caractères comme le point, la virgule, les 2 tirets (- et _), les lettres (minuscules ou majuscules, mais pas les lettres accentuées) et les chiffres.
Par exemple, supposons que nous ayons ceci :

alors nous devrions avoir en retour :

Quel 1er_paramtre   Un argument

L’intérêt sera de sécuriser votre site lors de l’appel à cette fonction.

Découvrir la mise en œuvre de cette fonction.