C’est un bug, sans aucun doute. Nous allons devoir enquêter, bien vu !
Excellent, merci pour la PR, fusionnée !
![]()
Y a-t-il un moyen d’avoir la miniature sur la page de catégorie avec les derniers sujets également ?
Trois défis :
- Je suis à peu près sûr que les miniatures ne sont pas sérialisées ici. N’hésitez pas à confirmer. Cela pourrait être surmonté en améliorant le plugin sidecar.
- Quand j’ai examiné cela pour la dernière fois, la structure de la page ne permettait pas des remplacements à faible risque isolés à un modèle de feuille. Généralement, nous ne voulons pas remplacer la page entière, ce qui pourrait entraîner des changements perturbateurs ou masquer les mises à jour de fonctionnalités du cœur. Une PR vers le cœur pourrait aider ici…
- De l’espace ?
N’hésitez pas à soumettre les PR requises.
Points valides. Je choisirai peut-être une autre présentation pour les pages de catégorie, peut-être en boîte ou quelque chose comme ça.
J’ai une autre question.
Est-il possible que les pages de catégorie (qui contiennent des listes de sujets) s’affichent en vignettes sur mobile, mais avec des miniatures sur ordinateur ? J’ai essayé plusieurs réglages mais je n’ai pas réussi à l’obtenir.
edit : J’ai réussi. Je détaillerai comment j’ai fait un peu plus tard au cas où cela intéresserait quelqu’un, j’ai ajouté cette modification juste pour que personne ne passe du temps à m’expliquer comment faire ![]()
Alors, si je ne me trompe pas, voici les réglages…
Il faut d’abord que l’affichage en vignettes ne soit présent que dans la vue mobile de (au moins ?) une liste de sujets :
Ensuite les miniatures pour ordinateur ET mobile :
Je me suis trompé au début car je pensais que “vignettes” et “miniatures” étaient deux présentations différentes d’une liste de sujets, contenant toutes deux les images. mais ce n’est pas le cas. Les miniatures sont nécessaires si vous voulez que des images apparaissent sur une liste de sujets, qu’elle soit en vignettes ou non.
Il n’est pas nécessaire d’ajouter manuellement vos catégories ici :

Puisque nous allons outrepasser ce réglage en activant le suivant :

Maintenant, vous devriez avoir de petites miniatures sur ordinateur dans n’importe quelle liste de sujets (la plus récente, une catégorie spécifique, etc.), et une présentation “en vignettes” sur mobile avec de grandes miniatures :
J’ai un petit souci avec mon profil utilisateur, je suppose que c’est un petit bug :
Puisqu’il mentionne la miniature, je suppose que c’est lié à ce composant de thème.
Je continue de jouer avec ce composant de thème d’ailleurs… Et il est génial.
J’ai une question. Est-il possible d’empêcher un sujet d’avoir une miniature, même si le sujet en contient réellement ?
Voici mon cas :
J’ai une catégorie documentation pour laquelle les miniatures sont les bienvenues.
Mais j’ai aussi un sujet qui donne simplement des conseils généraux lors de la création d’un nouveau sujet :
Il n’y a pas d’image significative dedans, mais il ajoute automatiquement une miniature :
La seule façon que je vois pour contourner le problème est d’ajouter une image aléatoire à un moment donné dans le sujet, et de la définir comme miniature.
Exemple :
(mais j’avoue que ça rend bien quand même…)
Oui, cette localisation échoue et doit être corrigée. ![]()
Non, s’il y a une image, il essaiera de l’utiliser. Ajouter une image supplémentaire agréable est la solution parfaite ![]()
Cela améliorera également la cohérence de la mise en page de votre page.
Quoi qu’il en soit, j’utilise souvent un composant de sujets mis en avant (celui intégré de TLP ou un autre) pour résumer ce genre de publications en haut, donc avoir une image est très agréable.
J’essaie de restreindre la miniature et les vignettes à une balise spécifique en plus de certaines catégories, mais cela ne fonctionne pas pour les balises. Voici ma page de paramètres, je ne veux que des vignettes et des miniatures pour la balise mise en avant. Pouvez-vous me dire si je fais quelque chose de mal.
Il manque également une chaîne dans les paramètres du plugin :

Et un autre bug avec l’option l’extrait de la liste des sujets supprime les liens.
Donc, comme déjà signalé, si je la désactive, il n’y a plus de lien du tout, même leur texte, ainsi que le bouton “lire la suite” :
Si je l’active, les liens dans les extraits apparaissent, ainsi que le lien “lire la suite”, mais pour une raison quelconque,
-
Le lien “lire la suite” n’est pas stylisé comme un lien (également déjà signalé, mais comme tout est lié à la même option, je préfère regrouper tous les problèmes en une seule fois)
-
Certains extraits sont mal coupés. Quelques exemples :
Seule la première partie de la phrase de l’extrait est coupée ici :
Une ligne vide est coupée comme un extrait :
Je serais heureux d’aider davantage, mais malheureusement, je n’y connais rien aux plugins et à la plupart du code de Discourse… ![]()
cela ressemble à un bug, j’y jetterai un coup d’œil bientôt.
J’ai corrigé cela sur la branche beta. Pourriez-vous confirmer que tout semble bon maintenant, puis je fusionnerai.
Pour que cela fonctionne, vous devez supprimer tag et tag-mobile et ajouter le tag spécifique au paramètre de la liste des tags.
(Installez la version bêta comme un autre composant et associez-la à un thème de test).
Il s’est avéré être un changement majeur dans le cœur.
Utilisez le bouton avancé pour révéler la branche et tapez beta :
Si je n’ai pas de nouvelles de vous dans un moment, je fusionnerai quand même, mais voici votre chance de tester et de faire avancer cela.
Cela ne s’acquiert qu’en faisant
, un peu à la fois et en accumulant des connaissances au fur et à mesure
![]()
Il y a aussi une erreur JS lorsque nous naviguons sur le site web si le composant de thème est installé.
Elle est également visible sur votre propre site web : https://starzen.space/
Cliquez sur n’importe quel post et regardez la console JS.
TypeError: Cannot read properties of null (reading 'querySelector')
L’erreur est déclenchée sur cette ligne du fichier Discourse :
On dirait un changement majeur dans le noyau : FIX: Don't listen for focus/blur events if the topic-list opts out of… · discourse/discourse@97e7bb1 · GitHub
Principalement corrigé avec : COMPATIBILITY: add css class to tiles to support focus · merefield/discourse-tc-topic-list-previews@4f0f0f0 · GitHub
Correction sur la branche beta comme démontré sur mon site.
L’avantage de corriger cela de cette manière est que nous obtenons maintenant l’indicateur de la dernière visite sur la vignette ![]()
(La plupart des erreurs disparaissent également sur mobile, mais cet indicateur n’est normalement pas visible sur mobile de toute façon, donc je vais considérer cela comme corrigé !)
Je devrai suivre l’erreur moins fréquente liée à l’élément de titre.
Ceci est corrigé dans beta : FIX: missing localisation on user prefs and update locale paths
Merci !
Concernant l’option supprimer les liens de l’extrait de la liste de sujets du plugin, puis-je suggérer de modifier l’expression régulière que vous utilisez actuellement ?
URI::regexp supprimera toute chaîne qui a un modèle de lien, ce qui n’est, à mon avis, pas toujours souhaitable.
Les liens ont parfois le même contenu textuel que leur valeur href. C’est même un cas très courant dans n’importe quel forum, et la suppression du contenu textuel peut conduire à des extraits bizarres avec des phrases qui n’ont pas de sens.
Cette expression régulière supprimera également des mots qui sont à l’intérieur ou à l’extérieur des liens parfois. Je donne des exemples ci-dessous.
Voici une comparaison avec une autre expression régulière : \u003ca .+?\\\u003e(.+)?\u003c\\/a\u003e
Ce n’est qu’un exemple d’expression régulière ; je comprends que URI::regexp couvre les liens d’une manière plus complexe (et supposément plus fiable).
Voici un exemple de publication :
Et les extraits résultants dans la liste des sujets :
URI::regexp
\u003cbig\u003e↓\u003c/big\u003e
(le contenu textuel du lien Facebook est supprimé, et il a également supprimé le mot “Day” dans “Astronomy Picture of the Day” pour une raison inconnue
\u003ca .+?\\\u003e(.+)?\u003c\\/a\u003e
\u003cbig\u003e↓\u003c/big\u003e
Un autre exemple, juste à propos d’un contenu textuel de lien supprimé qui rend l’extrait étrange à lire :
URI::regexp
\u003cbig\u003e↓\u003c/big\u003e
(“le lien était This may be my favorite halo”… ?)
\u003ca .+?\\\u003e(.+)?\u003c\\/a\u003e
\u003cbig\u003e↓\u003c/big\u003e
(maintenant, cela a du sens)
Je ne suggère donc pas que \u003ca .+?\\\u003e(.+)?\u003c\\/a\u003e soit mieux, c’était juste un test rapide, mais je ne suis pas sûr que l’utilisation de URI::regexp soit le meilleur choix en ce qui concerne les résultats, et ce pour les deux raisons que j’ai mentionnées : le contenu textuel du lien disparaît, rendant parfois les extraits étranges, et il supprime également des mots à l’intérieur ou à l’extérieur des liens de temps en temps pour une raison obscure. Ce dernier problème semble suffisamment fréquent pour ne pas être négligeable.
J’apprécie les inconvénients de la méthode actuelle (y compris l’enthousiasme étrangement excessif de l’algorithme actuel qui supprime trop), mais nous en sommes arrivés là par l’expérience.
La principale raison pour laquelle cette option existe est en fait de :
- préserver la mise en forme de l’aperçu lorsque les liens sont très longs (c’est-à-dire supprimer tous les liens afin qu’un lien long ne s’infiltre jamais dans l’extrait pour causer des problèmes). Essayez le scénario où un lien est très, très long. L’ancien sujet de support est jonché de problèmes avec les publications de sujets contenant de longs liens.
- préserver l’extrait comme une surface de clic prévisible où il naviguera toujours vers le sujet. Le texte est trop petit pour que cela soit discrétionnaire.
Devrait également être :
- simple à maintenir et ne pas générer de bruit de support. Parce que la méthode actuelle est une classe utilitaire prise en charge, je n’ai pas à m’en soucier de la maintenir.
Je ne suis pas encore convaincu que nous devions changer cela pour le grand public ?
Je pourrais être ouvert à en faire une sélection de trois options, DÉSACTIVÉ, sans liens (c’est-à-dire la méthode actuelle) et expérimental ? PR bienvenu. Je vais d’abord déplacer le code sidecar actuel vers la branche principale du plugin. J’essaierai de le faire cette semaine.
Merci pour votre réponse ![]()
J’ai corrigé la dernière phrase de mon précédent message, j’avais oublié un mot…
J’avais écrit
et il supprime aussi des mots à l’intérieur ou à l’extérieur des liens de temps en temps pour une raison obscure. Ce dernier problème semble suffisamment fréquent pour être négligeable.
J’ai oublié un « pas », donc…
et il supprime aussi des mots à l’intérieur ou à l’extérieur des liens de temps en temps pour une raison obscure. Ce dernier problème semble suffisamment fréquent pour ne pas être négligeable.
Je ne comprends peut-être pas grand-chose au code, mais j’essaierai de comprendre et de corriger le problème numéro 2 que j’ai mentionné ici : Topic List Previews (TLP) - #110 by Canapin aujourd’hui.
(les extraits ne sont pas correctement encapsulés par .topic-excerpt : l’encapsuleur semble se fermer juste avant le premier lien présent dans l’extrait au lieu de la fin de l’extrait)
Pour être honnête, la meilleure approche serait peut-être de signaler un problème au mainteneur de cet utilitaire et de lui demander de le corriger ? Il ne se comporte certainement pas comme on pourrait s’y attendre ?
Oui, je n’ai pas encore regardé ça. N’hésitez pas à soumettre une PR pour une correction en attendant.
Merci, je n’y avais pas pensé, je n’avais aucune idée d’où venait cet utilitaire.
Après quelques recherches, en gros, l’expression régulière reconnaît à peu près n’importe quel mot ou chaîne de caractères comme faisant partie d’un schéma URI tant qu’il est immédiatement suivi d’un deux-points - c’est-à-dire sans espace entre les deux -, ce qui est compréhensible, mais aussi un peu excessif car dans la langue anglaise (contrairement à la langue française, par exemple), nous ne mettons pas d’espace entre un mot et un deux-points. D’où des mots “légitimes” qui sont mangés par l’expression régulière simplement parce qu’ils sont malheureusement suivis d’un deux-points.
Une solution pourrait être d’avoir un champ (non pré-rempli pour éviter tout dommage dans les installations existantes) dans les paramètres du plugin pour saisir le(s) schéma(s) que nous voulons supprimer.
Par exemple, le paramètre pourrait être :
Schémas URI à supprimer : http|https|ftp|mailto
Cela donnerait :
#{URI::regexp(['http', 'https', 'ftp', 'mailto'])}
(mais c’est malheureusement sensible à la casse, mais cela peut sûrement être ajusté d’une manière ou d’une autre)
Si le paramètre est vide, alors ce serait ce qui serait utilisé :
#{URI::regexp}
Ce qui correspond au comportement actuel.
Une pull request avec un tel paramètre serait-elle la bienvenue ?























