Recherche avancée

Sur d’autres sites (10708)

• Evolution #4102 : Ordre des inclures dans cache/charger_plugins_options.php

  24 février 2018, par placido .

  il faut absolument qu’il continue d’y avoir un fichier avec le même ordre puisqu’on y met des pipelines, des variables globales (GLOBALS[’z_blocs’] par ex mais il y en a d’autres) qui DOIVENT être dans l’ordre actuel avec ceux qui nécessitent en dernier pour pouvoir passer après.

  Ok, alors faisons un point sur le rôle des fichiers xxx_options.php vs xxx_fonctions.php.
  Il me semblait justement que le fichier xxx_options.php est dévolu principalement aux define(), et de manière dérogatoire à quelques fonctions dont on souhaite qu’elles prennent la main très rapidement à chaque hit (de ce double emploi nait la limitation en fait).

  Oui, l’ordre des fichiers fonctions.php est important pour les surcharges, en effet. (Note qu’il n’était pas question de modifier cet ordre, seulement celui des fichiers options.php ; tu parles d’*un* fichier mais il y a en 2 en l’occurence).

  Donc la question, c’est : Est-ce un probleme que l’ordre d’appel des fichiers options.php diffère de celui des fichiers fonctions.php ?
  Plus j’y réfléchis, plus je me dis que ce n’est pas un problème, car les fichiers options.php ne contiennent pas - à ma modeste connaissance - d’éléments surchargeables :
  - les define() sont des constantes
  - les GLOBALS[’trucs’] livrés par défaut sont (devraient) être conditionnés par un isset()
  - les pipelines - outre qu’ils ont leur place dans le fichier dédié, ne sont pas surchargeables (function already exists !)
  - les fonctions qui y sont définies ne sont pas surchargeables non plus ( c-à-d suffixées par _dist), du moins je n’ai pas d’exemple en tête, infirmant ceci.

  Si tu as un exemple d’une fonction dûment déclarée dans pluginX_options.php et qui se veut surchargeable, je prends.

  J’ai modifié plugin.php en persevérant dans cette voie. Les premiers tests que j’ai pu faire en local avec une quinzaine de plugins actifs n’ont, pour l’instant, pas montré d’erreurs.
  À suivre...

  Et donc il faudrait plutôt un pipeline au tout début, dédié à ce cas des define()

  J’approuve. C’est sans conteste la solution la plus propre et la plus souple. Mais de là à ce qu’une majorité signicative de plugins adoptent cet hypothétique (quoique salvateur) pipeline... #SPIP4.0 #année2024

• Evolution #4489 : [API rôles] pouvoir mettre des rôles par défaut vides

  22 juin 2020, par RastaPopoulos ♥

  Et donc voilà ce que ça cause quand on finit pour telle ou telle raison par avoir des rôles vides :
  https://git.spip.net/spip-contrib-extensions/roles_documents/issues/8

  Il est alors impossible de détacher les objets, on peut ajouter et retirer des rôles (dont celui par défaut), mais il reste toujours la ligne avec rôle vide dans la table de lien. Donc impossible à tout jamais de virer le lien.

• Anomalie #3695 : Édition d’un auteur et autocompletion des login/mot de passe

  24 janvier 2019, par jluc -

  La non prise en compte du autocomplete=off est pénible
  et je trouve dommage d’en rester là
  car selon le contexte ça induit des blocages.
  (en plus sur firefox ça rejetait carrément le focus et je pouvais absolument rien faire, mais ce bug de firefox sera fixé)

  Il ya plusieurs hacks sur internet pour corriger ce pb.
  Celui que j’ai retenu marche avec javascript : compléter le autocomplete="off" (qui est ignoré par les navigateurs) par :
  

  <span class="CodeRay">readonly="readonly" onfocus="this.removeAttribute('readonly');" 
  
  </span>

  car le readonly désactive l’autocomplete
  et sauf stylage accenctuant la différence, quand le champ est vide je vois de différence d’apparence.