Recherche avancée

Sur d’autres sites (5463)

• Anomalie #4508 (En cours) : comportement erratique (et anormal) avec les table ayant des lignes av...

  11 juin 2020, par cy_altern -

  Dans un tableau si la première colonne d’une ligne est vide le rendu plante de différentes façon selon qu’il s’agit de la première ligne ou des suivantes et si le premier texte dans une cellule est dans la seconde ou les suivantes...

  Le détail à partir d’un tableau basique 3 lignes (dont une de titre) et 3 colonnes :
  

  <span class="CodeRay">|{{colonne A}}|{{ }}|{{ }}|
  |bla|||
  ||||
  </span>
  Télécharger

  
  => rendu OK (table avec thead + tbody, toutes les lignes visibles)

  <span class="CodeRay">|{{colonne A}}|{{ }}|{{ }}|
  ||bla||
  ||||
  </span>
  Télécharger

  
  => le "bla" de la 2ème cellule devient un caption qui se glisse juste après le thead , il est suivi d’un 2ème thead vide et le tbody (OK pour les tr/td) devient alors invisible même si il y a du contenu dans les cellules des lignes suivantes

  <span class="CodeRay">|{{colonne A}}|{{ }}|{{ }}|
  |||bla|
  ||||
  </span>
  Télécharger

  
  => le bla disparait complètement, le thead "normal" est suivi d’un 2ème thead avec 1 ligne et 3 td puis un tbody complètement vide (même si les lignes suivantes ont des cellules avec du texte)

  <span class="CodeRay">|{{colonne A}}|{{ }}|{{ }}|
  ||||
  |bla|||
  </span>
  Télécharger

  
  => la 2ème ligne donne un 2ème thead avec le bon nombre de th, le tbody est OK avec tr/td de la 3ème ligne

  <span class="CodeRay">|{{colonne A}}|{{ }}|{{ }}|
  ||||
  ||bla||
  </span>
  Télécharger

  
  => la 2ème ligne donne un 2ème thead avec avec le bon nombre de th, suivi par un tbody vide (ni tr,ni td)
  Idem si le bla est en 3ème cellule de la ligne (ou nième)

  Bref, il y a un sacré foirage dans l’algo de rendu de texwheel sur ce cas particulier de première cellule vide mais j’avoue que l’algo de rendu avec des regexp dans tous les sens ne m’a pas paru très "abordable" pour essayer de trouver un patch... :-(

• Evolution #4429 : Ajouter « configurer » en toutes lettres à côté de l’icône dans la liste des plu...

  17 février 2020, par RastaPopoulos ♥

  Ben oui la navigation c’est une partie intégrante de l’ergonomie, et c’est tout l’objet de la première partie de mon message (la deuxième étant quoi faire de plus rapide). Je ne comprends pas le "ce sont des pages indépendantes de l’espace privé", je ne vois pas ce que ça veut dire. Une page de config, c’est bien une page de l’espace privé où on configure une fonctionnalité, ça fait partie intégrante de l’espace privé, et donc doit être rangé de manière trouvable, que ça vienne d’un plugin ou pas, c’est une séparation qui n’est compréhensible que par une minorité.

  Il y a deux chemins principaux :

  1) En terme purement fonctionnel : les utilisateurs n’en savent la plupart du temps rien de savoir d’où vient la fonctionnalité, ce qu’ils ont besoin de savoir c’est "On peut configurer les événements", ou "On peut configurer les documents", etc, et dans ce cas de figure il n’y a aucune raison de distinguer où on peut trouver la page de config, suivant d’où vient la fonctionnalité. On a déjà une entrée principale "Configuration", c’est directement là que devraient être listées toutes les configurations pour être cohérent. Sinon dans Configuration on a parfois des trucs du core, parfois des trucs de plugins, parfois faut aller dans une sous-page pour trouver celles d’autres plugins… comment savoir du premier coup ?

  Jean-Michel est admin non-technique. Jean-Michel sait "j’ai des événements dans mon site". Il se demande s’il y a des choses configurables sur cette fonctionnalité, il n’en sait rien d’où ça vient. Il ne doit pas avoir à chercher à plusieurs endroits pour savoir où ça se configure. Il ouvre donc le menu "Configuration" et il regarde dedans s’il y a une entrée "Événements" ou "Agenda".

  2) En terme technique, les admins de plus haut niveau peuvent parfois ajouter des plugins elleux-mêmes. Dans ce cas on sait qu’on a ajouté le plugin Trucmuche, et on veut le configurer tout de suite : il n’y a pas à partir autre part, on a la liste des plugins actifs sous les yeux, et dans chacun ya un raccourci pour le configurer (c’est ce que fait Wordpress et Drupal aussi).

  Martine est admin technique, de temps en temps elle ajoute ou retire des plugins. Là elle vient d’ajouter le plugin "GIS". Dans sa liste de plugin, elle peut voir immédiatement à cet endroit que le plugin a une page de config et s’y rendre.

  Dans les deux cas de figures, il n’y a pas à savoir "quels plugins ont des pages de config" puisque
  - soit on veut configurer une fonctionnalité et non pas un plugin
  - soit on vient d’installer un plugin, ou comme ton exemple de départ une personne au téléphone nous demande de configurer tel plugin précis, et donc on sait déjà d’avance quel plugin on veut configurer.
  Et si vraiment il faut avoir cette liste (mais ça ne me parait pas le besoin courant suivant les deux scénarios), ça me parait plus logique d’ajouter un filtre directement dans l’espace qui existe déjà pour les plugins, puisque cette liste de plugins existe déjà, et qu’il y a déjà une liste de filtres. Pas besoin d’ouvrir un deuxième espace différent parlant des plugins d’une autre manière.

  Pour le scénario 1, c’est une évolution plus importante oui, mais avec une approche globale, non technique (on configure une fonctionnalité, pas un plugin).

  Pour le scénario 2, c’est quand on sait déjà que c’est plugin, et c’est alors une petite amélioration du bloc actuel. Dans ce cas, je disais que l’approche actuelle était déjà problématique en ergo de masquer des actions avec le hover. C’est pourquoi je proposais que si on améliorait un peu ces blocs, on corrige ce problème en même temps (juste ajouter le label pour Configurer, ne résoudrait pas le fait que les autres actions sont cachées). Si le menu ne convient pas, alors je préfère la solution où on affiche tout en permanence, car ça résout tous les problèmes à la fois pour config et pour les autres actions.

• Anomalie #3913 (Nouveau) : Restauration incomplète d’une sauvegarde effectuée avec la même version

  27 février 2017, par Gilles Corlobé

  J’utilise SPIP 3.2.0 dev (23435).
  J’ai effectué un dump puis une restauration de ce même fichier, à quelques heures d’intervalle.
  Pendant la restauration, je surveille le contenu de la base de données avec phpMyAdmin.
  Alors que les articles avaient été restaurés, avant le step 19, les données sont corrompues : la taille ne change pas mais les données sont inaccessibles (nombre de lignes dans spip_articles = 0, taille 41.7 Mo, perte 38.4 Mo).
  Version de PHP : 7.0.15-0ubuntu0.16.04.2
  Version du serveur : 5.7.17-0ubuntu0.16.04.1
  Apache/2.4.18 (Ubuntu)