Recherche avancée

Sur d’autres sites (5534)

• 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 #4102 : Ordre des inclures dans cache/charger_plugins_options.php

  24 février 2018, par placido .

  Merci RastaPopoulos pour ces précisions. Entre temps, j’ai relu la documentation, ce qui, avec tes explications, m’a permis d’y voir un peu plus clair.

  Alors penchons nous sur cette histoire de pipeline "pre_options" (ou "pre_plugins_options" en fait puisqu’il viendrait après le config/mes_options.php).

  - Quel serait son point de sortie ? A priori, au debut du fichier charger_plugins_options.php
  - Que doit-il colporter ?
  A) un flux brut de type chaine (comme insert_head) : grande liberté, mais fastidieux à éditer/compléter (strpos)
  B) un tableau clé/valeur, ce qui tend à restreindre l’utilisation aux define() et GLOBALS (ma foi, c’est cohérent), facilite la syntaxe d’ajout/d’édition (array_merge), mais il faut retriturer le flux en bout de chaine pour obtenir la bonne syntaxe.

  A ou B ?

• Revision 110994 : Tout comme pour une saisie précise, on a dans ses options la ...

  4 juillet 2018, par root — Log

  Tout comme pour une saisie précise, on a dans ses options la possibilité d’insérer du HTML quelconque au début et à la fin, et bien on permet pareil mais pour le formulaire complet, dans les options globales.