Recherche avancée

Sur d’autres sites (11256)

• Anomalie #3043 (Nouveau) : Suggestion ergonomie Interface privée : bouton Sauvegarder "flottant"

  19 août 2013, par YannX spip

  Bonjour,

  Au fur et à mesure de la complexification croissante de SPIP, les formulaires du privé s’allongent....
  vers le bas, alors que nos écrans s’allongent horizontalement !

  Dans la lignée de la taille d’ecran "Elastic" que je viens de decouvrir (avec HEUREUSE surprise),
  je suggère trois axes d’améliorations à discuter :
  - pouvoir rendre le bouton "sauvegarder" flottant (ou bien doublé en heaut de marge droite du menu /option)
  > de façon à toujours avoir accès (sans devoir scroller) quand on fait une modif rapide en début d’article
  avoir une personnalisation différente du menu (inspirée de Luis en 200 ? ),
  qui proposerait de disposer les icones principales du bandeau à gauche
  (à l’exemple de l’interface privée de WP... dont l’ergonomie semble assez souvent reconnue comme exemplaire)
  - utiliser plus largement les colonnes/boites du menu droite pour compléter les saisies...
  (mais cela pourrait nécessiter de revoir l’intégration dans un écran 2-colonnes (qd il existe encore)
  pour que des zones de saisie annexe (je pense en particulier aux mots-clés !! ) soient visibles/accessibles facilement !

  Qu’ne pensez-vous ?

  YannX
  PS n’oublions pas la définition de la majorité des portables : 1360 x 768
  sans oublier le format "vertical" des tablettes ou smartphones...

• Anomalie #3769 (Nouveau) : form_hidden insère un hidden en trop

  13 avril 2016, par jluc -

  La doc spip.net dit : Si on fait un formulaire qui utilise comme action un lien comprenant des arguments, il faut remettre ces valeurs dans des champs hidden .

  Le phpdoc dit : Fournit la suite de Input-Hidden correspondant aux paramètres de l’URL donnée en argument, compatible avec les types_urls.

  Normalement, le résultat de form_hidden devrait uniquement dépendre de la balise sur laquelle il s’applique, fut elle #SELF ou #URL_PAGEtagada

  Or, si la page courante est ?page=truc&id_truc=10, form_hidden insère toujours un hidden pour id_truc=10, même si on l’applique à un argument comme #URL_PAGEtagada dans lequel aucun id_truc n’est mentionné.

  J’imagine que ce comportement est pratique parfois, sur une page truc qui ne s’occupe que d’un seul truc et où toutes les noisettes s’occupent de ce seul truc.

  Mais il est des pages truc qui s’occupent AUSSI d’autres trucs, ou d’autres choses qui n’ont pas de rapport, ou des rapports plus complexes que "toujours tout sur un seul truc", et que ce paramètre id_truc peut gravement perturber.

  Exemple de squelette pour mettre en évidence : fichier truc.html

  DEBUT
  ENV=
  [(#ENV**|unserialize|print_r1)]
  SELF
  #SELF
  SELF|form_hidden
  [(#SELF|form_hidden|htmlspecialchars)]
  url_pagetagada
  #URL_PAGEtagada
  URL_PAGEtagada|form_hidden
  [(#URL_PAGEtagada|form_hidden|htmlspecialchars)]
  FIN
  

  
  Appeler ?page=truc&id_chose=1
  Appeler ?page=truc&id_truc=2
  Dans ce dernier cas, id_truc s’insère de force dans le form de la page tagada

• Evolution #4102 : Ordre des inclures dans cache/charger_plugins_options.php

  28 juin 2018, par placido .

  jluc - a écrit :

  Donc tu proposes que les constantes, avant d’être définies par un define, soient possiblement pré-réservées par les plugins, via le tableau $flux où les éventuelles pré-réservations peuvent être surchargées.

  Oui en gros c’est ça. On obtient une gestion plus souple des contantes. Le pipeline peut servir à trier, ou écraser certaines valeurs, il est (re)calculé lors de la visite de la page admin_plugin&actualise=1 et son résultat est inséré au début du fichier charger_options.php donc avant les éventuels define() livrés par defaut par les plugins. On retrouve bien la logique de surcharge emblématique de SPIP (le plus bas dans la chaîne a possiblement le dernier mot) et la magie continue.

  Mais est-ce que ça couvre tous les cas ? Ou bien est-ce que c’est suffisant ?

  Ma solution a quelques limitations qu’il faut garder à l’esprit en effet.
  Le calcul du pipeline ne se fait pas à chaque hit, et en conséquence, certaines valeurs dont on souhaiterait modifier l’affectation en fonction du contexte de la requête (ex : ip / test_espace_prive, ...) ne seraient alors pas pertinentes. Mais cela reste des cas rares, qui déjà eux-même sortent de la simple déclaration de constante de configuration.

  Ou bien un peu plus simple : sa valeur + un indice de priorité.

  Pour moi, pas besoin de gestion explicite de priorité. Si on veut vraiment forcer une valeur en toutes circonstances, il reste mes_options.php.