Recherche avancée

Sur d’autres sites (6190)

• Evolution #4105 : Constante ou config ?

  28 février 2018, par RastaPopoulos ♥

  Du coup maintenant on a trois discussions ouvertes sur les config, le ticket de Placido, le fil sur la liste emails, et ce ticket…

  b_b attention, dans l’idée de Maieul la constante est inversement prioritaire, et non pas à chercher en dernier recours.

  Mais mon avis c’est que les deux sont un peu de la merde. :D

  Déjà il ne faut pas comparer constantes et form de config, mais constante et meta (= une config gardée en mémoire en base). On a une API lire_config() et ecrire_config(), ça ne vient pas forcément que d’un formulaire avec interface humaine.

  L’avantage des constantes, c’est le déploiement, c’est défini et activé à chaque hit et donc pour l’exécution complète de tout ce qui suit. Ce qui est un énorme avantage pour vraiment activer des choses depuis un plugin (ou le mes_options général).
  L’inconvénient c’est que c’est un peu de la merde, vu que ça ne peut se surcharger qu’une seule fois et c’est super compliqué si plusieurs plugins chercher à faire des choix.

  L’avantage des config en base, c’est que c’est une API à nous, et qui peut être réécrite à tout moment. C’est beaucoup plus souple, et ça permet aussi des valeurs plus complexes.
  L’inconvénient c’est que c’est un peu de la merde : ça ne concerne qu’un enregistrement fixé en base. Et donc pas à chaque hit ! Du coup si un plugin personnalise une valeur lors de son installation, bah un form de config peut l’avoir réenregistré autrement ensuite, ou n’importe quel autre plugin en PHP avec ecrire_config(). Du coup c’est vraiment de la merde pour le déploiement contrôlé de variables de config !

  Mon idée est donc qu’il manque clairement quelque chose pour avoir une API complète de gestion des configurations.
  1) on doit pouvoir le garder en mémoire (chez nous en BDD)
  2) mais on doit AUSSI pouvoir le définir à chaque hit !

  Or il se trouve que le tableau des metas (donc des configs !) est de toute façon déjà chargé au démarrage de SPIP et trimballé entier durant tout le hit PHP !

  Du coup pour moi la solution la plus propre c’est qu’il y ait un nouveau pipeline "lire_config" qui permettent de modifier le tableau des configs après qu’il ait été initialisé depuis la base. Du coup on aurait bien les valeurs venant de la base (form de config ou autre), MAIS AUSSI n’importe qui pourrait forcer la valeur d’une config à chaque hit, exactement comme on le fait pour les constantes. Et du coup vu que pipeline, bah on pourrait le surcharger plusieurs fois, suivant le path, etc, easy et simple à comprendre pour tout le monde.

  monplugin_lire_config($metas) 
      // Je force une config
      $metas[’albums’][’activer_trucmuche’] = true ;
      return $metas ;
  
  
  

• Anomalie #4077 (Nouveau) : function redirige_par_entete & signature apache modifée

  19 janvier 2018, par Laurent PAGE

  Lorsqu’on utilise Apache avec le mod_securite2 nous pouvons changer la signature du serveur Server : Apache
  Et dans ce cas redirige_par_entete ne fonctionne plus correctement lorsqu’on en profite pour manipuler les cookies.
  C’est le cas lors de la connexion/déconnexion à "ecrire", il y a une redirection 302 qui pose des cookies, on obtient alors furtivement une 200 avec refresh ; c’est pas très gênant mais c’est déroutant pour les utilisateurs.

  La fonction inc/headers/redirige_par_entete contrôle le serveur utilisé en vérifiant $_SERVER[’SERVER_SOFTWARE’] à la ligne 72.
  $_SERVER[’SERVER_SOFTWARE’] a alors la valeur défini par Apache en tant que signature et ne contient donc pas forcément le mot Apache comme c’est vérifié ici.
  getenv(’APACHE_RUN_DIR’) me semble plus fiable pour contrôler l’usage d’Apache.

  Je propose d’ajouter à la condition pour vérifier si nous utilisons Apache or @getenv(’APACHE_RUN_DIR’) !=’’.

  defined(’_SERVER_APACHE’) permet de gérer ce problème par mes_options.php, mais je pense que la pratique du changer de signature de serveur va se généraliser dans les années à venir et qu’il faut donc opter pour une autre méthode de vérification.

• Anomalie #4342 (En cours) : Erreur 1071 de mysql : Specified key was too long ; max key length is 10...

  7 avril 2020, par cam.lafit -

  Salut

  Je me permets de réouvrir ce ticket. Si on migre un vieux site sur un nouveau serveur. L’export SQL va indiquer le moteur MyIsam.
  Si par la suite on souhaite monter de version on tomber sur l’erreur des index trop courts. Cette erreur est silencieuse et le site se mets à jour sans dire qu’il a un planté.
  Sur une migration 1.9.2 vers 3.2, la mise à jour plante sur spip_urls et spip_index qui utilise ce type d’index.

  Il serait bon de faire un contrôle amont pour vérifier que spip pourra se mettre à jour.