Entrambi i siti hanno sicuramente tag OG validi. Le origini delle immagini sono quadrate. Non stiamo specificando le dimensioni dell’immagine nei tag OG.
L’esempio sopra funziona bene nel debugger di condivisione di Facebook e iFramely. Fai clic sul link qui sotto per vederlo su iFramely.
Ho esaminato tutte le impostazioni di onebox e immagine, ma non vedo nulla che sembri pertinente.
Ho esaminato le guide alla risoluzione dei problemi e alla configurazione di onebox qui, ma nulla ha aiutato.
Suppongo che debba essere qualcosa nelle nostre impostazioni di Discourse, o in Discourse stesso.
Vediamo come appare quel link su questa istanza di Discourse:
Quando l’ho incollato, il onebox nell’anteprima ha mostrato brevemente l’immagine con le proporzioni corrette. Un secondo o due dopo si è schiacciata.
Quindi, qualunque cosa stia succedendo non è limitata alla nostra istanza di Discourse. Immagino che potremmo dover specificare le dimensioni dell’immagine nei tag OG, ma non pensavo fosse richiesto.
Quindi… ci sono progressi? Sta ancora succedendo. Se c’è una qualche soluzione alternativa, fammelo sapere. Se stiamo facendo qualcosa di sbagliato, fammelo sapere.
Rapporto sullo stato: questo succede ancora. Quando incollo un link in un nuovo argomento, inizialmente l’immagine associata appare corretta nell’anteprima. Ma non appena premo Invio o la barra spaziatrice, l’immagine viene schiacciata. Ho ricontrollato i passaggi per la risoluzione dei problemi di onebox e ho rivisto ancora una volta tutte le impostazioni sovrascritte, senza successo. È pazzesco.
Quel CSS potrebbe essere considerato subottimale o un qualche tipo di compromesso. Sono di fretta ma forse sta attualmente imponendo il formato 16:9. Non ideale per loghi quadrati
Mi chiedo se l’altezza potrebbe essere impostata su automatico? (Anche se ciò potrebbe presentare sfide per le immagini in formato verticale)
A quale CSS ti riferisci? Cioè, potresti avere ragione, ma sto cercando di determinare se è qualcosa che posso correggere sulla nostra istanza Discourse, o se è qualcosa nel codice sorgente di Discourse.
Penso che il bug qui sia che se il tipo è “rich” e non stiamo recuperando l’intera presentazione dal payload html di oembed, dovremmo saltare l’aggiunta delle dimensioni, poiché non siamo interessati a questi dati.
Questo lo corregge:
diff --git a/lib/onebox/engine/standard_embed.rb b/lib/onebox/engine/standard_embed.rb
index e3175d6247..fc8c300d81 100644
--- a/lib/onebox/engine/standard_embed.rb
+++ b/lib/onebox/engine/standard_embed.rb
@@ -159,8 +159,9 @@ module Onebox
@json_ld ||= Onebox::JsonLd.new(html_doc)
end
- def set_from_normalizer_data(normalizer)
+ def set_from_normalizer_data(normalizer, skip_dimensions: false)
normalizer.data.each do |k, _|
+ next if skip_dimensions && k.in?(%i[width height])
v = normalizer.public_send(k)
@raw[k] ||= v unless v.nil?
end
@@ -179,7 +180,8 @@ module Onebox
def set_oembed_data_on_raw
oembed = get_oembed
- set_from_normalizer_data(oembed)
+ skip_dimensions = oembed.data[:type] == "rich"
+ set_from_normalizer_data(oembed, skip_dimensions:)
end
def set_json_ld_data_on_raw
Tuttavia, non sono sicuro di quali altri effetti collaterali potrebbe avere, segnalo al team member-experience che darà un’occhiata a questo nel corso del prossimo mese.
Sono riluttante ad aggiungere semplicemente la mia patch perché ci sono molti livelli qui e complessità, qualcuno deve assicurarsi che siamo in grado di aggiungere la patch in modo molto sicuro e testato.
Questo è pri-medium perché l’impatto di questo bug è piuttosto ampio dato che wp-json lo espone.
Bello! Que dados oembed parecem ser a pista definitiva. Curiosamente, a documentação do Wordpress (software) fala sobre oembed apenas em termos de sites Wordpress incorporando conteúdo de outros sites, não o contrário. No entanto, a documentação do wordpress.com (serviço) diz “Cada post, página, anexo e vídeo VideoPress hospedado no WordPress.com suporta o formato oEmbed através da nossa API pública oEmbed.” Portanto, é seguro assumir que o software Wordpress faz isso por padrão.
Revisei todas as configurações do Wordpress e não consegui encontrar nada relacionado a oembed, então parece que quaisquer suposições feitas pelo Wordpress estão embutidas no código.
A API oembed do Wordpress também explica por que não há referência às dimensões 600/338 em nenhum lugar no código-fonte da página, o que eu anteriormente achava desconcertante.
Concordo que qualquer correção possível para isso no Discourse pode ter muitos efeitos colaterais (possivelmente indesejados) e precisa ser testada antes de ser lançada.
Além disso, nem tenho certeza se este é um problema do Discourse. A dimensão incorreta ‘338’ vem do Wordpress. Parece-me que deve haver uma maneira no Wordpress de substituir padrões relacionados a oembed como este. Planejo procurar um plugin do Wordpress que permita mais controle sobre oembed.
D’altra parte, dato che questi link appaiono corretti in iFramely e altrove, forse questa è effettivamente una cosa che dovrebbe essere modificata in Discourse.
