我尝试过使用来自几个不同 WordPress 站点的页面链接，效果都一样：
这两个站点肯定都有有效的 OG 标签。图片来源是正方形的。我们在 OG 标签中没有指定图片尺寸。
上面的示例在 Facebook 共享调试器和 iFramely 中都能正常工作。单击下面的链接在 iFramely 上查看它。
我查看了所有 onebox 和图片设置，但没有发现任何相关内容。
我已阅读了此处的 onebox 故障排除和配置指南，但均无帮助。
我认为这一定是我们的 Discourse 设置或 Discourse 本身的问题。
让我们看看这个链接在此 Discourse 实例上的显示效果：
当我粘贴进去时，预览中的 onebox 曾短暂地显示了具有正确纵横比的图片。一两秒钟后，它被压扁了。
所以，无论发生什么，都不只是我们这个 Discourse 实例的问题。我想我们可能需要在 OG 标签中指定图片尺寸，但我不认为这是必需的。
那么……有进展吗？这种情况仍然存在。如果有什么变通方法，请告诉我。如果我们有什么地方做错了，也请告诉我。
状态报告：这种情况仍然存在。当我将链接粘贴到新主题中时，关联的图像最初在预览中看起来还可以。但只要我按 Enter 或空格键，图像就会被压缩。我再次检查了 onebox 的故障排除步骤，并再次查看了所有覆盖的设置，但都没有成功。这太疯狂了。
该 CSS 可能被认为不够理想，或者是一种折衷方案。我目前正在处理，但也许它目前强制设置为 16:9。这对方形徽标来说不太好 
我想知道高度是否可以设置为自动？（尽管这可能给纵向图片带来挑战）
您指的是哪个 CSS？我的意思是，您可能是对的，但我正在尝试确定这是否是我们可以在 Discourse 实例上修复的问题，还是 Discourse 源代码中的问题。
回到桌子：
这可能是一种编码样式，因此您需要深入研究代码才能找出其设置方式。
当 600 / 600 时，您的徽标是方形……
给你：
有意思。里面有些代码会假设图像是正方形的。也许我会尝试一个非正方形的图像。
在其他条件都相同的情况下使用非方形图像：没有纵横比问题。我会继续试验。
会：
使用原始尺寸和比例。
这会在处理过程中被剥离。
尺寸来自 oembed：
https://hookproductivity.com/wp-json/oembed/1.0/embed?url=https%3A%2F%2Fhookproductivity.com%2Fhelp%2Fintegration%2Fother-app-developers%2F
其中包含：
我认为这里的 bug 是，如果 type 是“rich”，并且我们没有从 oembed html payload 中获取完整的演示文稿，那么我们应该跳过添加尺寸，因为我们不关心这些数据。
这可以修复：
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
但我不知道这会有什么其他副作用，我将把这个问题标记给 member-experience 团队，他们将在下个月进行审查。
我不太愿意直接添加我的补丁，因为这里有很多层和复杂性，需要有人确保我们能够以非常安全和经过测试的方式添加补丁。
这是 pri-medium 级别的问题，因为鉴于 wp-json 会暴露此问题，此 bug 的影响相当广泛。
太棒了！那个 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 中应该更改的内容。