La fonction introduite par ce plugin est similaire au principe d’Ajax Parallel Loading introduit dans Zpip, tel que décrit ici. La méthode de fonctionnement est cependant différente, et surtout ce plugin est destiné à être utilisé dans n’importe quel jeu de squelettes (non Zpip, donc).
Il ajoute un critère, {ajaxload}, à la balise #INCLURE, par exemple :
- [(#INCLURE{fond=inc/footer}{id_rubrique}{ajaxload})]
Au lieu d’insérer dans le code source de la page le contenu de inc/footer avec la variable d’environnement id_rubrique, le critère {ajaxload} modifie complètement le fonctionnement : seul un lien hypertexte doté d’un code spécifique est inséré dans la page. À l’affichage de la page chez le visiteur, une fonction Javascript charge dynamiquement le contenu nécessaire et l’insère à l’endroit prévu.
Il est impératif d’utiliser #INSERT_HEAD dans le squelette appelant (le code Javascript nécessaire au bon fonctionnement est alors inséré dans la page).
Quelques remarques :
• seuls les critères spécifiés dans l’appel #INCLURE sont passés à la page appelante ; si ces critères sont communs à plusieurs pages, on bénéficie ainsi du chargement d’éléments communs à ces pages (cache navigateur) ;
• si Javascript est désactivé chez le visiteur, une version fonctionnant sans Javascript est activée ;
• de manière automatique, les moteurs de recherche se voient proposer le contenu complet (identique à la version sans Javascript), ce qui leur permet d’indexer correctement les pages et de profiter de la navigation du site ;
• attention, ne pas insérer dans ces morceaux chargés dynamiquement des publicités ou des compteurs de visites (notamment Google), qui « écrivent » via Javascript, ce qui généralement provoque un affichage de page blanche ; plus généralement, éviter les chargements Ajax à l’intérieur de ces éléments chargés dynamiquement, ils deviennent difficiles à maîtriser.
Méthode alternative : chargement d’un fichier statique
La version 0.7 du plugin introduit une nouvelle méthode : l’inclusion dynamique de fichiers HTML parfaitement statiques. La méthode « normale » fonctionne sur la base des « noisettes Ajax » de SPIP : les fichiers inclus sont donc bien pages SPIP dotées de toutes les caractéristiques habituelles (notamment la possibilité d’avoir du contenu dynamique).
La méthode alternative permet d’inclure non des pages SPIP, mais des petits fichiers HTML statiques, stockés (brutalement...) dans /local/cache-ajaxload.
Pour cela, le critère devient :
- <code>{ajaxload=html}</code>
Dans ce cas, au calcul de la page, la noisette est immédiatement calculée, et son contenu est stocké « en dur » dans /local/cache-ajaxload. Au chargement de la page, c’est ce fichier HTML qui est directement inséré dans la page.
Pour les visites des robots de moteurs de recherche ou sans Javascript, ce sont ces morceaux « statiques » qui sont directement inclus.
L’avantage principal de cette méthode est que ces fichiers sont appelés « hors SPIP », et même hors PHP. Ce sont des fichiers HTML entièrement statiques. On gagne en vitesse et en charge du serveur. Il est très probable également que la visite du site par un robot de moteur de recherche soit beaucoup moins lourde pour le serveur avec cette méthode.
L’inconvénient, c’est que ces fichiers sortent totalement de SPIP :
— ils sont totalement statiques, et ne doivent donc contenir aucun élément dépendant d’une #SESSION, du statut du visiteur, ni code PHP non précalculé (tel que l’affichage de l’heure ou de l’IP du visiteur) ;
— le système n’interroge pas la durée du cache selon la méthode SPIP ; la durée de vie d’un tel fichier est fixée par défaut à 2 heures ; on peut forcer une autre durée, dans l’appel, avec un critère supplémentaire (ici : 24 heures) :
- <code>{ajaxload=html}{ttl_ajaxload=60*60*24}</code>
L’appel du footer pourrait donc se faire, avec cette méthode, ainsi :
- [(#INCLURE{fond=inc/footer}{id_rubrique}{ajaxload=html}{ttl_ajaxload=60*60*24})]
Pour les ceusses qui se la pètent en Javascript
Deux méthodes avancées sont destinées à ceux qui voudraient gérer eux-mêmes les appels Ajax (pas de chargement automatique par ce plugin, donc, mais « à la demande » selon du code développé par le webmestre lui-même). Ces méthodes retournent directement l’URL du fichier qui contient la noisette, à charge pour le créateur du site de savoir comment il souhaite les utiliser :
— {ajaxload=url} retourne l’URL de la noisette dynamique ;
— {ajaxload=url_html} retourne l’URL du fichier HTML statique.
Utiliser l’inclusion ESI de Varnish
Pour le #INCLURE fonctionne directement via l’inclusion ESI de Varnish, utiliser le méthode {ajaxload=esi}.
Évolutions
Version 0.5. Les inclusions {ajax}{ajaxload} conservent désormais le fonctionnement du {ajax}. On peut donc ainsi charger des éléments paginés (la pagination Ajax fonctionne à nouveau).
Version 0.6. Meilleure gestion du <meta refresh>, notamment dans le cas de passage des robots.
Version 0.7. Introduction de la méthode {ajaxload=html} et du critère {ttl_ajaxload=60*60*24}.
Version 0.8. Divers bugs corrigés concernant la navigation sans Javascript et sans cookies.
Version 1.0. Ajout des méthodes {ajaxload=url} et {ajaxload=url_html}.
Version 1.1. Insertion plus fine du code du <meta refresh>, uniquement dans les pages où il est nécessaire. (En revanche, l’insertion du Javascript reste systématique, de façon à ne pas changer, d’une page à l’autre, le fichier Javascript créé par le compactage de SPIP.)
Version 1.3 Ajout de la méthode {ajaxload=esi}.
