VDigital's

Niveau: Débutant+.

Repousser les limites des fonctionnalités standards de Piwigo, c’est le rôle de l’extension de modèles (extension de templates).

Le principe :

L’apparence standard d’une page de votre galerie ne vous plait pas? Sans dupliquer la totalité du template, vous pouvez en quelques minutes changer son aspect, son mode de présentation.

Prenons Subcatify (une logique proposée en 2005 par Thierry, devenue rapidement optionnelle, et aujourd’hui un standard). Un paramètre de configuration pour désactiver ce mode de fonctionnement ($conf['subcatify']) était disponible. Actuellement, ce paramètre n’est plus reconnu.

Problème :

Comment proposer des catégories sous la forme de simples miniatures?

Solution :

1. Activer si ce n’est déjà fait le plugin LocalFiles Editor.
2. Depuis l’onglet “Template” cliquez sur “Créer un nouveau fichier”
3. Nom du fichier “TN-categories.tpl” par exemple.
4. Collez ceci:
   <ul class="thumbnails">
{foreach from=$category_thumbnails item=cat}
<li>
<span class="wrap1">
<span class="wrap2">
<a href="{$cat.URL}">
<img class="thumbnail" src="{$cat.TN_SRC}" alt="{$cat.TN_ALT}"
title="{$cat.NAME|@replace:'"':' '} - {'hint_category'|@translate}" />
</a>
</span>
<span class="thumbLegend">
{$cat.NAME}
{$cat.ICON_TS}
</span>
</span>
</li>
{/foreach}
</ul>

5. Enregistrez votre nouveau template.
6. Activez la substitution du template d’origine par votre nouveau template (Admin > Configuration > Templates (Modèles)).
• Remplaçants (templates modifiés) : TN-categories.tpl
• Templates d’origine : mainpage_categories.tpl
• Paramètre facultatif de l’URL : laissez vide (pour l’instant)
• Template rattaché : yoga
7. Validez et redécouvrez votre galerie.

Vous pouvez n’utiliser ce modèle que pour une partie de votre galerie.
Le “Paramètre facultatif de l’URL” vous le permettra.

À la catégorie parente (“Catégories taille S”), un lien permanent “size_S” a été associé. Ce dernier présent dans l’URL permet d’activer le template proposé ci-dessus uniquement pour cette catégorie.

Ainsi dans “Catégories taille S”, vous trouverez 2 catégories d’une image chacune (inversées), présentées sous forme de 2 miniatures (en mode paysage), et également 2 miniatures d’images (en mode portrait).

Désactiver Subcatify

Cet exemple est à l’opposé des Miniatures en XXL dont j’aurai bientôt l’occasion d’expliquer le principe.

‘Once upon a time’, il était une fois une solution (basée sur un plugin personnel) pour arrêter de simuler.

Ce principe est toujours valable à la syntaxe près mais la bonne question est en fait: « Pourquoi faire ça avec un handler? ».
add_event_handler('loc_begin_page_tail', 'personal_sync_not_simulate');

Avant à chaque pied de page, la fonction était appelée via le système de plugin, et dans le traitement on se posait des tas de bonnes questions:
- Est-ce qu’on est en Admin?
- Est-ce qu’on est sur la page de sychro?
- Et là on ajoutait le script…
Le tout en utilisant des fonctions assez simples mais ne serait-ce que le add_event_handler, c’est quand même: des tests, une boucle, un tri, …

Solution:
LocalFiles Editor > Onglet Langues (Choisir votre langue habituelle).

<?php
global $lang;
 
 
if (isset($lang['update_simulate']))
  $lang['update_simulate'] .= '<script type="text/javascript">
  document.getElementsByName("simulate")[0].checked = false;
</script>';
 
 
?>

Une solution insufflée par vimages (Eric est peut-être l’utilisateur de Piwigo le plus avancé sur bien des plans).

Bonnes synchronisations mais sans simulation.

(Notez que cette solution était également valable avec PhpWebgallery 1.7.x).

Synchronisation:

Processus visant à collecter les informations des images incorporées ou supprimées par FTP sur le serveur, et surtout d’actualiser la base de données avec les nouvelles informations (présence des images, taille des images, poids, données IPTC, …).
Les « uploads » (ajout d’images) par les visiteurs par le protocole HTTP seront également synchronisées dès lors que leurs miniatures sont présentes.
Les images transférées par pLoader ne sont pas concernées par ce processus.

Niveau: avancé.

Le plugin «personnel» va évoluer et passer au service de l’économie de code. Il sera plus simple et probablement il redeviendra une source d’idées nouvelles afin de nous permettre d’identifer les fonctions de Piwigo que nous devrons externaliser.
Lire l’article: « Economie de plugins »

Reprenons le même exemple, mais cette fois je vous invite à refaire la démarche inverse.
Nous avions obtenu:
{php}
global $user;
$this->assign('USER_LEVEL', $user['level']);
{/php}
{if $USER_LEVEL >= 1}
Vous avez été reconnu par le webmaster comme une personne ayant plus de droits que d'autres...
{/if}

Première remarque assez gênante:
La présence de {php}, alors que nous souhaitons séparer le code php du code html.

Seconde remarque:
L’ “assign”, alors que le template n’a que faire de cette nouvelle variable, hormis la tester une seule fois. Pourquoi être dans l’obligation de créer une variable?

Ceci nous conduit à éliminer l’handler certes mais également l’assign.
Solution: “LocalFiles Editor” (Merci P@t), onglet “Plugin Personnel”
if (!function_exists('permission_level')) {
function permission_level() {
global $user;
return $user['level'];
}
}

Et dans son template on ne code plus que ceci:
{if permission_level() >= 1}
Vous avez été reconnu par le webmaster comme une personne ayant plus de droits que d'autres...
{/if}

Quelque part, Smarty nous invite à réinventer la roue puisque dans une application sans moteur de template, nous coderions:
<?php
if (permission_level() >= 1) { ?>
Vous avez été reconnu par le webmaster comme une personne ayant plus de droits que d'autres...
<?php
} ?>
(Ce dernier exemple ne fonctionnera pas avec Piwigo).
Voire même encore plus simple. De toute façon, la séparation code php et code html s’en trouveraient fortement lésée.

Or l’important est de bien simplifier les deux langages et limitant surtout la présence de code php dans le code html (et lycée de versailles, cela va de soi).

Quelques règles :

1 – Publier: “assign” dans le template, quand une donnée est facile à atteindre mais non prévue, et que son contenu est à publier.
2 – Tester: “Appel d’une fonction” dans le template, quand cette fonction n’est pas sollicitée plusieurs fois, que cette fonction s’intègre dans un if (par exemple), et surtout que la valeur retournée n’a pas besoin d’être publiée.
3 – Accéder aux tables, parsing d’autres templates, …: Plugin.
4 – Enfin, pas des moindres: se relire!

Ce que l’on souhaite, c’est de livrer quelque chose de simple, lisible et performant.

Passez maître en économie! Moins j’en écrit, moins je fais de “fôtes”.

Patrice, dit P@t pour les intimes, nous offre un merveilleux site essentiellement sur la Nouvelle Calédonie.
Par ailleurs, il partage ses solutions à base de Plugins et nous l’en remercions pour ses accords parfaits.

Pour autant, il n’est pas vain de comprendre comment faire l’économie d’un plugin dit «personnel» et pour ce faire, nous prendrons un exemple proposé par P@t.

Bien entendu, cela ne sera pas toujours aussi évident et il ne faut surtout pas appliquer cette solution de façon systématique. Dès lors que vous avez des requêtes SQL, il sera préférable de choisir une solution par plugin.

Exemple proposé par P@t:

add_event_handler('init', 'assign_template_permission_level');
function assign_template_permission_level()
{
global $user, $template;
$template->assign('USER_LEVEL', $user['level']);
}

et dans le template:

{if $USER_LEVEL >= 1}
Vous avez été reconnu par le webmaster comme une personne ayant plus de droits que d'autres...
{/if}

C’est effectivement très simple. Qu’à cela ne tienne !
C’est tellement simple que tout ceci peut très bien être réalisé directement dans le template…

{php}
global $user;
$this->assign('USER_LEVEL', $user['level']);
{/php}
{if $USER_LEVEL >= 1}
Vous avez été reconnu par le webmaster comme une personne ayant plus de droits que d'autres...
{/if}

Moins d’«handler», moins de conflits et d’erreurs. C’est encore plus simple.
Je n’explique pas toutes les justifications techniques mais assurément aujourd’hui, c’est bien la direction à prendre pour éviter le plat de spaghettis (ou sans le ’s’ à l’italienne) à la sauce plugins.

Qu’on se le dise! Mais qu’on ne se le tienne pas pour dit, enfin au moins, cette fois c’est écrit!

«Whois Online» est un plugin d’information sur les visites d’une galerie Piwigo.

Dans PhpWebGallery (version précédente de Piwigo), pour offrir des indications sur les visites observées, j’avais développé un plugin basé sur l’historique des visites de la galerie.
Malheureusement la volumétrie de l’historique croit, et toute requête devient vite pénalisante pour le serveur MySQL.
Pour que le plugin fonctionne, nous devions activer l’historique. Le provider Free s’était empressé de faire la chasse aux historiques en base de données, condamnant ainsi ses clients à ne plus pouvoir afficher ces indications.
Dans une optique radicalement opposée, j’ai donc conçu «Whois Online».

Une petite table, épurée régulièrement, devient donc la clé de voûte du plugin.

La structure (sans entrer dans les détails):

1. La session php.
2. La première (ou dernière) adresse IP (connue).
3. L’identifiant de l’utilisateur.
4. Son pseudo.
5. La langue utilisée.
6. La permanence de ce suivi (‘false’ par défaut).
7. Le time() php du dernier accès.
8. Les 10 derniers ids utilisés via picture.
9. Les 10 derniers ids de catégories présentées via index.
10. Les 10 derniers ids de tags présentés par picture.
11. Les 10 derniers ids de recherches présentés par picture.
12. La date du premier accès connu.
13. Les hits sur picture.
14. Les hits sur picture/index.
15. etc.

À savoir: Un enregistrement global conserve le nombre de hits par minute (10), par tranches de 5 minutes (12), par heures (24), et par jour (14).
À l’activation du plugin, la table est crée si elle n’existe pas déjà.
À la désactivation, la table est supprimée sauf si elle est protégée (Option par défaut, modifiable en configuration).
À chaque visite de l’index ou de picture, (Événements “loc_begin_index” et “loc_begin_picture”) le plugin met à jour la table, prépare les informations, et (suivant les options en configuration) il affiche ou non les éléments d’information.

Les visites (Hits) des pages Comments, Tags, Search, Notification, Identification et autres ne sont pas comptabilisés.
Nous présentons une galerie ne l’oublions pas.

Vous pouvez configurer le plugin en sachant que pendant les 24 premières heures, les informations affichées seront incomplètes (il n’y avait rien avant).
Au-delà de 24h, vous pouvez afficher les informations que vous souhaitez. Vous pouvez ne pas afficher les données par le plugin mais par votre template extension. Voir le template fourni, default.tpl, pour un exemple d’utilisation des variables {$Whois.xxxx}.
À lire l’article : « Whois Online : côté template ».
Vous devez encore savoir que le nombre de hits des images est calculé au départ sur la base des hits connus dans la table images. Par contre pour le total des pages d’index et le total, il s’agit d’estimations (respectivement 70% et 170% du nombre de hits des images).

«Whois Online» propose une solution d’affichage des indications obtenues (Cf. Les grandes lignes). Pour autant, vous désirez peut-être insérer ailleurs quelques uns de ces éléments. À la surprise générale, vous n’obtiendrez aucun élément dans certains cas. En effet, il se peut que votre template soit traité avant l’appel de «Whois Online», et dans ce cas, vous ne pourrez pas afficher ces indications. Exemple: La page about.php (A propos) ne sollicite pas le plugin, et elle ne peut pas afficher ces indications. En supposant que votre template soit analysé et résolu après l’appel du plugin, vous pourrez coder celui-ci de la façon suivante: <balise attribut="valeur">{'Exemple d\'utilisation :'|@translate} {$Whois.indication}</balise> {$Whois.indication} est un exemple, et à la place de “indication” vous avez le choix suivant:

En complément, vous avez également {$Online.xxxxxxx} et comme pour {$Whois.xxxxxx} vous pouvez activer le plugin standard “Multi view” qui permet lancer la “Smarty Debug Console”. A l’aide de cette dernière, vous pourrez retrouver toutes les variables disponibles à l’issue du traitement de chaque page.

La table mémoire du plugin Whois Online est épurée régulièrement.

Une fois toutes les 7 sollicitations, suivant la taille de la table, le plugin tentera de réduire le nombre d’enregistrements de la table. Certains enregistrements pourront être effacés dès lors qu’ils sont présents depuis plus de 72 heures sans accès ou que la permanence ne sera pas prévue (’false’ par défaut).

Par défaut, si le nombre d’enregistrements à effacer est supérieur à 20, et si ce nombre représente plus de 20% de ceux à conserver alors dès la septième sollicitation suivante l’effacement sera réalisé.

Autrement dit :
- L’enregistrement global ne sera jamais supprimé (hits par minutes, 5 minutes, heures, et jours).
- Les enregistrements des visiteurs récents (moins de 72 heures) ne seront pas supprimés.
- Les enregistrements protégés (Webmaster, Admin, … selon vos choix) resteront dans la table (permanence).
- Les sites ayant peu de visiteurs ou ayant des membres régulièrement connectés ne devraient pas ressentir de ralentissements du fait d’une épuration à priori exceptionnelle.
- Les sites très sollicités par un grand nombre de visiteurs différents devraient avoir un lissage de l’épuration. D’une part, l’épuration ne devrait pas être systématique (une fois sur sept), et d’autre part, en configurant le plugin les webmaster pourront adapter le seuil de déclenchement:
(Nombre d’enregistrements permanents et/ou d’accès de moins de 72 heures) + 20%
Ces 20% seront paramétrables (10% à 200%).

Exemple sans déclenchement :
- 5 enregistrements permanents + 95 visiteurs très récents.
Il faudrait en standard avoir “n” enregistrements pour déclencher…
Imaginons que nous avons 50 visiteurs de plus pendant les 3 prochaines heures.
Combien faudra-t-il avoir d’accès ayant plus de 72 heures sans retour du visiteur?
( 5 + 95 + 50 ) x 20% = 30 et en dessous: PAS DE DÉCLENCHEMENT.

Exemple de déclenchement :
- Durant les 3h suivantes, 40 visiteurs dépassent les 72 heures sans activité, nous avons également 10 visiteurs récents en plus, reprennons:
95 (du départ) + 50 (des 3 premières heures) + 10 (nouveaux) + 5 (permanents):
Nous sommes à 160 accès connus dont 40 à supprimer. Combien avons-nous d’actifs? (160 – 40) = 120
Les 40 accès à supprimer représente donc 33% des actifs soit plus de 20%.
Et 40 accès à supprimer c’est également plus que les 20 accès du seuil fixe. Le déclenchement se réalisera si ce n’est pas déjà fait durant les 7 prochains accès.

Dans la pratique, l’épuration ne se réalisera que rarement en période de forte sollicitation du site (toujours trop d’utilisateurs récents), mais elle intervient en début de reprise après une période de faible activité du site. Puis une fois par heure, au moment du passage d’un certain nombre de visiteurs au moins à plus de 72 heures d’inactivité.

Le seuil en % (20% par défaut) pourra être modifié via l’icone (Admin > Spéciale > Historique) par :
Seuil de nettoyage [10-200] (rapport entre données obsolètes et actives)

Tandis que le seuil fixe (20 par défaut) pourra l’être par :
Limite d’inactifs [20-100] (nombre maximum d’anciens enregistrements)

Niveau: Moyen
Je ne sais jamais où conserver les liens utiles au site.
Exemples:
L’adresse de la home page de mon Provider, mon url de PhpMyAdmin, Paypal, Google Analytics, Google Adsense, … Certains de ces liens n’ont pas besoin d’être publiés ailleurs qu’en Admin.

L’objectif de cet article est de vous montrer qu’en quelques secondes vous allez pouvoir les enregistrer.

Remarque: le plugin LocalFiles Editor doit être activé.
Administration > Spéciales > LocalFiles Editor > Onglet “Langues”
Choisissez votre langue: Français (FR) [Edit]
Pour notre exemple, j’ajoute ceci:


$lang['FORUM'] = 'Support</a></li>
<li class="external"><a class="external" href="http://www.vdigital.org/sharing/" onclick="window.open(this.href, \'\'); return false;">VDigital\'s';

Explications:
Normalement dans admin.lang.php, vous trouvez ceci:

$lang['FORUM'] = 'Support';

Dans le template d’Admin, nous trouvons

<li><a ... >{'FORUM'|@translate}</a></li>

@translate va remplacer ‘FORUM’ par sa traduction.
La traduction est réalisée en fonction du langage utilisé par admin.lang.php.

Cependant cette traduction peut être contre-carrée par la version locale de la langue.
LocalFiles Editor Plugin est l’outil idéal pour modifier ce fichier.

Oui mais dans la traduction rien ne vous empêche de:

• traduire 'FORUM',
• et d’ajouter autant de fois que nécessaire:
• la fermeture des balises HTLM encore ouvertes (</a></li>)
• ouvrir un autre lien (<li …><a …>VDigital\'s)

Ne fermez pas les dernières balises (la fermeture déjà prévue de 'FORUM' s’en chargera).
Ces liens seront pratiques pour référencer vos sites techniques préférés ou d’autres sites privés.

Quelques hébergeurs (comme OVH ou Infomaniak) proposent l’option MultiViews.

À vérifier: Accédez à une de vos images par la page picture.php. À partir de l’URL indiquée dans la barre de votre navigateur, enlevez “à la main” l’indication .php et faites “Entr(er)”. Si cela fonctionne, vous pourrez continuer.

Pour les serveurs Apache, vous allez créer votre fichier .htaccess (au niveau du répertoire racine de votre site ou à défaut de votre répertoire Piwigo).
Il vous suffira de coder ceci:

Options +Multiviews

Alors depuis l’Administration > Spéciale > LocalFiles Editor
et l’onglet Configuration, vous ajouterez ceci:

$conf['php_extension_in_urls'] = false;

Vos adresses en seront, je veux le croire, beaucoup plus sympathiques !!!