No topo: Como o Discourse gera um chamado “mini card” pouco envolvente.
Na parte inferior: Card do Twitter correto e grande.
Solução:
Por favor, altere…
<meta name="twitter:card" content="summary" />
para
<meta name="twitter:card" content="summary_large_image">
no núcleo.
Referência:
Olá @Terrapop
Acho que isso não é uma solução. Às vezes, as imagens são ruins. E imagens ruins com summary_large_image são realmente ruins.
Talvez seja possível adicionar uma opção para que o usuário possa alterar summary para summary_large_image.
No meu caso, eu optaria por isso, pois garantimos que as imagens adicionadas aos tópicos que tweetamos em nossa conta tenham tamanho suficiente. Pelo que sei, o Twitter automaticamente recorre à versão pequena se você não fornecer uma imagem grande o suficiente, mesmo quando summary_large_image é fornecido.
Ainda melhor seria se os tamanhos das imagens fossem validados pelo núcleo e, dependendo dos tamanhos mínimos necessários, usasse summary ou summary_large_image (mínimo 300x157) automaticamente.
Se isso não for possível de forma alguma, eu certamente ficaria feliz em ter pelo menos a opção de usar summary_large_image em vez de summary.
Existe alguma maneira de sobrescrever o comportamento de def crawlable_meta_data com um plugin simples?
Em particular, gostaríamos de alterar:
elsif opts[:image].present?
result << tag(:meta, name: 'twitter:card', content: "summary")
result << tag(:meta, name: "twitter:image", content: opts[:image])
para
elsif opts[:image].present?
result << tag(:meta, name: 'twitter:card', content: "summary_large_image")
result << tag(:meta, name: "twitter:image", content: opts[:image])
pois dependemos bastante do Twitter e dos cards grandes para engajamento.
Sou bastante novo em Ruby, então qualquer orientação na direção certa seria muito apreciada.
Atualização: Aqui está o plugin.rb para quem deseja corrigir o núcleo devido às imagens pequenas no Twitter:
after_initialize do
reloadable_patch do |plugin|
ApplicationHelper.module_eval do
def crawlable_meta_data(opts = nil)
opts ||= {}
opts[:url] ||= "#{Discourse.base_url_no_prefix}#{request.fullpath}"
if opts[:image].blank?
twitter_summary_large_image_url = SiteSetting.site_twitter_summary_large_image_url
if twitter_summary_large_image_url.present?
opts[:twitter_summary_large_image] = twitter_summary_large_image_url
end
opts[:image] = SiteSetting.site_opengraph_image_url
end
# Com largura e altura disponíveis?
# Usar o esquema correto para a imagem opengraph/twitter
opts[:image] = get_absolute_image_url(opts[:image]) if opts[:image].present?
opts[:twitter_summary_large_image] =
get_absolute_image_url(opts[:twitter_summary_large_image]) if opts[:twitter_summary_large_image].present?
# Adicionar tags opengraph e twitter
result = []
result << tag(:meta, property: 'og:site_name', content: SiteSetting.title)
if opts[:twitter_summary_large_image].present?
result << tag(:meta, name: 'twitter:card', content: "summary_large_image")
result << tag(:meta, name: "twitter:image", content: opts[:twitter_summary_large_image])
elsif opts[:image].present?
result << tag(:meta, name: 'twitter:card', content: "summary_large_image")
result << tag(:meta, name: "twitter:image", content: opts[:image])
else
result << tag(:meta, name: 'twitter:card', content: "summary")
end
result << tag(:meta, property: "og:image", content: opts[:image]) if opts[:image].present?
[:url, :title, :description].each do |property|
if opts[property].present?
content = (property == :url ? opts[property] : gsub_emoji_to_unicode(opts[property]))
result << tag(:meta, { property: "og:#{property}", content: content }, nil, true)
result << tag(:meta, { name: "twitter:#{property}", content: content }, nil, true)
end
end
if opts[:read_time] && opts[:read_time] > 0 && opts[:like_count] && opts[:like_count] > 0
result << tag(:meta, name: 'twitter:label1', value: I18n.t("reading_time"))
result << tag(:meta, name: 'twitter:data1', value: "#{opts[:read_time]} mins 🕑")
result << tag(:meta, name: 'twitter:label2', value: I18n.t("likes"))
result << tag(:meta, name: 'twitter:data2', value: "#{opts[:like_count]} ❤")
end
if opts[:published_time]
result << tag(:meta, property: 'article:published_time', content: opts[:published_time])
end
if opts[:ignore_canonical]
result << tag(:meta, property: 'og:ignore_canonical', content: true)
end
result.join("\n")
end
end
end
end
Mas seria melhor se houvesse uma opção para isso no futuro e se o núcleo avaliasse os tamanhos mínimos de imagens do Twitter para usar summary_large_image ou summary (para imagens muito pequenas) caso um administrador opte por uma nova configuração: “habilitar imagens grandes de resumo do Twitter”.
Gostaria de saber se é possível alterar o comportamento atual de sempre exibir summary_large_image para summary — encontrei este post, mas parece que ele está pedindo o inverso — então imagino que alguém deve ter implementado isso… no entanto, é possível fazer o inverso? Existe alguma opção? Tentei procurar nas configurações de administrador e não encontrei.
Para qualquer outra pessoa que queira isso (para sempre usar summary_large_image) - Eu peguei o código do @Terrapop e o transformei em um plugin que você pode incluir:
- https://github.com/CubeCoders/discourse-twitter-large-card
O que eu realmente gostaria de fazer é algo semelhante ao cartão do Github que você verá anexado a esta postagem, uma maneira de gerar automaticamente cartões dinâmicos para um determinado tópico. No momento, o cartão será a primeira imagem de tamanho razoável na postagem. Portanto, se você criar uma postagem que comece com uma imagem, ela acabará usando essa.