Ah, isso é um bug, com certeza. Precisaremos investigar isso, bom trabalho em encontrar!
4 curtidas
Excelente, obrigado pelo PR, mesclado!
4 curtidas
Três desafios:
- Tenho quase certeza de que as miniaturas não são serializadas aqui. Sinta-se à vontade para confirmar. Isso poderia ser superado aprimorando o plugin sidecar.
- Quando olhei isso pela última vez, a estrutura da página não permitia substituições de baixo risco isoladas em um template de folha. Geralmente, não queremos substituir a página inteira, o que pode causar alterações disruptivas ou mascarar atualizações de recursos do core. Um PR para o core pode ajudar aqui…
- Espaço?
Sinta-se à vontade para enviar os PRs necessários.
1 curtida
Pontos válidos. Talvez eu escolha outra apresentação para as páginas de categoria, talvez em blocos ou algo assim.
Tenho outra pergunta.
É possível ter páginas de categoria (que contêm listas de tópicos) exibidas em blocos no celular, mas com miniaturas na área de trabalho? Tentei vários ajustes de configuração, mas não consegui alcançar isso.
editar: Consegui. Detalharei como fiz um pouco mais tarde, caso possa interessar a alguém, adicionei esta edição apenas para que ninguém perca tempo me explicando como fazer: wink:
Então, se não me engano, aqui estão as configurações…
Primeiro, precisamos que a exibição em blocos seja apenas na visualização móvel de (pelo menos?) uma lista de tópicos:
Em seguida, as miniaturas para desktop E celular:
Eu me enganei no início porque pensei que “blocos” e “miniaturas” eram duas apresentações diferentes de uma lista de tópicos, ambas contendo as imagens. mas não é o caso. Miniaturas são necessárias se você quiser que as imagens apareçam em uma lista de tópicos, seja ela em bloco ou não.
Não há necessidade de adicionar suas categorias manualmente aqui:
Já que substituiremos essa configuração ativando a seguinte:
Agora, você deve ter pequenas miniaturas no desktop em qualquer lista de tópicos (mais recentes, uma categoria específica, etc.), e uma apresentação em “blocos” no celular com miniaturas grandes:
2 curtidas
Tenho um pequeno problema com o meu perfil de usuário, acho que é um pequeno bug:
Como menciona a miniatura, suponho que esteja relacionado a este componente de tema.
Ainda brincando com este componente de tema, aliás… E é incrível. 
Tenho uma pergunta. É possível impedir que um tópico tenha uma miniatura, embora o tópico realmente contenha algumas?
Aqui está o meu caso:
Tenho uma categoria de documentação para a qual miniaturas são bem-vindas.
Mas também tenho um tópico que apenas dá conselhos gerais ao criar um novo tópico:
Não há imagem significativa nele, mas ele adiciona uma miniatura automaticamente:
A única maneira que vejo para contornar o problema é adicionar uma imagem aleatória em algum ponto do tópico e defini-la como miniatura.
Exemplo:
(mas admito que fica bonito, embora…)
1 curtida
Sim, essa localização está falhando e precisa ser corrigida. 
Não, se houver uma imagem, ele tentará usá-la. Adicionar uma adicional e agradável é a solução perfeita
Isso ficará melhor para a consistência do layout da sua página também.
De qualquer forma, costumo usar um Componente de Tópicos em Destaque (o TLP integrado ou outro) para resumir esse tipo de postagem no topo, então ter uma imagem é muito bom.
1 curtida
Estou tentando restringir a miniatura e os blocos a uma tag específica, além de certas categorias, mas não está funcionando para tags. Aqui está a minha página de configurações, eu só quero blocos e miniaturas para a tag em destaque. Você pode me dizer se estou fazendo algo errado.
Há também uma string ausente nas configurações do plugin:
E outro bug com a opção o trecho da lista de tópicos remove links.
Portanto, como já foi relatado, se eu desativá-la, não haverá mais nenhum link, nem mesmo o texto deles, assim como o botão “leia mais”:
Se eu ativá-la, os links nos trechos aparecem, assim como o link “leia mais”, mas por algum motivo:
-
O link “leia mais” não é estilizado como um link (também já foi relatado, mas como tudo está relacionado à mesma opção, prefiro agrupar todos os problemas de uma vez)
-
Alguns trechos estão incorretamente formatados. Alguns exemplos:
Apenas a primeira parte da frase do trecho está formatada aqui:
Uma linha vazia é formatada como um trecho:
Ficarei feliz em ajudar mais, mas infelizmente não sei nada sobre plugins e a maior parte do código do Discourse… 
1 curtida
isso parece um bug, darei uma olhada em breve.
3 curtidas
Corrigi isso no branch beta. Você poderia confirmar se tudo parece estar bom agora, então eu farei o merge.
Para que isso funcione, você tem que remover tag e tag-mobile e adicionar a tag específica à configuração da lista de tags.
(Instale a versão beta como outro componente e associe-a a um tema de teste).
Aconteceu que foi uma alteração disruptiva no core.
Use o botão avançado para revelar o branch e digite beta:
Se eu não ouvir de você em um tempo, eu farei o merge de qualquer maneira, mas esta é sua chance de testar e trazer isso adiante.
1 curtida
Isso só é ganho fazendo 
, um pouco de cada vez e juntando pedaços de conhecimento ao longo do caminho 
3 curtidas
Também há um erro de JS ao navegar no site se o componente de tema estiver instalado.
Também é visível no seu próprio site: https://starzen.space/
Clique em qualquer postagem e olhe o console de JS.
TypeError: Cannot read properties of null (reading 'querySelector')
O erro é acionado nesta linha do arquivo Discourse:
1 curtida
Parece uma alteração incompatível no core: FIX: Don't listen for focus/blur events if the topic-list opts out of… · discourse/discourse@97e7bb1 · GitHub
Principalmente corrigido com: COMPATIBILITY: add css class to tiles to support focus · merefield/discourse-tc-topic-list-previews@4f0f0f0 · GitHub
Correção no branch beta como demonstrado no meu site.
A vantagem de corrigir isso dessa forma é que agora temos o indicador de último visitado no bloco
(A maioria dos erros desaparece no mobile também, mas este indicador normalmente não é visível no mobile em qualquer caso, então vou chamar isso de corrigido!)
Precisarei acompanhar o erro menos frequente relacionado ao elemento de título.
1 curtida
Isso foi corrigido na beta: FIX: missing localisation on user prefs and update locale paths
1 curtida
Obrigado!
Em relação à opção do plugin topic list excerpt remove links, posso sugerir a alteração da regex que você usa atualmente?
URI::regexp removerá qualquer string que tenha um padrão de link, o que não é, na minha opinião, sempre desejável.
Links às vezes têm o mesmo conteúdo de texto que seu valor href. Esse é até um caso muito comum em qualquer fórum, e remover o conteúdo do texto pode levar a trechos bizarros com frases que não fazem sentido.
Essa regex também removerá palavras que estão dentro ou fora de links às vezes. Dou exemplos abaixo.
Aqui está uma comparação com outra regex: \u003ca .+?\\\u003e(.+)?\u003c\\/a\u003e
Esta é apenas uma regex de exemplo; entendo que URI::regexp cobre links de uma maneira mais complexa (e supostamente mais confiável).
Aqui está um post de exemplo:
E os trechos resultantes na lista de tópicos:
URI::regexp
\u003cbig\u003e↓\u003c/big\u003e
(o conteúdo do texto do link do facebook foi removido, e também removeu a palavra “Day” em “Astronomy Picture of the Day” por um motivo desconhecido
)
\u003ca .+?\\\u003e(.+)?\u003c\\/a\u003e
\u003cbig\u003e↓\u003c/big\u003e
Outro exemplo, apenas sobre o conteúdo de texto de um link removido que torna o trecho estranho de ler:
URI::regexp
\u003cbig\u003e↓\u003c/big\u003e
(“o link era This may be my favorite halo”…?)
\u003ca .+?\\\u003e(.+)?\u003c\\/a\u003e
\u003cbig\u003e↓\u003c/big\u003e
(agora isso faz sentido)
Portanto, não estou sugerindo que \u003ca .+?\\\u003e(.+)?\u003c\\/a\u003e seja melhor, foi apenas um teste rápido, mas não tenho certeza se usar URI::regexp é a melhor escolha em relação aos resultados, tanto pelas duas razões que mencionei: o conteúdo do texto do link desaparece, tornando os trechos estranhos às vezes, e também remove palavras dentro ou fora de links de tempos em tempos por um motivo obscuro. Este último problema parece ser frequente o suficiente para não ser negligenciável.
3 curtidas
Aprecio as desvantagens do método atual (incluindo o entusiasmo excessivo surpreendentemente estranho do algoritmo atual, que exclui demais), mas chegamos aqui através da experiência.
A principal razão pela qual essa opção existe é, na verdade, para:
- preservar a formatação da pré-visualização quando os links são muito longos (ou seja, excluir todos os links para que um link longo nunca vaze para o trecho e cause problemas). Tente o cenário em que um link é muito, muito longo. O antigo tópico de suporte está repleto de problemas com posts de Tópicos com links longos.
- preservar o trecho como uma superfície de clique previsível, onde sempre navegará para o Tópico. O texto é muito pequeno para que isso seja discricionário.
Também deve ser:
- simples de manter e não causar ruído de suporte. Como o método atual é uma classe utilitária suportada, não preciso me preocupar em mantê-la.
Ainda não estou convencido de que precisamos mudar isso para o público em geral?
Posso estar aberto a torná-lo uma seleção de três opções: DESLIGADO, sem links (ou seja, método atual) e experimental? PR bem-vindo. Deixarei mover o código sidecar atual para o branch principal do plugin primeiro. Tentarei fazer isso esta semana.
3 curtidas
Obrigado pela sua resposta 
Corrigi a última frase da minha postagem anterior, esqueci uma palavra…
Eu escrevi
e também remove palavras dentro ou fora de links de tempos em tempos por uma razão obscura. A última questão parece frequente o suficiente para ser negligenciável."
Eu esqueci um “não”, então…
e também remove palavras dentro ou fora de links de tempos em tempos por uma razão obscura. A última questão parece frequente o suficiente para não ser negligenciável.
Eu posso não entender muita coisa de código, mas vou tentar entender e corrigir o problema número 2 que mencionei aqui: Topic List Previews (TLP) - #110 by Canapin hoje.
(os trechos não estão devidamente envolvidos por .topic-excerpt: o wrapper parece fechar logo antes do primeiro link presente no trecho em vez do final do trecho)
Na verdade, a melhor abordagem talvez seja abrir um problema com o mantenedor dessa utilidade e pedir para que ele corrija? Certamente não está se comportando como você esperaria?
Sim, ainda não olhei para isso. Sinta-se à vontade para enviar um PR com uma correção enquanto isso.
1 curtida
Obrigado, não tinha pensado nisso, não fazia ideia de onde vinha essa utilidade.
Após pesquisar um pouco, basicamente a regex reconhece praticamente qualquer palavra ou string como parte de um esquema de URI, desde que seja imediatamente seguida por dois pontos - ou seja, sem espaço entre eles -, o que é compreensível, mas também um pouco demais, já que na língua inglesa (ao contrário da língua francesa, por exemplo), não colocamos espaço entre uma palavra e dois pontos. Daí palavras “legítimas” serem consumidas pela regex apenas porque, infelizmente, são seguidas por dois pontos.
Uma correção poderia ser ter um campo (não pré-preenchido para evitar danos em instalações existentes) nas configurações do plugin para inserir os esquemas que queremos remover.
Por exemplo, a configuração poderia ser:
Esquemas de URI para remover: http|https|ftp|mailto
Isso resultaria em:
#{URI::regexp(['http', 'https', 'ftp', 'mailto'])}
(mas é, infelizmente, sensível a maiúsculas e minúsculas, mas isso certamente pode ser ajustado de alguma forma)
Se a configuração estiver vazia, então é isso que seria usado:
#{URI::regexp}
Sendo o comportamento atual.
Um pull request com tal configuração seria bem-vindo?