Você provavelmente pode fazer isso com algum CSS.
Antes da última mensagem, tentei o seguinte. Isso corrigiu o problema com o tamanho da fonte do recurso, mas tornou o tamanho da fonte da lista de tópicos do restante da página inicial muito pequeno.
.featured-topic {
font-size: 9px;
}
Você está se referindo a estes links?
Eu não vejo nenhuma alteração no resto da página se eu mudar isso.
Você pode ver a lista de tópicos abaixo depois que apliquei o código CSS acima. A fonte ficou bem pequena.
Removi o código CSS, e o tamanho da fonte na lista de tópicos voltou ao normal.
Certo. Tente isto:
.featured-topic h3 a {
font-size: 9px;
}
1 curtida
Obrigado! Está funcionando!
1 curtida
Solicitação de recurso: por favor, adicione a capacidade de mostrar um trecho do tópico
É possível que o recurso de Tag esteja com falhas ou se comportando de forma inesperada ao trabalhar com um Grupo de Tags restrito?
Criei um Grupo de Tags com a seguinte restrição:
As Tags são visíveis para todos, mas apenas os seguintes grupos podem usá-las
- Administradores, Moderadores
Adicionei a Tag ‘featured’ deste componente a este Grupo.
Estas são as configurações do meu componente:
Quando crio um tópico como Administrador com a Tag ‘featured’, a tag fica visível para mim e para os moderadores, mas não para outros Grupos de Usuários. Para outros Usuários registrados, ela aparece exatamente assim:
Tag1, Tag2,
Para Administradores e Moderadores, a Tag ‘featured’ aparecerá corretamente:
Tag1, Tag2, featured
Outra coisa: se estiver oculta, acho que a vírgula não deveria aparecer. Isso confunde os usuários.
Além disso, não tenho certeza se isso é relevante, mas os tópicos estão em categorias que são visíveis apenas para Usuários registrados, não para Convidados.
Ah, e a propósito: Obrigado pelo componente, trabalho incrível! Exceto por esse pequeno recurso, ele funciona perfeitamente para mim!
Ha, encontrei meu próprio tópico antigo enquanto procurava por uma pequena irritação 
Acabei de perceber (novamente) que as imagens reais que são carregadas são enormes em comparação com seu tamanho real renderizado. No meu caso, está carregando uma imagem de 1000x1000px e renderizando-a em < 200px.
Verifiquei alguns dos dados, e se eu pudesse substituí-las pela versão de 400x400px, isso economizaria cerca de 83% de banda (para a linha em destaque), ou 1,6 MB no total. Sei que essas imagens são armazenadas em cache, mas isso definitivamente terá impacto no carregamento inicial da página, e acho que também não ajudará a acelerar a renderização da página, certo? Estou usando essas imagens em destaque em todas as páginas do meu fórum, então acho que o impacto é real.
Seria possível adicionar uma opção à configuração do TC para nos permitir escolher qual tamanho de imagem usar, para que todos possam ajustar isso ao seu próprio tema?
1 curtida
Boa pegadinha! Faz um tempo que não olhava para esse componente, então consegui fazer uma revisão geral de melhorias:
https://github.com/discourse/discourse-homepage-feature-component/pull/96
Isso atualiza as imagens para usar srcset, então a imagem apropriada para o container é usada automaticamente. Os tamanhos disponíveis podem ser definidos usando um novo featured_image_sizes setting.
Também corrigi o hide featured tag setting (não estava funcionando, então as tags estavam sempre ocultas) e atualizei para o tipo de configuração de tags em vez da entrada de texto simples. Isso também significa que múltiplas tags podem ser usadas, se desejado.
1 curtida
Legal, obrigado! Acho que isso também resolve o problema com a tag “em destaque” que estava realmente confuso.
Só uma coisa: desde a atualização, isso disparou MUITAS tarefas de processamento de imagens - tenho mais de 20 mil na fila agora. Isso é esperado? Parece meio desperdício, já que eu só preciso realmente dos últimos 5…
1 curtida
Hmm, sim, bom ponto. Infelizmente, não há como evitar isso. Acho que provavelmente vale a pena reverter essa parte por causa disso. Estou fazendo isso aqui:
A realidade é que não consigo gerar um subconjunto direcionado de imagens de miniatura otimizadas a partir de um tema dessa forma; tem que ser tudo ou nada. Portanto, precisaremos de algum outro método de otimização para casos mais limitados como este.
1 curtida
Entendido. As miniaturas desnecessárias serão removidas automaticamente mais tarde?
E parece que meu tema já tem vários formatos de imagem diferentes que podem funcionar bem - como o 400x400 ou 500x500. Que tal torná-los selecionáveis? Em comparação com o 1024x1024 atualmente usado, isso já proporcionaria uma boa economia de largura de banda, sem overhead adicional de processamento/armazenamento.
(ignorar os 300x300, 600x600 e 900x900 que foram adicionados pela atualização do 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 curtida
Acho que não, porque as imagens originais ainda estão em uso e essas são versões otimizadas. Não causa nenhum dano real, além de ocupar um pouco de espaço de armazenamento.
Você pode limpá-las pelo console do Rails. Isso cobre os tamanhos incluídos por padrão para a configuração e não removerá imagens geradas por um modificador em outro lugar.
# 1. Veja o que realmente existe versus o que ainda está registrado legitimamente
still_needed = Topic.thumbnail_sizes +
ThemeModifierHelper.new(theme_ids: Theme.pluck(:id)).topic_thumbnail_sizes
TopicThumbnail.group(:max_width, :max_height).count
# 2. Remova os tamanhos indesejados (arquivos + registros)
[[300, 300], [600, 600], [900, 900]].each do |w, h|
next if still_needed.include?([w, h]) # não toque nos tamanhos que outra coisa ainda usa
TopicThumbnail
.where(max_width: w, max_height: h)
.find_each { |tt| tt.optimized_image&.destroy! }
# registros de tentativa sem imagem otimizada não fazem cascata
TopicThumbnail.where(max_width: w, max_height: h).delete_all
end
Ah, sim, boa ideia — posso verificar quais miniaturas já existem e, se houver alguma, usar o melhor tamanho. Se apenas os originais estiverem disponíveis, isso sempre funcionará como fallback.
Fazendo isso aqui:
2 curtidas
Brilhante, vou testar isso esta noite!
E eu estava apenas voltando aqui para relistar um antigo pedido meu: seria possível adicionar uma opção para classificar a linha de destaques pela data de marcação? A nossa ordem de destaque não é determinada pela data de criação de um tópico OU pela última atividade - para nós, é o momento em que aplicamos a marcação que deve determinar a ordem. Eu não tinha percebido antes, mas nossa linha de destaques está um pouco bagunçada agora 
1 curtida
Infelizmente, acho que isso não é possível… não temos uma maneira de ordenar a lista de tópicos pela data em que uma tag foi adicionada. Uma forma de contornar isso seria editar o carimbo de data/hora do tópico?
1 curtida
Sem problemas. Estou contornando isso agora com um pouco de fita adesiva: fiz um fork do seu TC e criei uma consulta no Data Explorer para buscar os tópicos em destaque, ordenados pela data de marcação e incluindo as URLs das imagens. Um pequeno script web externo carrega e faz cache desses dados e retorna o JSON para o TC. Funciona como um charme, mesmo que seja um pouco feio
Fico feliz em compartilhar meu código e consulta se alguém precisar.
2 curtidas
Atualização: Ok, percebi que isso era apenas metade do meu problema. Também usamos o Componente de Destaque da Página Inicial (Homepage Feature TC) para exibir uma galeria das obras em destaque. E a ordem de classificação da galeria já não correspondia à da nossa linha de destaques, o que confundia os visitantes (e me irritava). Então, a galeria também precisava ser classificada pela data de marcação — não apenas pela data de criação do tópico ou pela última atividade.
Foi aí que eu resolvi ser um pouco malandro e recorri ao Claude Code para me ajudar. Primeiro, pedi para ele criar um pequeno plugin para adicionar a opção de classificar listas de tags pela data de marcação, como /tag/featured?order=tag_date.
Depois que isso funcionou, estendi a opção de classificação no Componente de Destaque da Página Inicial adicionando tag_date. Também mudei o widget de caixas de seleção para uma lista suspensa:
E voilà! Agora tenho uma linha de destaques que funciona do jeito que quero (e, francamente, do jeito que acho que deveria ), E uma galeria que corresponde:
Se alguém quiser experimentar, aqui está meu código:
- Plugin discourse-sort-by-tagging-date
- Componente de Destaque da Página Inicial com suporte para a nova opção tag_date
Você pode ver em ação em https://blenderartists.org/
Aviso: tudo isso foi feito pelo Claude Code. Eu revisei o que pude, mas no final das contas não sou especialista nisso. Vou atualizar conforme necessário, já que são uma parte importante da nossa comunidade de gráficos 3D.
Aproveitem!
1 curtida