Warning: Use of undefined constant INCLUREAJAXLOAD_affichemeta - assumed 'INCLUREAJAXLOAD_affichemeta' (this will throw an Error in a future version of PHP) in ecrire/public/composer.php(96) : eval()'d code on line 157

Reprise du code de `balise_INSERT_HEAD_dist()`

retrait du `plugin.xml`, renommage du fichier d'options et ajout des balises nécessaires pour les pipelines

(googlebot est assez malin désormais pour venir tout indexer meme avec le js et le rel=nofollow)

il peut y avoir des pipes dans la querystring. Par exemple https://fr.wikipedia.org/w/api.php?action=query&format=json&titles=Aaata&continue=&redirects=1&meta=siteinfo|wikibase&prop=revisions&rvprop=content

Quand il y a changement de version, il faut faire un z+1 minimum pour que ceux qui utilisent le plug le sache :-)

Gestion de _SPIP_LIER_RESSOURCES: si true, alors ajoute des <link href=‘’> faciliter aspiration du site:
define("_SPIP_LIER_RESSOURCES", true);

(Je suppose que c’était un bug…) Le plugin ajoutait des <?xml version='1.0' encoding…?> à tout bout de champ. Si j’ai bien compris, ça faisait foirer l’affichage sous IE8 (possiblement IE9) des pages HTML5 (qui ne sont plus strictement XML).

Spip 2.1 ne connaissant pas la signification de *, il faut mettre 99, les * 'est uniquement quand les plugins ne sont que pour spip 3.0 et/ou spip 3.1

Version 1.3: ajoute la méthode {ajaxload=esi}, qui transforme l’inclusion en inclusion ESI de Varnish.

Quand ESI est bien activé dans Varnish, il n’y a donc plus du tout de chargement Ajax.
En revanche, si ESI n’est pas activé dans Varnish, ça redevient un ajaxload classique – attention, c’est un fall-back: le refresh vers no_ajax de la page est alors désactivé, parce que le fonctionnement normal de cette méthode, c’est tout de même l’inclusion ESI.

On donne egalement la possibilité d'indiquer un message de chargement textuel {ajaxload_message=Chargement de la page} qui s'affiche à la suite de la roue, dans une classe .ajaxload_message

Évolution du plugin inclure-ajaxload en encapsulant le javascript dans une fonction, que l'on rappelle elle-même lors d'un chargement ajax : de la sorte si une inclusion {ajaxload} est chargée dans un squelette lui-même ajouté en ajax (par exemple avec l'ajax parallèle des blocs de ZPIP), l'inclusion sera réellement faite. 

Pour éviter une récursion, les classes .includeajax et .includestatic sont renommées lorsque le js les a traitées. On les suffixe de _load pendant le chargement, et de _loaded une fois le chargement réalisé.

N'ajouter le filtre d'analyse de la page pour détecter le changement avec NO_JS que si l'on rencontre un INCLURE avec {ajaxload}.

Cela évite de casser des tests [(#INCLURE{fond=x/y}|trim) y a du contenu... ] car ils pouvaient avoir le filtre à destination du  header d'ajoutés.

Cependant je n'ai peut être pas suivi correctement le mécanisme et si cette modification pose problème il faudra trouver une autre correction ou revert. J'ai l'impression que ça fonctionne... mais bon...

inclure les autres librairies a la suite de jQuery sinon il est necessaire d'utiliser jQuery.noConflict(); )

N'inserer le traitement des cookies no_js que si la page contient du includeajax ou includestatic. (J'aimerais bien ne pas le faire via affichage_final, cela dit...)

Nouvelles méthodes pour récupérer les URL des noisettes: {ajaxload=url} et {ajaxload=url_html}. Pour les ceusses qui veulent gérer leur Ajax à la main.

Simplification du meta refresh, et passage à 2 secondes. (Eviter que les bots prennent le refresh pour une redirection - mais theoriquement, les bots ne voient pas le meta...)

Ajout d'une nouvelle methode: {ajaxload=html} (la noisette ajax est alors un pur fichier HTML statique, traité hors SPIP).