Vous pouvez probablement le faire avec un peu de CSS.
Avant le dernier message, j’ai essayé ce qui suit. Cela a résolu le problème de la taille de police de la fonctionnalité, mais cela a rendu la taille de police de la liste des sujets de la page d’accueil minuscule.
.featured-topic {
font-size: 9px;
}
Faites-vous référence à ces liens ?
Je ne vois aucun changement sur le reste de la page si je modifie cela.
Vous pouvez voir la liste des sujets ci-dessous après avoir appliqué le code CSS ci-dessus. La police est devenue très petite.
J’ai supprimé le code CSS, et la taille de la police dans la liste des sujets est redevenue normale.
D’accord. Essayez ceci :
.featured-topic h3 a {
font-size: 9px;
}
1 « J'aime »
Merci ! Ça fonctionne !
1 « J'aime »
Demande de fonctionnalité : veuillez ajouter la possibilité d’afficher un extrait du sujet
Est-il possible que la fonctionnalité de Tag soit boguée ou se comporte de manière inattendue lors de l’utilisation d’un Groupe de Tags restreint ?
J’ai créé un Groupe de Tags avec la restriction suivante :
Les Tags sont visibles par tout le monde, mais seuls les groupes suivants peuvent les utiliser
- Admins, Modérateurs
J’ai ajouté le Tag ‘featured’ de ce composant à ce Groupe.
Voici les paramètres de mon composant :
Lorsque je crée un sujet en tant qu’Admin avec le Tag ‘featured’, le tag est visible pour moi et pour les modérateurs, mais pas pour les autres groupes d’utilisateurs. Pour les autres utilisateurs enregistrés, il s’affiche exactement comme ceci :
Tag1, Tag2,
Pour les Admins et les Mods, le Tag ‘featured’ s’affiche correctement :
Tag1, Tag2, featured
Autre chose : s’il est masqué, je pense que la virgule ne devrait pas s’afficher. Cela prête à confusion pour les utilisateurs.
Je ne suis pas sûr que ce soit pertinent, mais les fils de discussion se trouvent dans des catégories qui ne sont visibles que pour les utilisateurs enregistrés, et non pour les Invités.
Ah, et au fait : Merci pour le composant, excellent travail ! À part ce petit détail de fonctionnalité, il fonctionne parfaitement pour moi !
Haha, je suis tombé sur mon ancien sujet en cherchant une petite nuisance 
Je viens donc de réaliser (encore une fois) que les images réellement chargées sont énormes par rapport à leur taille d’affichage effective. Dans mon cas, une image de 1000x1000px est chargée pour être affichée à < 200px.
J’ai vérifié quelques données, et si je pouvais les remplacer par la version 400x400px, cela économiserait environ 83 % de bande passante (pour la rangée mise en avant), soit 1,6 Mo au total. Je sais que ces images sont mises en cache, mais cela aura certainement un impact sur le chargement initial de la page, et je suppose que cela ne contribue pas non plus à accélérer le rendu de la page ? J’utilise ces images mises en avant sur chaque page de mon forum, donc je pense que l’impact est réel.
Serait-il possible d’ajouter une option à la configuration du TC pour nous permettre de choisir la taille d’image à utiliser, afin que chacun puisse l’adapter à son propre thème ?
1 « J'aime »
Bien vu ! Ça fait un moment que je n’avais pas regardé ce composant, donc j’ai pu faire un passage d’amélioration générale :
https://github.com/discourse/discourse-homepage-feature-component/pull/96
Cela met à jour les images pour utiliser srcset, de sorte que l’image appropriée pour le conteneur est utilisée automatiquement. Les tailles disponibles peuvent être définies à l’aide d’un nouveau paramètre featured_image_sizes.
J’ai également corrigé le paramètre hide featured tag (il ne fonctionnait pas, donc les tags étaient toujours masqués) et mis à jour le type de paramètre des tags plutôt que l’entrée de texte brut. Cela signifie également que plusieurs tags peuvent être utilisés si nécessaire.
1 « J'aime »
Super, merci ! Je pense que cela règle également le problème du tag « à la une » manquant, qui était vraiment intriguant.
Cela dit : depuis la mise à jour, cela a déclenché BEAUCOUP de tâches de traitement d’images — j’en ai plus de 20 000 en file d’attente maintenant. Est-ce normal ? Cela semble plutôt gaspilleur, car je n’ai réellement besoin que des 5 dernières…
1 « J'aime »
Hmm oui, bon point, malheureusement il n’y a pas moyen d’éviter cela. Je pense qu’il vaut probablement mieux annuler cette partie à cause de ça. Je m’en occupe ici :
La réalité est que je ne peux pas produire un sous-ensemble ciblé d’images miniature optimisées à partir d’un thème de cette façon, c’est tout ou rien. Nous aurons donc besoin d’une autre méthode pour optimiser les cas plus limités comme celui-ci.
1 « J'aime »
Compris. Les miniatures inutiles seront-elles automatiquement supprimées plus tard ?
Et il semble que mon thème dispose déjà d’un certain nombre de formats d’image différents qui pourraient convenir — comme le 400x400 ou le 500x500. Pourquoi ne pas les rendre sélectionnables ? Par rapport au format 1024x1024 actuellement utilisé, cela permettrait déjà de faire de belles économies de bande passante, sans surcoût de traitement ni d’espace de stockage.
(ignorer les formats 300x300, 600x600 et 900x900 ajoutés par la mise à jour de TC) :
-rw-r--r-- 1 1000 www-data 723K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_1000x1000.jpeg
-rw-r--r-- 1 1000 www-data 757K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_1024x1024.jpeg
-rw-r--r-- 1 1000 www-data 30K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_200x200.jpeg
-rw-r--r-- 1 1000 www-data 68K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_300x300.jpeg
-rw-r--r-- 1 1000 www-data 118K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_400x400.jpeg
-rw-r--r-- 1 1000 www-data 185K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_500x500.jpeg
-rw-r--r-- 1 1000 www-data 263K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_600x600.jpeg
-rw-r--r-- 1 1000 www-data 417K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_750x750.jpeg
-rw-r--r-- 1 1000 www-data 470K Jun 23 21:32 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_800x800.jpeg
-rw-r--r-- 1 1000 www-data 595K Jun 30 22:18 80c77ac08d5671a1dc6d2a15ddea28e6d56f98c9_2_900x900.jpeg
1 « J'aime »
Je ne pense pas, car les images sources sont toujours utilisées et celles-ci en sont des versions optimisées. Aucun réel inconvénient, à part occuper de l’espace de stockage.
Vous pourriez les nettoyer depuis la console Rails. Cela couvre les tailles incluses par défaut pour ce paramètre, et ne supprimera pas les images générées par un modificateur ailleurs.
# 1. Voir ce qui existe réellement par rapport à ce qui est encore légitimement enregistré
still_needed = Topic.thumbnail_sizes +
ThemeModifierHelper.new(theme_ids: Theme.pluck(:id)).topic_thumbnail_sizes
TopicThumbnail.group(:max_width, :max_height).count
# 2. Supprimer les tailles indésirables (fichiers + enregistrements)
[[300, 300], [600, 600], [900, 900]].each do |w, h|
next if still_needed.include?([w, h]) # ne pas toucher aux tailles encore utilisées par autre chose
TopicThumbnail
.where(max_width: w, max_height: h)
.find_each { |tt| tt.optimized_image&.destroy! }
# les enregistrements « attempt » sans image optimisée ne sont pas en cascade
TopicThumbnail.where(max_width: w, max_height: h).delete_all
end
Ah oui, bonne idée — je peux vérifier quelles miniatures existent déjà et, s’il y en a, utiliser la meilleure taille. Si seules les originales sont disponibles, cela fonctionnera toujours comme solution de repli.
Je le fais ici :
2 « J'aime »
Super, je vais tester ça ce soir !
Et je revenais justement ici pour remettre sur le tapis une vieille demande : serait-il possible d’ajouter une option pour trier la ligne des sujets en vedette par date de marquage ? L’ordre de mise en vedette chez nous n’est pas déterminé par la date de création du sujet ni par la dernière activité — c’est le moment où on applique le tag qui doit définir l’ordre. Je ne m’en étais pas rendu compte avant, mais notre ligne des sujets en vedette est un peu le chaos en ce moment 
1 « J'aime »
Malheureusement, je ne pense pas que ce soit possible… nous n’avons pas de moyen de trier une liste de sujets par la date d’ajout d’un tag. Une solution de contournement consisterait à modifier la date de publication du sujet ?
1 « J'aime »
Pas de souci. Je contourne le problème pour l’instant avec un peu de « ruban adhésif » : j’ai créé une copie de votre TC et écrit une requête Data Explorer pour récupérer les sujets en vedette, triés par date de balisage et incluant les URLs des images. Un petit script web externe charge et met en cache ces données, puis renvoie le JSON à la TC. Ça fonctionne comme sur des roulettes, même si c’est un peu moche
Je suis heureux de partager mon code et ma requête si quelqu’un en a besoin.
2 « J'aime »
Mise à jour : Bon, j’ai réalisé que ce n’était en fait que la moitié de mon problème. Nous utilisons également le composant « Fonctionnalité de la page d’accueil » pour afficher une galerie des œuvres mises en avant. Et l’ordre de tri de la galerie ne correspondait plus à celui de notre rangée d’œuvres mises en avant, ce qui a perturbé les visiteurs (et m’a agacé). Donc, la galerie devait également être triée par date de balisage — et non seulement par date de création du sujet ou dernière activité.
C’est là que je suis devenu un « méchant garçon » et que j’ai fait appel à Claude Code pour m’aider. D’abord, je lui ai demandé de créer un petit plugin pour ajouter une option permettant de trier les listes de balises par date de balisage, comme /tag/featured?order=tag_date.
Une fois que cela a fonctionné, j’ai étendu l’option de tri dans le composant « Fonctionnalité de la page d’accueil » en ajoutant tag_date. J’ai également remplacé les cases à cocher du widget par un menu déroulant :
Et voila ! J’ai maintenant une rangée d’œuvres mises en avant qui se comporte comme je le souhaite (et, franchement, comme je pense qu’elle devrait se comporter ), ET une galerie qui correspond :
Si quelqu’un veut essayer, voici mon code :
- Plugin discourse-sort-by-tagging-date
- Composant Fonctionnalité de la page d’accueil avec prise en charge de la nouvelle option tag_date
Vous pouvez le voir en action sur https://blenderartists.org/
Avertissement : tout cela est le travail de Claude Code. J’ai revu ce que j’ai pu, mais je ne suis pas un expert en la matière. Je mettrai ces éléments à jour au fur et à mesure, car ils constituent une partie clé de notre communauté de graphistes 3D.
Amusez-vous bien !
1 « J'aime »