Recherche avancée

Sur d’autres sites (10607)

• 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

  23 février 2018, par RastaPopoulos ♥

  Je l’ai déjà dit juste avant, 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.

  Le cas des define() qui doivent être en tout premier est le seul cas particulier où ça doit être avant, alors on ne va pas prendre ça comme cas principal sur lequel se baser. C’est celui là le cas rare et surtout qui ne concerne absolument que les define().

  Dans tous les autres cas, ceux qui veulent surcharger doivent se trouver après, pas avant.

  Et donc il faudrait plutôt un pipeline au tout début, dédié à ce cas des define(), ou pas que, mais où on sait qu’on est au tout début de SPIP, avant même les inclusions des fichiers. Un pipeline "initialisation" en fait, c’est même plus générique que "pre_options" comme je disais avant.

• Evolution #3996 : Y a t-il une limite de taille de cache dans SPIP ?

  18 janvier 2018

  Je viens de tester en local et je confirme : on peut nettoyer le tout

  J’ai juste une question : le genie_invalidateur_dist devient superflu
  doit-on le conserver pour avoir un point d’entrée ou faut-il le supprimer des taches générales ?
  (et comment fait cela ? retirer proprement un item de taches_generales) ?

  Pour l’instant, j’ai juste masqué la valeur dans l’interface r23894 et r23895