Recherche avancée

Sur d’autres sites (8208)

• Anomalie #4515 (Fermé) : 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 !
  J’ai donc fait l’installation d’un spip 3.3 (24642) en php 7.4 puis, je change la version de php de esayphp pour lui mettre php 8.0 alpha1

  Résultat, j’ai de suite 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\test3\config\ecran_securite.php:350 Stack trace : #0 C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test3\ecrire\inc_version.php(130) : include() #1 C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test3\ecrire\index.php(22) : include(’C :\Program File...’) #2 main thrown in C :\Program Files (x86)\EasyPHP-Devserver-17\eds-www\test3\config\ecran_securite.php on line 350

  Je monte la priorité du ticket à "haut" car cela serait bien que spip 3.3 fonctionne en php 8, mais après, c’est discutable !

• Anomalie #3281 (En cours) : remarques sur le nouveau thème graphique de la 3.1

  13 août 2016, par b b

  Ha mais non pardon, je pensais qu’on avait intégré les propositions alors que non... J’ouvre de nouveau, mais il serait bien de s’occuper de ce ticket un jour... (parce que là ça commence à dater ^^).

  Pour tenter d’avancer, quelques remarques à propos des propositions de tcharlss :

  formulaires latéraux (fiche d’un objet) : couleurs neutres (bordures et fond), boutons plus lisibles.

  Perso je n’avais même pas remarqué le problème car j’utilise toujours le gris dans le privé. Ça a failli être la couleur par défaut pour la 3.1, mais Arnaud nous a "gentiment" fait remarquer que le gris n’est une couleur... Du coup, je ne suis pas certain que ta proposition lui fera plaisir, par contre ça le fera certainement réagir :p

  Pour les boutons plus lisibles, je crois bien qu’on a augmenter le contraste de ce côté, ça semble bon de mon côté à ce jour.

  - fiche d’un objet : pas d’ombre portée, remplacée par une simple bordure.

  Perso avec ou sans je m’en cogne un peu, mais je trouve plus en accord avec le reste du thème de ne pas utiliser d’ombre portée. Je crois bien que c’est la seule présente dans tout le privé, elle fait un peu tâche du coup. +1 donc :)

  - marge entre le contenu éditorial d’un objet et les formulaires de date etc.

  Ce point semble aussi réglé maintenant.

  - bandeaux identité et outils : couleur de fond identique.

  J’ai un gros doute sur ce point, en effet, si on utilise la "non couleur" gris (^^) et qu’on applique le gris clair du premier bandeau au second (#f4f4f4), la séparation visuelle entre la zone haute et la zone de contenu est beaucoup moins perceptible.

  D’autres avis ?

• Evolution #4727 : Des pictos / icônes symboliques pour tout le monde

  13 avril 2021, par RastaPopoulos ♥

  - et même amha assez simplement la balise #ICON pourrait détecter si l’image demandée est dans un sprite connu, auquel cas elle utilise le sprite, sinon elle utilise le fichier individuel

  Ça c’est bien prévu dans le cahier des charges :)

  Pour les classes, si ya une autre méthode que la fonte tant mieux hein, mais ce qui compte c’est continuer d’avoir l’option des classes, surtout pour l’interface d’admin. Car il y a plein de cas où c’est utile quand on veut avoir une interface cohérente maintenable, surtout si elle est modulaire (plugins infinis qui doivent avoir aussi le même style, sans devoir tout changer partout dès qu’on veut changer le style d’un morceau, dont les pictos).

  Et pour une interface d’admin, il y a encore moins de freinage y compris pour une fonte, on parle pas du site public qui utilise 3 pictos (là c’est au choix de la personne intégratrice de faire les bonnes décisions). Pour l’admin on charge de toute façon des choses permanentes, dont les sprites, et on va de toute façon utiliser un certain nombre de pictos un peu partout + en rendre dispo pour les plugins + le fait que les fontes sont à peu près toujours plus légères que les sprites. Avec tout ça je ne vois pas de problème énorme à charger une fonte de 80 pauvres kilos pour ce qui est de l’admin… (on parle pas de 500ko là…)
  Batailler pour ne pas intégrer 80ko voire même 40ko si on prend un jeu moins gros que bootstrap, c’est un peu dérisoire… :)
  (et du coup justement ya PAS à maintenir un sous-ensemble, car déjà l’ensemble complet pèse bien moins lourd que les sprites SVG, ça fait de la maintenance en moins)