Haut : Comment Discourse génère une soi-disant « mini carte » peu engageante.
Bas : Correcte, grande carte Twitter.
Solution :
Veuillez modifier…
<meta name="twitter:card" content="summary" />
en
<meta name="twitter:card" content="summary_large_image">
dans le noyau.
Référence :
Bonjour @Terrapop
Je ne pense pas que ce soit une solution. Parfois, les images sont de mauvaise qualité. Et des images de mauvaise qualité avec summary_large_image sont vraiment problématiques.
Peut-être ajouter une option permettant à l’utilisateur de passer de summary à summary_large_image.
Dans mon cas, je choisirais cette option, car nous nous assurons que les images ajoutées aux sujets que nous tweetons sur notre compte sont suffisamment grandes. À ma connaissance, Twitter revient automatiquement à la version petite si vous ne fournissez pas une image suffisamment grande, même lorsque summary_large_image est spécifié.
Ce serait encore mieux si les tailles d’image étaient vérifiées par le cœur du système et que, selon les tailles minimales requises, summary ou summary_large_image (minimum 300x157) était utilisé automatiquement.
Si cela n’est absolument pas possible, je serais certainement ravi d’avoir au moins la possibilité d’utiliser summary_large_image au lieu de summary.
Existe-t-il un moyen de remplacer le comportement de def crawlable_meta_data avec un simple plugin ?
En particulier, nous souhaitons modifier :
elsif opts[:image].present?
result << tag(:meta, name: 'twitter:card', content: "summary")
result << tag(:meta, name: "twitter:image", content: opts[:image])
en
elsif opts[:image].present?
result << tag(:meta, name: 'twitter:card', content: "summary_large_image")
result << tag(:meta, name: "twitter:image", content: opts[:image])
car nous dépendons beaucoup de Twitter et des grandes cartes pour l’engagement.
Je suis assez nouveau dans Ruby, donc toute indication dans la bonne direction serait appréciée.
Mise à jour : Voici le plugin.rb pour ceux qui souhaitent appliquer un correctif au cœur du système à cause des petites images sur 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
# Avec la largeur et la hauteur disponibles ?
# Utiliser le bon schéma pour l'image 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?
# Ajouter les balises opengraph et 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
Mais il serait préférable qu’une option soit prévue à l’avenir et que le cœur du système évalue les tailles minimales des images Twitter pour choisir entre summary_large_image ou summary (pour les très petites images) si un administrateur active un nouveau paramètre : “activer les grandes images de résumé Twitter”.
Je souhaiterais savoir s’il est possible de modifier le comportement actuel qui affiche systématiquement summary_large_image en summary — je suis tombé sur ce post, mais il semble qu’il demande l’inverse. Je suppose donc que quelqu’un a dû l’implémenter… Cependant, est-il possible de faire l’inverse ? Existe-t-il une option ? J’ai essayé de chercher dans les paramètres d’administration, mais je n’ai rien trouvé.
Pour tous ceux qui souhaitent cela (utiliser toujours summary_large_image) - J’ai pris le code de @Terrapop et en ai fait un plugin que vous pouvez inclure :
- https://github.com/CubeCoders/discourse-twitter-large-card
Ce que j’aimerais vraiment faire, c’est quelque chose de similaire à la carte Github que vous verrez attachée à ce post, un moyen de générer automatiquement des cartes dynamiques pour un sujet donné. Pour l’instant, la carte sera la première image de taille décente dans le post. Donc, si vous créez un post qui commence par une image, il finira par l’utiliser.