S’affranchir des templates-extensions

Piwigo par le biais de son prédécesseur PhpWebGallery avait intégré un principe assez mal compris, celui des templates-extensions (T-E.).
Le principe était alors simplement décrit et devait encore être codé, ce que j’ai réalisé dans Piwigo 2.0.

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…

{if getParam('recent_pics')}
  {include file='recent.tpl' assign=RECENT_BANNER}
  {include file="../../default/template/header.tpl" PAGE_BANNER=$RECENT_BANNER} {* le path doit être relatif depuis themes/mon_theme/template/ *}
{else}
  {include file="../../default/template/header.tpl"}
{/if}
{if getParam('category/Paris')}
{known_script id="jquery" src=$ROOT_URL|@cat:"themes/default/js/jquery.packed.js"}
{known_script id="topbar" src=$ROOT_URL|@cat:"local/js/topbar.js"}
{/if}

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.

10 thoughts on “S’affranchir des templates-extensions

  1. les template extensions perdureront justement pour les points 2 et 3 que tu as cités car ils sont très pratiques et simples d’utilisation. Je prédis ainsi une multiplication des t-e sur PEM…

  2. Le problème compatibilté thèmes/plugin a toujours été une problématique -à laquelle je suis actuellement confronté pour mes maj de plugin- et est un point névralgique que les CMS ont plus ou moins bidouillé des solutions

    1. Les T-E. ne devraient pas résister très longtemps.
      PEM (le gestionnaire de download de Piwigo) verra peut-être quelques T-E. je n’y crois pas trop.
      Par contre, PEM devrait reprendre cette logique pour gérer:
      – les thèmes
      – les plugins
      – les traductions
      etc.

      Je n’ai pas dit que le problème n’existait pas ailleurs, je pense que les T-E. représentent une bonne réponse actuellement.

  3. Certes les T-E sont difficilement partageables, j’avais fait un test avec une page ‘picture’ spécifique dans le style du thème Luciano.
    Par contre les T-E me sont très utiles pour personnaliser des fonctions sans utiliser de plugin.
    Insertion du copyright, du code pour analytics ou pour des optimisations (regroupement de Css ou de JS) en fonctions du thème choisi.
    J’espère qu’ils resteront longtemps disponibles dans le ‘core’ de Piwigo.

  4. perso j’ai dans mes cartons le projet de distribuer des templates extensions qui ne styleront que des parties précises telles les miniatures, le bloc commentaire ….

  5. Vu de ma fenêtre de développeur assez occasionnel, les template-extensions ont tout de même 2 gros inconvénients :

    – ils utilisent Smarty, langage qui reste encore assez ésotérique pour moi : c’est un langage de plus et, surtout, Piwigo est le seul de mes « outils habituels » qui y fasse recours (Contao et WordPress ne nécessitent que PHP) ; le peu d’occasions de pratiquer constitue un frein non négligeable à son utilisation.

    – ils restent mono-thème, ce qui constitue un inconvénient majeur lorsqu’une galerie utilise plusieurs thèmes.

    1. Premier point – Je suis assez d’accord même si les balises Smarty sont simples.

      Sur le second – Je le suis beaucoup moins.
      Lors du choix côté Administration du remplacement des templates d’origine par vos templates personnalisés issus du dossier template-extension, seul le nom du templates d’origine est obligatoire, le paramètre de l’URL et le thème rattaché sont facultatifs (Cf. l’aide en ligne même si elle n’a pas été corrigée avec la 2.1 – ceci prouvant l’avenir probable des T-E. Dans l’Aide, lire parfois Thème au lieu de template), je cite :

      Si vous sélectionnez un Template rattaché alors les remplacements ne seront réalisés que sur ce template.

      Ceci dit du fait que les templates sont devenus des éléments des thèmes, il devient plus complexe d’imaginer qu’un template puisse être adapté à tous les thèmes.
      Ce qui manque encore au système des thèmes c’est d’avoir un template commun à tous, pour des scripts type Google Analytics.

      1. Merci d’avoir attiré mon attention sur le fait qu’un template-extension pouvait ếtre utilisé par tous les thèmes, à condition de ne pas indiquer de thème rattaché.
        Je n’avais pas identifié cette possibilité.

  6. Sinon ce serait bien de trouver une manière globale de modifier des tpl en rendant ça pérenne : il faudrait certainement de la manipulation de string via php … ça m’a l’air faisable mais y en a qui ont plus de temps que moi pour coder et écrire des articles…. #regardeenl’air

    1. Gotcha propose l’usage de pré-filtres.
      Je n’aime pas vraiment car cela complexifie le support, le rendant quasiment impossible.

Comments are closed.