몇 개의 다른 WordPress 사이트에서 페이지 링크를 사용해 시도해 보았지만, 결과는 동일합니다:
두 사이트 모두 유효한 OG 태그가 definitely 존재합니다. 이미지 소스는 정사각형입니다. OG 태그에서 이미지 크기를 지정하지 않았습니다.
위 예시는 Facebook 공유 디버거와 iFramely에서 정상적으로 작동합니다. 아래 링크를 클릭하여 iFramely에서 확인해 보세요.
onebox 및 이미지 설정을 모두 검토해 보았지만, 관련이 있어 보이는 설정은 찾지 못했습니다.
여기 있는 onebox 문제 해결 및 설정 가이드를 모두 읽어 보았지만, 도움이 되지 않았습니다.
우리 Discourse 설정이나 Discourse 자체의 문제일 것 같습니다.
해당 링크가 이 Discourse 인스턴스에서 어떻게 보이는지 확인해 보겠습니다:
그 링크를 붙여넣었을 때, 미리보기의 onebox에 이미지가 올바른 비율로 잠시 표시되었습니다. 그러나 1~2초 후에 이미지가 변형되었습니다.
따라서 현재 문제가 발생하는 것이 우리 Discourse 인스턴스에 국한된 것은 아닌 것 같습니다. OG 태그에 이미지 크기를 명시해야 할 수도 있지만, 저는 그것이 필수라고 생각하지 않았습니다.
그래서… 이 문제에 진전이 있나요? 여전히 문제가 발생하고 있습니다. 우회 방법이 있다면 알려 주세요. 우리가 잘못하고 있는 부분이 있다면 그것도 알려 주세요.
상태 보고: 이 문제는 여전히 발생하고 있습니다. 새 주제에 링크를 붙여넣으면 처음에는 미리보기에서 관련 이미지가 정상으로 보입니다. 하지만 Enter 키나 스페이스바를 누르는 순간 이미지가 찌그러집니다. 원박스 트러블슈팅 단계를 다시 확인하고, 모든 오버라이드된 설정도 다시 검토해 보았지만 효과가 없었습니다. 정말 말이 안 되는 상황입니다.
그 CSS는 비최적이라고 볼 수도 있고, 어떤 타협점일 수도 있습니다. 지금 급하게 움직이고 있어서, 현재 16:9 비율을 강제하고 있는 건지 모르겠네요. 정사각형 로고에는 별로 좋지 않아요 
높이를 auto로 설정할 수 있을지 궁금하네요. (다만 세로 이미지에겐 어려움이 될 수도 있겠지만요)
어떤 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
여기에는 다음이 포함되어 있습니다:
여기서 버그는 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)입니다.
좋습니다! 그 oEmbed 데이터가 결정적인 증거인 것 같습니다. 흥미롭게도 WordPress(소프트웨어) 문서에서는 oEmbed를 다른 사이트의 콘텐츠를 WordPress 사이트에 임베드하는 맥락에서만 다루고 있으며, 그 반대 경우는 언급하지 않습니다. 그러나 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에서 변경되어야 할 문제일 수도 있습니다.
이 문제는 이전에 놓쳤지만, 이번 변경 사항으로 이제 수정되었습니다:
이 주제는 5일 후 자동으로 닫혔습니다. 더 이상 새 답변을 작성할 수 없습니다.