Argument _ des appels XHR au js calendar

#3 (closed) ne règle probablement pas tout : on m'indique que « côté JS, les appels XHR par le fullcalendar sont de la forme spip.php?page=agenda.json&start=2021-06-28&end=2021-08-02&_=1634627112097. On y retrouve le _= avec un timestamp. C’est une feature de jQuery pour éviter de tomber dans les caches navigateur et s’assurer qu’une version à jour du json sera chargée, mais c’est un problème car cela provoque le calcul d’un nouveau cache à chaque fois. Il faut modifier l’appel pour passer par exemple un var_t=… car SPIP ignore les paramètres d’url commençant par var_ dans la signature du cache (ça se paramètre quelque part dans le jQuery ou dans l’appel à fullcalendar, et de ce que je vois dans le fullcalendar de l’espace privé on l’a carrément supprimé, mais il est bien de le conserver dans le site public). Ça impacte pas les json en cache fichier, mais ça impacte le fait que les jsons utilisés pour l’agenda ne sont jamais en cache SPIP (ou plutot on calcule un nouveau cache SPIP à chaque fois). On a donc des hits couteux car pas en cache, et en plus on pollue le cache SPIP car on le rempli de json qu’on réutilisera jamais » (merci !)

En effet la navigation ajax du fullcalendar se fait avec urls qui ont un argument _ timestamp ajouté. C'est documenté là : https://fullcalendar.io/docs/v3/events-json-feed#caching et ça vient de la méthode ajax() de jQuery https://api.jquery.com/jQuery.ajax

• On ne peut pas renommer cette variable via l'API js, mais on peut demander à ce qu'elle ne soit pas ajoutée pour autoriser le recours au cache navigateur + vérifier si le raffraîchissement est assuré quand il faut.
• Ou peut être on peut la renommer var_t via SPIP pour qu'elle n'empêche pas le recours au cache ?