Recherche avancée

Sur d’autres sites (3256)

• Anomalie #3640 : affichage incorrect des rubriques restreintes

  8 janvier 2016, par b b

  J’ai envoyé un patch mais ce n’est pas satisfaisant, la règle css de source:spip/prive/themes/spip/forms.css.html#L74 impacte encore, en appliquant une largeur en dur au label.

  En comparant avec SPIP 3.0, on voit que la règle précédente est plus haut dans la css compactée, par rapport aux styles du picker, cf :

  source:spip/prive//themes/spip/picker.css.html#L67

  Du coup, plutôt que d’ajouter une couche supplémentaire, je me dis qu’il vaudrait chercher pourquoi l’ordre d’insertion de ces deux css a changé. En attendant j’ai annulé r22717 par r22718.

  Trouvé, c’est l’ajout de .editer dans dans source:spip/prive/themes/spip/forms.css.html#L74 qui rend la règle plus forte que celle du picker.

  Première option, affiner le sélecteur de source:spip/prive/themes/spip/forms.css.html#L74 comme ceci :

   .formulaire_spip .editer > label, .formulaire_spip .editer.gauche > label
  

  Mais ça risque d’avoir des effets de bord. Deuxième option, ajouter la règle suivante dans source:spip/prive/themes/spip/forms.css.html#L246 :

  .formulaire_editer_auteur .editer.editer_statut .rubriques_restreintes label  float : none ; width : auto ; margin-#ENVleft : 0 ; 
  

  D’autres avis ?

• Anomalie #4516 (Nouveau) : Fatal error en php 8.0

  9 juillet 2020, par Franck D

  Hello, :)

  Windows 10 (1909)
  Firefox 78.0.2
  Easyphp
  Apache 2.4.43 x64
  PHP 8.0.0 alpha1 x64
  MySQL 8.0.20 x64
  PhpMyAdmin 5.0.2

  memory_limit 512M
  post_max_size 130M
  upload_max_filesize 64M
  max_execution_time 300
  max_input_time -1

  Comme php 8.0 sort le 26 novembre, https://wiki.php.net/todo/php80 et que spip 3.4 ne sortira sans doute pas avant 2022... Je commence à faire des tests avec php 8 (plus c’est tôt mieux c’est) histoire de voir si cela posera de gros problèmes avec spip 3.3 !

  Si je lance spip_loader version 3.0.9, j’ai une page blanche avec :
  Fatal error : Uncaught Error : Call to undefined function get_magic_quotes_gpc() in C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test2\config\ecran_securite.php:350 Stack trace : #0 C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test2\ecrire\inc_version.php(130) : include() #1 C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test2\spip.php(17) : include_once(’C :\Program File...’) #2 C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test2\index.php(3) : include(’C :\Program File...’) #3 main thrown in C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test2\config\ecran_securite.php on line 350

  Je monte la priorité à "haut" pour voir, si cela ne serait pas possible pour spip 3.3.0, mais c’est discutable...

• Anomalie #3860 : Non prise en compte de la balise `genie` d’un paquet.xml lors du vidage de cache

  9 novembre 2016, par marcimat ☺☮☯♫

  Je pensais bien déplacer plus haut le chargement des chemins et options (le point B que j’indiquais).
  Mais. Cela pourrait potentiellement impacter des plugins qui attendent d’avoir dans leur fichier d’option un ’spip_pipeline’ un peu rempli.

  Mais je vois 1 plugin (1 seul sur la zone il me semble) que ma pourrait impacter : Fastcache. (En fait non car Mutualisation déclare son pipeline dans son fichier d’option aussi donc, ça ne s’applique pas pour lui) mais je le mets pour l’exemple : si je remonte un peu le chargement des fichiers d’options, la globale ’spip_pipeline’ ne sera pas remplie par les pipelines déclarés dans les plugin.xml ou paquet.xml des plugins à activer.
  Or, dans Fastcache on a cette écriture :
  

  # s’inserer au *debut* du pipeline affichage_final pour etre avant f_surligne etc
  # mais de preference apres mutualisation_url_img_courtes pour qu’il s’applique
  $GLOBALS[’spip_pipeline’][’affichage_final’] = preg_replace(
      ’,|mutualisation_url_img_courtes|^,
      ’,’\0|Fastcache_affichage_final’, 
      $GLOBALS[’spip_pipeline’][’affichage_final’]
  ) ;
  

  On peut peut être du coup supposer que d’autres plugins dans la nature font de même ?
  Ça se mord un peu la queue tout de même, vu que le fichier de chargement des pipelines (tmp/cache/charger_pipelines) pourrait aussi avoir besoin d’infos qui sont chargées dans les fichiers d’options de plugins. En tout cas là pour cette balise <genie></genie> tel que c’est codé il en a besoin (des chemins au moins).

  Cependant je serai d’avis tout de même de recharger les chemins et options plus tôt (spip_pipeline sera presque vide dans les fichiers d’options), en considérant que le fichier d’option sert à remplir justement ce fichier de pipeline, pas à modifier des fonctions qu’ont demandé d’autres plugins.

  Voici un patch, pour voir ce que j’indique en B donc, en pièce jointe.