Recherche avancée

Sur d’autres sites (11565)

• Nomenclature #4626 : Renommer le menu "Squelettes"

  1er mai 2021, par RastaPopoulos ♥

  Merci b_b, voici donc la liste seule triée alpha :

  acs adaptive_images campagnes champs_extras_synchronisation chosen cloudzoom comarquage comments compositions court-circuit dublin_core elements eva-web-bonus eva-web-habillage eva-web-install eva-web-mentions exclure_secteur fontawesome5 forkawesome kaye links mathjax mediaspip_player menu_langues_liens menus noizetier picto player porte_plume_enluminures_typographiques rainette recherche_mots_cles refbase saisies select2 seminaire seo sjcycle skeleditor slick sociaux spip_visuels squelettes_par_mots_cle switcher timecircles tooltip videos w3css xiti xray zinit

  des aspects aussi bien esthétiques que fonctionnels

  C’est un point qui me semble très important : ce menu ne sera jamais que pour l’apparence graphique, il y a aussi du fonctionnel mais qui a un rapport quand même avec l’affichage de la page sans que ce soit de l’éditorial. Par ex Compositions ou Noizetier ou Menus permettent de définir quoi afficher à certains endroits des pages, mais ce n’est pas de l’éditorial, c’est de la mise en page et de la config de navigation.

  que des métas dans le header que de la redirection que des outils de dev/débug que etc

  @nico justement, comme dit dans le texte de départ, il est très clair que parfois ce menu n’a strictement aucun sens quelque soit son nom :D car des gens y ont aussi mis tout et n’importe quoi.

  Il est donc de même très clair que certains plugins doivent se barrer ailleurs, c’est d’ailleurs ce que qu’a dit b_b aussi. Certains plugins devraient aller dans Configuration ou autre.

  Suivant la liste je vais essayer de faire une typologie, yen a pas tant que ça, et on va vite voir les quelques trucs à déplacer.

  L’idée c’est qu’il ne reste à peu près que des choses : styles graphiques + mise en page + navigation, en gros.

• 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...

• Evolution #3953 : formulaire de date sur les rubriques

  12 février 2021, par RastaPopoulos ♥

  Dans tous les cas il me semble nécessaire de pouvoir agir sur les dates des objets, sachant qu’historiquement les dates des rubriques sont liées automatiquement à la date de leur dernier article, faudrait-il trouver une solution pour bloquer/débloquer cet automatisme ?

  1) Les dates des rubriques sont liés aux articles, mais il me semble que soit la doc n’est pas assez explicite, soit le code ne va pas jusqu’au bout (mais ça impliquerait possiblement des trop gros tests). En effet, la date des rubriques n’est pas liée vaguement à la date du contenu le plus récent publié dedans. :) C’est plus fourbement précis : c’est la date du dernier contenu dont le statut a été mis en publié pendant qu’il était dans cette rubrique. Et ça à défaut de changer le code pour l’instant, il faudrait au moins le dire moins sibyllin. Concrètement ça signifie que si on déplace un article (publié bien sûr) depuis une autre rubrique dedans après coup, avec une date plus récente, ça ne change rien à la date de la rubrique (dont le contenu a pourtant changé toute autant qu’en publiant direct depuis dedans). En théorie il faudrait que ça change en cascade la date de tous les parents quand on déplace un article (la rubrique de destination et toute la hiérarchie). Et possiblement d’autres cas de ce genre.

  2) Quoiqu’il en soit, même s’il y a un changement de date par défaut, je pense aussi qu’il faut pouvoir décider qu’on veut la changement manuellement après coup. Si on a une liste de rubriques "par date de contenu récent", on peut rien corriger actuellement si les dates ne vont pas. Là j’ai le cas après une migration WP par exemple.

  En attendant faudrait un mini plugin tout simple pour ajouter le form de date sur les rubriques comme le montre touti au début. Mais est-ce ça devrait pas être natif directement ?