In alto: come Discourse genera una cosiddetta “mini card” poco coinvolgente.
In basso: la corretta “Twitter card” grande.
Soluzione:
Modifica…
<meta name="twitter:card" content="summary" />
in
<meta name="twitter:card" content="summary_large_image">
nel core.
Riferimento:
Ciao @Terrapop
Non credo che questa sia una soluzione. A volte le immagini sono di scarsa qualità. E le immagini di scarsa qualità con summary_large_image sono davvero problematiche.
Forse sarebbe utile un’opzione che permetta all’utente di cambiare summary in summary_large_image.
Nel mio caso, opterei per questa soluzione, dato che ci assicuriamo che le immagini aggiunte ai topic su cui twittiamo dal nostro account abbiano dimensioni sufficientemente grandi. Per quanto ne so, Twitter passa automaticamente alla versione piccola se non si fornisce un’immagine abbastanza grande, anche quando viene specificato summary_large_image.
Sarebbe ancora meglio se le dimensioni delle immagini fossero verificate dal core e, in base alle dimensioni minime richieste, venisse utilizzato automaticamente summary o summary_large_image (minimo 300x157).
Se ciò non fosse assolutamente possibile, sarei certamente felice di avere almeno la possibilità di utilizzare summary_large_image invece di summary.
C’è qualche modo per sovrascrivere il comportamento di def crawlable_meta_data con un semplice plugin?
In particolare, vorremmo modificare:
elsif opts[:image].present?
result << tag(:meta, name: 'twitter:card', content: "summary")
result << tag(:meta, name: "twitter:image", content: opts[:image])
in
elsif opts[:image].present?
result << tag(:meta, name: 'twitter:card', content: "summary_large_image")
result << tag(:meta, name: "twitter:image", content: opts[:image])
poiché dipendiamo molto da Twitter e dalle card grandi per l’engagement.
Sono abbastanza nuovo a Ruby, quindi qualsiasi spunto nella direzione giusta sarebbe apprezzato.
Aggiornamento: Ecco il plugin.rb per chi vuole patchare il core a causa delle immagini piccole su 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
# Con larghezza e altezza disponibili?
# Usa lo schema corretto per le immagini 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?
# Aggiungi tag 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
Ma sarebbe meglio se in futuro fosse disponibile un’opzione per questo e se il core valutasse le dimensioni minime delle immagini di Twitter per scegliere tra summary_large_image o summary (per immagini molto piccole) se un amministratore attiva una nuova impostazione: “abilita immagini di riepilogo grandi per Twitter”.
Vorrei sapere se è possibile modificare il comportamento attuale che mostra sempre summary_large_image in summary — ho trovato questo post, ma sembra che richieda l’opposto — quindi immagino che qualcuno lo abbia già implementato… tuttavia è possibile fare l’inverso? Esiste un’opzione? Ho cercato nelle impostazioni di amministrazione ma non riesco a trovarla.
Per chiunque altro volesse questo (per usare sempre summary_large_image) - Ho preso il codice di @Terrapop e l’ho trasformato in un plugin che puoi includere:
- https://github.com/CubeCoders/discourse-twitter-large-card
Quello che mi piacerebbe davvero fare è qualcosa di simile alla card di Github che vedrai allegata a questo post, un modo per generare automaticamente card dinamiche per un dato argomento. Al momento la card sarà la prima immagine di dimensioni adeguate nel post. Quindi, se crei un post che inizia con un’immagine, finirà per usarla.