Recherche avancée

Sur d’autres sites (9245)

• Anomalie #3615 (Fermé) : Evitons les redirections

  8 décembre 2015, par Franck Dalot

  Bonjour
  spip 3.1 [22634]

  Il reste encore dans le core des url de type .org au lieu de .net
  Je croyais que cela avait été fait, mais il semble que non :-(
  Exemple :
  Faudrait faire une transformation des url du type :
  http://core.spip.org/
  en :
  https://core.spip.net/

  http://forum.spip.org/
  en :
  http://forum.spip.net/

  http://demo.spip.org/
  en :
  http://demo.spip.net/

  Pendant que j’y suis, il s’agit de sites de la galaxie ou pas ?
  http://math.spip.org/tex.php
  https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc_version.php#L234

  http://example.org/squelettes/bg.png
  http://zone.spip.org/trac/spip-zone/browser/_core_/plugins/compresseur/tests/css/expected_url_abs.css
  Car ils ne sont pas en .net

  Franck

• Anomalie #4562 : Suite #4468 : Unification des CSS pour les boutons et les icônes

  7 octobre 2020

  cedric signalait un problème dans la liste des plugins de SVP : parfois les boutons chevauchent la case à cocher.
  Plus précisément quand un plugin n’a pas de descriptif.

  Et pour cause : les boutons sont positionnés en absolute, calés en bas à droite de chaque ligne.
  Donc depuis le début ils pouvaient chevaucher le titre et le descriptif, et maintenant qu’ils sont un peu plus grands, ça empiète parfois sur la case à cocher (plus embêtant).

  Pour régler le problème à peu de frais on peut utiliser la variante .mini sur les boutons, mais c’est un peu cacher la misère sous le tapis je trouve.
  En fait ça fait partie des problèmes d’UX évoqués dans les tickets #4429 et #3017.

  En attendant l’implémentation de la solution proposée, on pourrait déjà faire quelques ajustements :

  • Boutons visibles tout le temps, pas juste au survol
  • Boutons calés à droite, pas en absolute. On a maintenant assez de place en largeur pour ça.

  Nb : dans la capture j’ai mis les logos en 50px (au lieu de 32px), mais c’était juste pour voir.

  

• Anomalie #3562 (Nouveau) : onAjaxLoad s’applique sur Document lorsqu’il provient d’une fenêtre mod...

  7 octobre 2015, par marcimat ☺☮☯♫

  En tentant de corriger un bug du porte plume, à savoir que le calcul automatique de la hauteur des textarea ne se faisait pas si on était sur exec=article&id_article=xx et qu’on cliquait sur "modifier l’article" (qui affiche le formulaire d’édition en ajax), Cédric m’a conseillé d’utiliser onAjaxLoad qui exécute les fonctions sur les contenus chargées.

  Je l’ai appliqué là : http://zone.spip.org/trac/spip-zone/changeset/92220

  Ceci étant dit, il y a un cas où le « this » vaut Document au lieu d’un contenu chargé en ajax. Pour s’en rendre compte, il suffit d’éditer sur l’édition d’un article un document joint (ajouter ou modifier). 3 triggerAjaxLoad sont exécutés dont 1 sur Document. Dans ce cas là, on arrive sur https://core.spip.net/projects/spip/repository/entry/spip/prive/javascript/ajaxCallback.js#L96 qui exécute le trigger. s.url vaut http://example.com/ecrire/?exec=document_edit&popin=oui mais s.onAjaxLoad n’existe pas.