ヒースロー閉鎖: ロンドンの空港管理者が今後数日間、フライトの運航停止が続くと述べています
「いいね！」 1
このDiscourseインスタンスでそのリンクがどのように表示されるか見てみましょう。
それを貼り付けたとき、プレビューのワンボックスには正しいアスペクト比の画像が一時的に表示されました。1、2秒後にそれは潰れてしまいました。
したがって、何が起こっているのかは、私たちのDiscourseインスタンスに限定されるものではありません。OGタグで画像の寸法を指定する必要があるかもしれませんが、それは必須だとは考えていませんでした。
「いいね！」 2
それで…何か進展はありましたか？まだ発生しています。何か回避策があれば教えてください。もしこちらが何か間違ったことをしているのであれば、それも教えてください。
「いいね！」 1
状況報告：これはまだ起こります。新しいトピックにリンクを貼り付けると、最初は関連する画像がプレビューで問題なく表示されます。しかし、Enterキーまたはスペースバーを押すとすぐに、画像が潰れてしまいます。onebox のトラブルシューティングの手順を再度確認し、すべてのオーバーライドされた設定を再度確認しましたが、効果はありませんでした。これはどうかしています。
「いいね！」 1
そのCSSは最適とは言えず、何らかの妥協策である可能性があります。外出先ですが、現在は16:9が強制されているのかもしれません。正方形のロゴにはあまり適していません:slight_smile:
高さは自動に設定できるでしょうか？（ただし、縦長の画像には問題が生じる可能性があります）
どのCSSについて言及していますか？あなたの言うことは正しいかもしれませんが、Discourseインスタンスで修正できるものなのか、それともDiscourseソース内のものなのかを判断しようとしています。
デスクに戻って：
これはおそらくコード化されたスタイルなので、それがどのように設定されているかを知るにはコードを調べる必要があります。
600 / 600 の場合、ロゴは正方形になります…
こちらです：
「いいね！」 1
面白い。画像が正方形の場合にそれを前提とするコードがいくつかありますね。正方形でない画像も試してみようかな。
他の条件は同じで、正方形ではない画像を使用しましたが、アスペクト比の問題はありませんでした。引き続き実験します。
そうでしょうね。
元の寸法とアスペクト比を使用します。
これは、クッキングプロセス中に削除されます。
「いいね！」 1
oembed からディメンションを取得しています。
https://hookproductivity.com/wp-json/oembed/1.0/embed?url=https%3A%2F%2Fhookproductivity.com%2Fhelp%2Fintegration%2Fother-app-developers%2F
これには以下が含まれます。
このバグは、type が “rich” で、oembed の html ペイロードからプレゼンテーション全体を取得していない場合に、ディメンションを追加しないようにする必要があると思います。なぜなら、このデータには興味がないからです。
これで修正されます。
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
しかし、他にどのような副作用があるかはわかりません。メンバーエクスペリエンスチームにフラグを立て、来月中に確認してもらう予定です。
多くのレイヤーと複雑さが存在するため、パッチを単純に追加することにはためらっています。誰かが、非常に安全でテストされた方法でパッチを追加できることを保証する必要があります。
wp-json がこれを表面化するため、このバグの影響はかなり広範囲に及ぶため、これは pri-medium です。
「いいね！」 1
素晴らしい！そのoembedデータは決定的な証拠のようですね。興味深いことに、WordPress（ソフトウェア）のドキュメントでは、WordPressサイトが他のサイトからコンテンツを埋め込むことに関してのみoembedについて言及しており、その逆については触れていません。しかし、wordpress.com（サービス）のドキュメントには、「WordPress.comでホストされているすべての投稿、ページ、添付ファイル、およびVideoPressビデオは、公開oEmbed APIを通じてoEmbed形式をサポートしています」と書かれています。したがって、WordPressソフトウェアがデフォルトでこれを行っていると仮定しても安全でしょう。
WordPressの設定をすべて確認しましたが、oembedに関連するものは見つかりませんでした。そのため、WordPressが行う仮定はコードに組み込まれているようです。
WordPressのoembed APIは、以前は不可解に思えた600/338の寸法がページソースのどこにも参照されていない理由も説明しています。
Discourseで可能な修正は、多くの（おそらく望ましくない）連鎖効果をもたらす可能性があり、リリース前にテストする必要があることに同意します。
また、これがDiscourseの問題であるかどうかも定かではありません。不正な「338」の寸法はWordPressから来ています。私には、WordPressにはこのようなoembed関連のデフォルトをオーバーライドする方法があるはずです。oembedの制御を強化するWordPressプラグインを探す予定です。
ありがとうございます！
他方で、これらのリンクはiFramelyや他の場所では問題なく表示されるため、これは実際にDiscourse側で変更すべき点かもしれません。