Recherche avancée

Sur d’autres sites (2678)

• Anomalie #4751 : Refonte du jeu d’icônes : retours et commentaires

  29 avril 2021

  C’est un immense et chouette boulot que tu as fait avec toutes ces icones personnalisées !
  Et c’est très bien.

  J’espère n’énerver personne pour la suite :p
  J’ai principalement 2 remarques :

  - la première et principale concerne l’icone de rubrique, qui pour moi ne se détache pas assez du fond (ça dépend du thème aussi et où elle est utilisée). Tu as proposé un contour sympa sur le plugin archiviste. Ce contour, plus un peu de couleur serait probablement intéressant.

  - la seconde concerne l’épaisseur des traits, qui n’est pas toujours identique (plus fin généralement) sur certaines icones. C’est pas dramatique, mais par cohérence si c’était la même taille ça serait cool. Je pense à notamment à
  - "suivi des révisions" ,
  ou "plan du site" (celui du bandeau du moins)
  - ou "vider le cache" (qui lui est plus gros)

  une 3è : chez moi l’icone "agenda interne" a un reflet contrairement aux autres (à moins que ce ne soit du au plugin agenda)
  - une 4è : l’icone "gestion des plugins" est un peu comme la rubrique, jaune sans contour, dans certaines situations elle se détache mal

  Le reste des remarques sont des détails et mes préférences, sans drame apparent, à voir selon les humeurs et d’autres avis :

  - certaines icones sont en fond plein (mots par exemple), ça sort un peu de l’apparence filaire des autres
  - une petite touche de couleur sur certaines icones était sympa (article, ou mot, a perdu sa touche de couleur par exemple)
  - le A (français) des icones de langues a le trou du A central à peine visible en petit. Il semble très légèrement trop épais quoi
  - « fonctions avancée" : 1 seul outil avec un engrenage ?
  - "identité du site" : je suis pas fan du terminal (je n’avais absolument pas compris l’analogie), mais s’il est conservé, mettre un peu plus de contraste entre les gris ?
  - je n’ai pas vu comment était la boite du compagnon récemment, mais son logo, je ne suis pas sûr de l’intérêt d’avoir son contour plus épais que les autres
  - SVP : je ne comprends toujours pas l’analogie (tu as repris la même qu’avant donc… bon…)
  - Plugin "Dev" : chez moi il a une icone différente des autres plugins du core ?
  - le "auteur" (le vert surtout, et jaune aussi) sont pas facile à voir. Peut être qu’augmenter la taille du buste par rapport à la tête aiderait ?

  ---

  Et sinon, la vue des logos des plugins du core est trop chouette ! C’est magnifique cet ensemble !

• Anomalie #3462 (Nouveau) : Gestion des documents utilisés dans les rubriques - suppression impossi...

  5 juin 2015, par Pascal Verrier

  Bonjour,

  Je constate une modification liée à l’utilisation de documents/images au sein du texte explicatif d’une rubrique.
  Dans SPIP 2.1.27 l’édition de rubrique permet l’ajout de documents (bloc Ajouter une image à gauche), cette fonctionnalité a apparemment été supprimée dans la 3.0.19.

  Cela n’interdit pas de saisir des codes type (correspondant à des éléments de la médiathèque chargés auparavant) dans le texte de description de la rubrique, ce qui permet d’utiliser ces contenus dans la présentation d’une rubrique : ils sont bien affichés, mais contrairement à ce qui se passait sur les versions précédentes, on n’a pas en bas de page rubrique du backoffice (exec=naviguer&id_rubrique=N) le rappel des documents liés, or en regardant dans la médiathèque on peut constater que le lien a bien été réalisé (lors de l’enregistrement) entre les documents utilisés et la rubrique.

  Cela se complique lorsque l’on décide de supprimer une rubrique utilisant, ou ayant utilisé des documents.

  Si je reprends ma rubrique, j’en supprime ou déplace tous les articles, j’en supprime le contenu texte, je n’obtiens jamais le bouton "Supprimer cette rubrique". En fait les documents utilisés y sont liés et tant que ces liens existent la suppression est impossible. C’est le même comportement que sur les versions précédentes* à cela près que l’absence de la liste des documents liés (normalement affichés en bas de page, ou à gauche en édition) n’aide pas vraiment à comprendre pourquoi cette rubrique ne peut être supprimée. Seul indice, sous l’identifiant de rubrique est indiqué "N documents". Autre curiosité la rubrique est d’office considérée comme active, et elle apparaît sur l’espace public, même si elle ne contient aucun article. C’est ainsi que l’on se retrouve avec une rubrique vide, impossible à supprimer, et affichée dans les menus de l’espace public.

  En supprimant manuellement les liens document/rubrique depuis la médiathèque le lien "Supprimer cette rubrique" réapparaît.

  (* : je ne suis pas certain par ailleurs que le fait de ne pas pouvoir supprimer une rubrique à laquelle des documents sont liés soit réellement justifié)

  Ce choix de supprimer l’ajout de documents dans l’édition de rubriques est-il intentionnel ? Pourrait-on retrouver le mécanisme existant dans les articles et dans SPIP 2.1 ?
  Serait-il envisageable de pouvoir supprimer directement une rubrique vide sans avoir à se préoccuper de l’existence de ces liens avec les documents ?
  Merci.

• Anomalie #2884 : un modèle doc dans une liste, interrompt l’énumération

  11 août 2014, par cedric -

  En fait le problème vient de http://core.spip.org/projects/spip/repository/entry/branches/spip-3.0/ecrire/inc/texte_mini.php#L80 qui ajoute 2 retours ligne après un modèle de type bloc (comme doc ou img avec legende), ce que le traitement des listes interprete ensuite comme une fermeture/reouverture d’une nouvelle liste.
  Il faudrait se passer de ces 2 retours ligne forcé ici, car normalement paragrapher est censé faire proprement le boulot ensuite. Si l’on ne mets qu’un seul retour ligne cela corrige le bug, mais je crains que cela ne casse autre chose, il nous manque vraiment des tests unitaires complets pour propre avec autant de test-cases que possible pour savoir ce que l’on fait.

  Cf ce que l’on dispose dans la plugin markdown :

  https://github.com/Cerdic/markdown/tree/master/tests/data/typo
  adapté des tests unitaires du parseur ParseDown https://github.com/Cerdic/markdown/tree/master/lib/parsedown/test/data

  et les variantes
  https://github.com/Cerdic/markdown/tree/master/tests/data/modeles_spip_inline
  https://github.com/Cerdic/markdown/tree/master/tests/data/modeles_spip_block
  https://github.com/Cerdic/markdown/tree/master/tests/data/liens_spip

  Peut-être on pourrait utiliser cette base pour construire une base de tests pour la syntaxe SPIP, quitte à generer un point de départ à partir de sale(*.html), repasser à la main dessus pour verification, puis regenerer la sortie html avec propre(), ce qui nous donnerait un etat de l’art.

  A partir de là on peut checker un minimum tout risque de casse lié à un bugfix.

  Je propose donc de repousser la résolution de ce ticket à SPIP 3.1