Recherche avancée

Sur d’autres sites (16631)

• 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... :-(

• Anomalie #3566 (Nouveau) : Restaurer une révision ne restaure pas toujours tous les champs modifiés

  12 octobre 2015, par marcimat ☺☮☯♫

  Deux cas de figure remarqués :

  Cas A
  - Créer une version avec un champ révisable vide, par exemple un article avec un texte vide.
  - Modifier cet article en ajoutant un texte
  - Si l’on fait afficher l’historique des modifications, et qu’on demande à Restaurer la version précédente, le texte est rempli avec le contenu actuel, alors qu’il était vide à la version précédente.

  Cas B
  - Créer plusieurs révisions sur des champs différents (pour aller vite, alterner des modifications entre 2 auteurs, sinon il faut attendre un certain temps si on utilise le même auteur pour que les modifications fassent des révisions différentes)
  - Imaginons qu’on a effectué 7 révisions, et qu’on affiche dans l’historique des modifications la différence entre la version 7 et la version 2
  - On voit l’ensemble des champs modifiés
  - En cliquant alors le lien « Restaurer la version n°2 », seuls les champs modifiés par la version n°2 apparaissent changés dans le formulaire. Les champs modifiés ENTRE la version courante et la version 2 ne reviennent pas au contenu qu’ils avaient en version 2. Du coup, tout ne revient pas dans l’état de modification de la version 2

  Ce me semble 2 bugs assez ennuyant.

• Anomalie #3535 : liste des rédacteurs connectés

  20 août 2015, par Pierre KUHN

  Frank, c’est aussi le cas en 3.0.29 ou la valeur par défaut est vide.