Recherche avancée

Sur d’autres sites (12065)

• Anomalie #3978 : Reload ajax et contexte au retour d’un URL_ACTION_AUTEUR

  29 septembre 2018, par cedric -

  Pas de bug ici, juste une erreur de conception dans les 2 squelettes :)

  Dans le cas 1 les arguments reloada=1 et reloadb=1 sont passés en argument du href et viennent dans l’URL après un reload ajax d’un bloc
  Du coup quand on passe un {args:{reloadb:''}} et {args:{reloada:''}} dans le refresh ajax ça annule bien l’argument de l’URL et évite la boucle infinie

  Dans le cas 2 les reloada et reloadb ne sont pas en arguments de l’URL mais en argument de l’URL de retour passée à l’action
  Du coup les arguments {args:{reloadb:''}} et {args:{reloada:''}} ne viennent rien faire car ils s’appliquent sur l’URL de l’action, pas sur l’URL de retour.

  Consequence sans doute pas vue : au second coup le refresh de A se fait via l’URL action, c’est a dire en faisant une action indésirable au lieu de simplement rafraichir

  Solution : indiquer dans le refresh ajax qu’il faut utiliser l’URL de départ et pas l’URL action :

  Bloc A (#REM
  
  
      Reload A => Declenchera ensuite le Reload de B
  
  
  [(#ENVreloada|oui)
  &lt;script type=&quot;text/javascript&quot;&gt;<br />
  
      ajaxReload('blocb', {args:{reloadb:''},href:'#SELF'});<br />
  
  &lt;/script&gt;
  ]
  

  Bloc B (#REM
  
  
      Reload B => Declenchera ensuite le Reload de A
  
  
  [(#ENVreloadb|oui)
  &lt;script type=&quot;text/javascript&quot;&gt;<br />
  
      ajaxReload('bloca', {args:{reloadb:''},href:'#SELF'});<br />
  
  &lt;/script&gt;
  ]
  

  A noter qu’ici j’ai aussi ajouté une class nohistory sur les liens pour ne pas modifier l’URL de la page web et éviter qu’elle ne devienne celle de l’action

• Evolution #4080 : Raccourci puce : se débarasser de l’image

  28 septembre 2018, par cedric -

  Je note que la demande initiale simple était "ne plus avoir une image sur cette puce parce qu’on ne peut pas la personaliser" et qu’à la fin il s’agit de tout revoir le fonctionnement des raccourcis SPIP et donc qu’on ne fera rien :)

  Pour revenir au point de départ :

  1/ peut-être ça manque de documentation mais la puce est totalement personnalisable via le mes_options.php :
  

  $GLOBALS[’puce’] = ’’ ;
  $GLOBALS[’puce_rtl’] = ’’ ;
  $GLOBALS[’puce_prive’] = ’’ ;
  $GLOBALS[’puce_prive_rtl’] = ’’ ;
  

  2/ ça paraitrait moderne de passer à une puce unicode par défaut décorée en CSS avec un fallback texte pour les sites qui upgraderont sans avoir la CSS qui va bien
  

  —
  avec les styles suivants :
  .spip-puce b display:none ;
  
  .spip-puce 
  
    position : relative ;
  
    top : 1px ;
  
    display : inline-block ;
  
    font-style : normal ;
  
    font-weight : normal ;
  
    line-height : 1 ;
  
    -webkit-font-smoothing : antialiased ;
  
    -moz-osx-font-smoothing : grayscale ;
  
  
  
  .spip-puce:before 
  
  content : "\2023" ;
  
  
  

  Avec puce à choisir parmi
  https://unicode-table.com/fr/2023/
  https://unicode-table.com/fr/25B8/
  https://unicode-table.com/fr/25B6/

  Du coup sans ces styles spécifiques, la puce est un simple tiret typographique, et avec les styles c’est un caractère qui s’affiche dans la couleur et taille de texte courante, et stylable

  2b/
  Voire si on veut faire une transition vraiment smoothly on garde le img actuel en fallback dans le span (au lieu du simple tiret), et il ne s’affichera plus que sur les anciens sites qui n’ont pas ajoutés la nouvelle CSS
  (et on prévient que dans une prochaine version cette puce image disparaitra complètement)

  3/ à partir du moment où on a un plugin qui permet de transformer ces puces en liste je pense que garder le comportement actuel par défaut dans SPIP est pertinent et le plus logique

• Inscriptions3 + Champs Extra

  6 août 2018

  Bonjour,

  Voici quelques points liées à l’utilisation de Champs Extra dans Inscription 3. Je vais détailler un peu mais dans l’idée, il s’agit d’adapter l’affichage de champs ou de leur valeur selon leur nature (input, radio, select ou fieldset), pour l’heure cela semble bien pensé pour les inputs et textarea, mais pour le reste ça pèche un peu.

  Page des utilisateurs (ecrire/ ?exec=inscription3_adherents) :

  Bug :
  Les champs fieldset et explication provoque une erreur alors qu’il devrait être ignorer. Il va de soit qu’on ne devrait pas cocher la colonne ’table’ pour ces champs dans la page de configuration, mais malheureusement c’est une erreur fréquente.

  Soucis d’affichage :

  1. Pour les selects, les entêtes des colonnes sont erronées, on voit par exemple ’label_nom_champs’ au lieu du nom du champs
  2. Pour les selects, on voit dans les cellules du tableau et non des valeurs
  3. Les dates sont au format SQL, pas si simple à lire pour les utilisateurs.

  Page de configuration (ecrire/ ?exec=configurer_inscription3) :

  Bug :

  • Dans la première colonne dans la partie des champs extras, le label est vide pour les checkbox, impossible de les identifier sinon par l’ordre dans la liste.
  • Idem avec les champs ’explication’
  • Il faut supprimer les cases à cocher de la colonne ’Table’ pour les champs ’explication’ et ’fieldset’, ils créés l’erreur fatales dans la page des utilisateurs.
  • Il faut supprimer les cases à cocher de la colonne ’Obligatoire’ pour les champs ’explication’ et ’fieldset’, car si ils sont cochés, le formulaire d’inscription ne pas être validé par l’utilisateur, c’est une erreur fréquente chez moi...

  Groupe de champs :

  Par le passé, j’ai voulu exploiter les fieldsets (Groupe de champs) de champs extra, pour grouper des champs...
  Malheureusement, cela ne semble pas être pris en charge par Inscription3.
  Les champs groupés disparaissent de la page de configuration, ils en deviennent inconfigurable...
  Et on perds les options d’affichage conditionnel par groupe par exemple...

  Vous pouvez compter sur moi pour des tests suite à la correction de ces bugs.

  Merci d’avance,

  Jul