Recherche avancée

Sur d’autres sites (7146)

• Revision 118606 : Version 1.4.0. - Nouveauté la plus visible : petite refacto du menu de ...

  13 novembre 2019, par Charles Razack — Log

  Version 1.4.0.
   Nouveauté la plus visible : petite refacto du menu de langues → Noms des langues en entier au lieu des codes (fr, en...), liens affichés sous formes de boutons plus grands et centrés pour être bien visibles, ajout d’un label. Petite amélioration pour éviter qu’il y ait un saut lorsque le menu passe en sticky.
   Configuration : les formulaires sur lesquels activer le script sont tous regroupés dans une même clé formulaires.
   Configuration : ajout d’une option pour ajouter des sélecteurs dans le paramètre root (exemple complètement au hasard : .formulaire_editer_noisette).
   Ajout d’un pipeline multilang_parametres pour permettre aux plugins de changer les paramètres passés au script d’init. Cas le plus courant : ajouter des formulaires à prendre en compte par le script.
   Refactorisation du script d’init afin qu’il soit plus lisible et maintenable : séparation du javascript et du php. Au passage, correction d’un bug rigolo qui faisait que quand on décochait tous les items dans la config, le script devenait actif sur *tous* les formulaires : recherche, login, etc.

• Evolution #3488 : Stocker globalement toutes les requetes passées

  29 juin 2015, par nico d

  Justement non :)
  Actuellement, les requetes sont stockées uniquement si on a un var_profile en GET.
  var_profile c’est bien, c’est très complet pour debugger finement, mais il faut ajouter le paramètre à l’url (même si avec le minibando c’est plus rapide).

  Ma modif consiste juste a stocker toutes les requetes en global.
  Ensuite je me suis inspiré du plugin dev, je passe par register_shutdown_function() pour ajouter ce bandeau sur toutes les pages, sans ajouter var_profile à l’url.
  C’est plus rapide, je l’ai tout le temps sous les yeux quand je suis connecté et webmestre (privé et public).
  Pour les appels en Ajax, je logge ces infos au lieu de les afficher pour pouvoir les lire aussi si besoin (vérifier le nombre de requetes générées).

  Pour être complet, en fait j’affiche aussi le temps de génération de la page :
  
  ça me permet aussi de tester certaines optimisations.
  (et la croix me sert à masquer le bandeau si jamais il y a du texte en dessous)

  Possible que ça n’intéresse que moi, mais Fil sur IRC paraissait intéressé aussi, du coup je pose ça là.

  "Voilà ma chanson mon pote. Si t’en veux pas, pas d’ malaise. Je la remet dans ma culotte."

• Anomalie #4155 : la fonction roles_presents ne fonctionne pas correctement

  27 juin 2018, par Michel Bystranowski

  Mmmm, à me relire, c’est vrai que je n’ai pas été clair du tout… Je réessaie :

  Pour donner les roles possible pour un lien entre deux types d’objets, la fonction roles_presents se base sur la « table des tables », qui est retournée par la fonction lister_tables_objets_sql. C’est de cette liste dont je veux parler quand je parle de « liste des tables ».

  Cette « table des tables » est très grande, donc dans mon exemple je ne montre qu’une partie : la clé "roles_objets" de la table "spip_documents". On y définit les rôles possibles pour les liens avec les autres objets éditoriaux SPIP. Il peut y avoir des index par objets éditoriaux et/ou un ’*’.

  Enfin en écrivant tout ça, je vérifie et je me rend compte que ça n’est pas un bug dans SPIP, mais dans mon plugin logos_roles. C’est lui qui utilise des index du type "spip_articles" au lieu de "articles", alors que la doc des rôles sur contrib dit l’inverse (https://contrib.spip.net/Des-roles-sur-des-liens).

  Et donc il n’y a pas de bug (dans SPIP :-)), et on peut fermer le ticket, désolé pour la fausse alerte.