Oben: Wie Discourse eine nicht besonders ansprechende sogenannte „Mini-Karte
3 „Gefällt mir“
Hallo @Terrapop
Ich glaube nicht, dass das eine Lösung ist. Manchmal sind Bilder einfach schlecht. Und schlechte Bilder mit summary_large_image sind wirklich problematisch.
Vielleicht wäre es eine Option, wenn der Nutzer summary in summary_large_image ändern könnte.
3 „Gefällt mir“
In meinem Fall würde ich mich dafür entscheiden, da wir sicherstellen, dass Bilder, die zu den Themen hinzugefügt werden, über die wir auf unserem Konto tweeten, groß genug sind. Meines Wissens weicht Twitter automatisch auf die kleine Version zurück, wenn Sie kein ausreichend großes Bild bereitstellen, selbst wenn summary_large_image angegeben ist.
Noch besser wäre es, wenn die Bildgrößen vom Kern überprüft würden und je nach den erforderlichen Mindestgrößen automatisch summary oder summary_large_image (min. 300x157) verwendet würde.
Wenn das überhaupt nicht möglich ist, wäre ich jedenfalls gerne bereit, zumindest die Option zu haben, summary_large_image anstelle von summary zu verwenden.
2 „Gefällt mir“
Gibt es eine Möglichkeit, das Verhalten von def crawlable_meta_data mit einem einfachen Plugin zu überschreiben?
Insbesondere möchten wir Folgendes ändern:
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])
Da wir für die Engagement-Rate stark auf Twitter und große Karten angewiesen sind.
Ich bin noch recht neu in Ruby, daher wäre jeder Hinweis in die richtige Richtung willkommen.
Update: Hier ist die plugin.rb für diejenigen, die den Core patchen möchten, um die kleinen Bilder auf Twitter zu beheben:
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
# Sind Breite und Höhe verfügbar?
# Verwende das korrekte Schema für OpenGraph-/Twitter-Bilder
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?
# OpenGraph- & Twitter-Tags hinzufügen
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
Es wäre jedoch besser, wenn es zukünftig eine Option dafür gäbe und der Core die Mindestgrößen für Twitter-Bilder prüft, um entweder summary_large_image oder summary (für sehr kleine Bilder) zu verwenden, falls ein Administrator eine neue Einstellung aktiviert: „Große Twitter-Summary-Bilder aktivieren".
6 „Gefällt mir“
Ich würde gerne wissen, ob es möglich ist, das aktuelle Verhalten, bei dem immer summary_large_image angezeigt wird, auf summary zu ändern. Ich bin auf diesen Beitrag gestoßen, aber es scheint, als würde dort das Gegenteil gefordert. Ich gehe also davon aus, dass jemand dies bereits umgesetzt hat. Ist es jedoch möglich, das Verhalten umzukehren? Gibt es eine entsprechende Option? Ich habe versucht, in den Admin-Einstellungen danach zu suchen, konnte aber nichts finden.
1 „Gefällt mir“
Für alle anderen, die dies wünschen (um immer summary_large_image zu verwenden) – ich habe den Code von @Terrapop genommen und ihn in ein Plugin umgewandelt, das Sie einbinden können:
- https://github.com/CubeCoders/discourse-twitter-large-card
Was ich wirklich gerne tun würde, ist etwas Ähnliches wie die Github-Karte, die Sie im Anhang dieses Beitrags sehen, eine Möglichkeit, dynamische Karten für ein bestimmtes Thema automatisch zu generieren. Im Moment wird die Karte das erste brauchbare Bild im Beitrag sein. Wenn Sie also einen Beitrag erstellen, der mit einem Bild beginnt, wird dieser verwendet.
1 „Gefällt mir“