Puoi probabilmente farlo con un po’ di CSS.
Prima dell’ultimo messaggio, ho provato quanto segue. Ha risolto il problema con la dimensione del carattere della funzionalità, ma ha reso la dimensione del carattere dell’elenco degli argomenti della home page super piccola.
.featured-topic {
font-size: 9px;
}
Ti riferisci a questi link?
Non vedo cambiamenti nel resto della pagina se modifico quello.
Puoi vedere l’elenco degli argomenti qui sotto dopo aver applicato il codice CSS sopra. La dimensione del carattere è diventata piuttosto piccola.
Rimosso il codice CSS e la dimensione del carattere nell’elenco degli argomenti è tornata normale.
Giusto. Prova questo:
.featured-topic h3 a {
font-size: 9px;
}
1 Mi Piace
Grazie! Funziona!
1 Mi Piace
Richiesta di funzionalità: si prega di aggiungere la possibilità di mostrare un estratto dell’argomento
È possibile che la funzione Tag sia difettosa o si comporti in modo imprevisto quando si lavora con un Gruppo di Tag con restrizioni?
Ho creato un Gruppo di Tag con la seguente restrizione:
I tag sono visibili a tutti, ma solo i seguenti gruppi possono usarli
- Amministratori, Moderatori
Ho aggiunto il Tag ‘featured’ da questo componente a questo Gruppo.
Queste sono le impostazioni del mio componente:
Quando creo un argomento come Amministratore con il Tag ‘featured’, il tag è visibile a me e ai moderatori, ma non agli altri Gruppi di Utenti. Per gli altri Utenti registrati mostra esattamente così:
Tag1, Tag2,
Per Amministratori e Moderatori, il Tag ‘featured’ apparirà correttamente:
Tag1, Tag2, featured
Un’altra cosa: se è nascosto, penso che la virgola non dovrebbe apparire. Questo confonde gli utenti.
Inoltre, non sono sicuro se sia rilevante, ma i thread sono in categorie visibili solo agli Utenti registrati, non agli Ospiti.
Ah, e a proposito: grazie per il componente, ottimo lavoro! A parte questa piccola funzione, per me funziona perfettamente!
Ahah, ho trovato il mio vecchio argomento mentre cercavo una piccola seccatura 
Così ho appena realizzato (di nuovo) che le immagini effettivamente caricate sono enormi rispetto alle loro dimensioni reali di rendering. Nel mio caso, sta caricando un’immagine di 1000x1000px e la renderizza a < 200px.
Ho controllato alcuni dei dati e se potessi sostituirle con la versione 400x400px, risparmierei circa l’83% di banda (per la riga in evidenza), o 1,6 MB in totale. So che queste immagini sono in cache, ma questo avrà sicuramente un impatto sul caricamento iniziale della pagina e immagino che non aiuti nemmeno ad accelerare il rendering della pagina? Sto usando queste immagini in evidenza su ogni pagina del mio forum, quindi penso che l’impatto sia reale.
Sarebbe possibile aggiungere un’opzione alla configurazione del TC per consentirci di scegliere quale dimensione dell’immagine usare, così che tutti possano personalizzarla per il proprio tema?
1 Mi Piace
Ottimo accorgimento! Era da un po’ che non esaminavo questo componente, quindi ho potuto effettuare una revisione generale per miglioramenti:
https://github.com/discourse/discourse-homepage-feature-component/pull/96
Questo aggiorna le immagini per utilizzare srcset, in modo che l’immagine appropriata per il contenitore venga utilizzata automaticamente. Le dimensioni disponibili possono essere impostate tramite una nuova impostazione featured_image_sizes.
Ho anche corretto l’impostazione hide featured tag (non funzionava, quindi i tag erano sempre nascosti) e l’ho aggiornata all’impostazione di tipo tag invece che all’input di testo semplice. Questo significa inoltre che, se desiderato, possono essere utilizzati più tag.
1 Mi Piace
Ottimo, grazie! Credo che questo risolva anche il problema con il tag “in evidenza” mancante, che era davvero un enigma.
Una cosa però: dopo l’aggiornamento, sono stati avviati TANTISSIMI lavori di elaborazione delle immagini - ne ho oltre 20.000 in coda ora. È normale? Sembra piuttosto uno spreco, dato che mi servono davvero solo gli ultimi 5..
1 Mi Piace
Mmm, sì, hai ragione, purtroppo non c’è modo di evitarlo. Penso che valga la pena annullare quella modifica proprio per questo. Sto facendo proprio questo qui:
La realtà è che non posso generare un sottoinsieme mirato di immagini miniature ottimizzate da un tema in questo modo, deve essere tutto o niente. Quindi avremo bisogno di un altro metodo per ottimizzare casi più limitati come questo.
1 Mi Piace
Capito. Le miniature non necessarie verranno rimosse automaticamente in seguito?
E sembra che il mio tema abbia già una serie di diversi formati immagine che potrebbero funzionare bene - come il 400x400 o il 500x500. Che ne dite di renderli selezionabili? Rispetto al 1024x1024 attualmente utilizzato, questo fornirebbe già un bel risparmio di banda, senza sovraccarico aggiuntivo di elaborazione/archiviazione.
(ignora quelli 300x300, 600x600 e 900x900 aggiunti dall’aggiornamento 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 Mi Piace
Non credo di sì, perché le immagini originali sono ancora in uso e queste sono versioni ottimizzate. Nessun vero danno, a parte occupare un po’ di spazio di archiviazione.
Potresti ripulirle dalla console Rails, questo copre le dimensioni incluse di default per l’impostazione, e non rimuoverà le immagini generate da un modificatore altrove.
# 1. Verifica cosa esiste realmente rispetto a ciò che è ancora legittimamente registrato
still_needed = Topic.thumbnail_sizes +
ThemeModifierHelper.new(theme_ids: Theme.pluck(:id)).topic_thumbnail_sizes
TopicThumbnail.group(:max_width, :max_height).count
# 2. Rimuovi le dimensioni indesiderate (file + record)
[[300, 300], [600, 600], [900, 900]].each do |w, h|
next if still_needed.include?([w, h]) # non toccare le dimensioni ancora utilizzate da qualcos'altro
TopicThumbnail
.where(max_width: w, max_height: h)
.find_each { |tt| tt.optimized_image&.destroy! }
# i record di tentativo senza immagine ottimizzata non fanno cascata
TopicThumbnail.where(max_width: w, max_height: h).delete_all
end
Oh sì, buona idea — posso verificare quali miniature esistono già e, se ce ne sono, usare la dimensione migliore. Se sono disponibili solo gli originali, funzioneranno sempre come fallback.
Sto lavorando a questo qui:
2 Mi Piace
Fantastico, lo testerò stasera!
E stavo proprio tornando qui per riesporre una vecchia richiesta mia: sarebbe possibile aggiungere un’opzione per ordinare la riga degli elementi in evidenza in base alla data di assegnazione del tag? Il nostro ordine di evidenziazione non è determinato dalla data di creazione di un argomento né dall’ultima attività - per noi è il momento in cui applichiamo il tag che dovrebbe determinare l’ordine. Non me ne ero reso conto prima, ma la nostra riga degli elementi in evidenza è un po’ un casino al momento 
1 Mi Piace
Purtroppo non credo sia possibile… non abbiamo un modo per ordinare un elenco di argomenti in base al momento in cui è stato aggiunto un tag. Un modo per aggirare il problema potrebbe essere quello di modificare il timestamp dell’argomento?
1 Mi Piace
Nessun problema. Sto aggirando il problema al momento con un po’ di nastro adesivo: ho creato una fork del tuo TC e una query Data Explorer per recuperare gli argomenti in evidenza, ordinati per data di taggatura e includendo gli URL delle immagini. Un piccolo script web esterno carica e memorizza in cache questi dati e restituisce il JSON al TC. Funziona alla grande, anche se è un po’ brutto
Sono felice di condividere il mio codice e la query se qualcuno ne ha bisogno.
2 Mi Piace
Aggiornamento: Ok, mi sono reso conto che questo era solo metà del mio problema. Utilizziamo anche la Homepage Feature TC per mostrare una galleria delle opere in evidenza. E l’ordine di ordinamento della galleria ora non corrispondeva più a quello della nostra riga in evidenza, il che confondeva i visitatori (e mi infastidiva). Quindi la galleria doveva essere ordinata anche per data di tagging - non solo per data di creazione dell’argomento o ultima attività.
Ed è qui che sono diventato un “ragazzo cattivo” e mi sono rivolto a Claude Code per aiutarmi. Prima, gli ho fatto creare un piccolo plugin per aggiungere un’opzione per ordinare le liste di tag per data di tagging, come /tag/featured?order=tag_date.
Una volta funzionante, ho esteso l’opzione di ordinamento nella Homepage Feature TC aggiungendo tag_date. Ho anche cambiato il widget da caselle di spunta a menu a tendina:
E voilà! Ora ho una riga in evidenza che si comporta come voglio (e, francamente, come credo dovrebbe ), E una galleria che corrisponde:
Se qualcuno vuole provarlo, ecco il mio codice:
- Plugin discourse-sort-by-tagging-date
- Componente Homepage Feature con supporto per la nuova opzione tag_date
Potete vederlo in azione su https://blenderartists.org/
Avvertimento: tutto questo è lavoro di Claude Code. Ho revisionato quello che potevo ma in definitiva non sono un esperto in questo. Aggiornerrò questi componenti come necessario poiché sono una parte fondamentale della nostra comunità di grafica 3D.
Buon divertimento!
1 Mi Piace