Recherche avancée

Sur d’autres sites (9951)

• Anomalie #3239 : _CACHE_CONTEXTES_AJAX génère un dossier /tmp/cache/contextes qui grossit à l’infini

  22 avril 2020, par RastaPopoulos ♥

  Et donc comme vu sur la liste, ça s’est reproduit 6 ans plus tard (entre temps le disque a dû être beaucoup augmenté par l’hébergeur et donc ça ne s’est pas vu pendant longtemps, mais fatalement ça revient).
  Et cette fois avec 47Go… (et sûrement des millions, dizaines de millions, de fichiers).

  @marcimat quand tu dis "la solution intermédiaire qu’on utilise" c’est qui "on" ? C’est désormais SPIP 3 qui fait déjà ça tout seul ? et donc ya pas besoin d’une autre constante pour faire ça "seulement quand il y a besoin" comme le disait Cédric sur la liste, puisque c’est déjà le cas ?

  Sauf que sans la constante, yavait vraiment des pages qui marchaient pas, le site est en SPIP 3 depuis le tout début, donc c’est bien en SPIP 3 qu’il y avait des problèmes d’URL trop longues aussi. Donc c’est pas mis en cache automatiquement comme tu le décris non ? Je suis pas sûr d’avoir tout pigé.

  (je mets en "haut" car c’est un bug qui lorsqu’il apparait, pète le système de fichiers, donc c’est gros quand même)

• Anomalie #4501 (Nouveau) : js.cookie : message de warning dans la console avec les options par défaut

  2 juin 2020

  SPIP 3.3-dev + Firefox 76

  Depuis quelques temps dans firefox je vois apparaître le message d’erreur suivant lorsque je change le mode d’affichage des documents :

  Le cookie « affichage-illustrations » sera bientôt rejeté car son attribut « sameSite » est défini sur « none » ou une valeur invalide, et sans attribut « secure ». Pour en savoir plus sur l’attribut « sameSite », consultez https://developer.mozilla.org/docs/Web/HTTP/Cookies

  C’est apparemment le cas dès qu’on pose un cookie avec les options par défaut, sans préciser secure ou sameSite : https://git.spip.net/spip/medias/src/branch/master/javascript/gestion_listes_documents.js.html#L39
  

  Cookies.set(’foo’, ’bar’)
  

  Au début je pensais que ça voulait dire que les cookies non sécurisés ne fonctionneraient plus du tout dans les prochaines versions des navs, mais en fait ça à l’air plus bénin (cf. explications dans le ticket ci dessous). Par contre c’est tout de même un peu embêtant d’avoir ces messages qui polluent la console.

  Il y a un ticket d’ouvert à ce propos dans le dépôt de la lib, et le problème semble résolu dans les dernières versions : https://github.com/js-cookie/js-cookie/issues/620

  Adding sameSite : ’lax’ to the attributes in the remove function leaves removing intact and eliminates the warning.

  Actuellement on est en v2.1.4 : https://git.spip.net/spip/spip/src/branch/master/prive/javascript/js.cookie.js
  Je n’ai pas encore testé avec la dernière version de la branche v2 (la v2.2.1), mais si ça règle ce problème je propose de mettre à jour : https://github.com/js-cookie/js-cookie/releases/latest

• Anomalie #4543 : Accessibilité des chargements ajax (live regions)

  9 septembre 2020, par RastaPopoulos ♥

  Ah là ya un peu d’explication :
  https://disic.github.io/guide-developpeur/9-utiliser-aria.html

  Bien utilisée, cette propriété est une solution robuste et efficace pour gérer les zones de mise à jour dynamique, par exemple un panier d’achats affiché dans la page.

  Mais attention : puisque la zone contrôlée par aria-live va être vocalisée, il convient de l’utiliser avec précaution dès que cette zone va contenir beaucoup de contenus.

  Par exemple, imaginons un moteur de recherche qui afficherait ses résultats dans la même page via AJAX. L’utilisation de aria-live sur la zone mise à jour risque d’être particulièrement lourde et contre-indiquée. Préférez une prise de focus sur la zone mise à jour en résultat de la fonctionnalité de recherche afin de simuler un rechargement de page classique par exemple.

  Donc pour tout rechargement ajax suite à un clic (liens rechargeant un bloc, ou validation de formulaire), il faudrait retirer l’attribut et "juste" placer le focus au début du bloc. Est-ce déjà le cas aussi ?