Gutenberg 기고자들이 메타 상자에 iframe을 사용할 때의 단점에 대해 논의합니다.

Gutenberg의 메타 박스용 iframe 사용에 관한 활발하고 생산적인 토론이 GitHub에서 진행 중입니다. 어제 WordPress 개발자 Kevin Hoffman은 "iframe이 메타 박스를 위한 실행 가능한 장기 솔루션입니까?"라는 제목의 문제를 만들었습니다.

Gutenberg 1.5는 메타 박스에 대한 초기 지원을 도입했습니다. Hoffman은 개발자가 현재 메타 상자 구현을 테스트하기 시작하면서 나타나는 iframe의 몇 가지 문제를 확인했습니다. 그는 Gutenberg의 iframe 사용이 모든 iframe뿐만 아니라 상위 창의 모든 CSS 및 JS 자산을 대기열에 추가하기 때문에 자산 요청 수를 3배로 늘리는 것으로 밝혀진 몇 가지 성능 테스트를 수행했습니다.

"일반적으로 말해서, iframe은 잘 문서화되어 있는 이유로 수년 동안 웹 개발에서 권장되지 않았습니다."라고 Hoffman은 말하면서 플러그인 개발자가 Gutenberg의 메타 박스 지원을 테스트하면서 이미 발견한 많은 문제를 언급했습니다. “메타 박스를 생성하는 테마나 플러그인을 수정하지 않고도 이러한 문제를 해결할 수 있습니까? 우리는 수년 동안 메타 박스를 구동해 온 타사 코드가 iframe 내에서 호환되기 위해 업데이트되는 사치를 누릴 수 없다는 점을 고려해야 합니다."

Gutenberg 디자인 책임자 Tammie Lister는 Hoffman의 우려에 응답하여 현재 메타 박스 구현은 단순한 실험일 뿐이며 반드시 WordPress 5.0에 포함될 필요는 없다고 말했습니다.

오늘날 구텐베르그의 메타 박스에 대해 가지고 있는 것이 실험이라는 점을 조금 생각하는 것이 좋습니다. 여러 면에서 프로젝트가 취해야 할 방향을 결정할 때 유지 패턴입니다. 그것은 '지금은' 작동하지만 우리가 함께 배송할 제품이 아니라고 말하면서.

위의 모든 것이 말했지만, 나는 미래의 메타박스가 무엇을 위해 사용될 것인지를 보는 것이 중요하다고 생각합니다. 블록으로 변환되지 않는 경우(있는 경우)는 무엇입니까? 모든 메타박스가 모바일에서 작동해야 합니까? 우리가 탐구하지 않은 대체 인터페이스가 있습니까? 나는 거기에 내기. 바로 지금, 그 가능성을 바라보고 현재의 주와 미래의 주를 위해 작동하는 길을 가는 것입니다.

구텐베르크 1.5가 "이 릴리스에는 오랫동안 기다려온 메타 박스 지원이 포함되어 있습니다(테스트 필요!)"라는 발표와 함께 "현재 작동하는"(그러나 배송되지는 않음) 실험으로 이 구현을 발표한 것은 놀라운 일입니다.

Hoffman은 iframe 접근 방식이 '현재로서는' 작동하지 않는다고 주장합니다. 문제가 몇 가지 주요 방법이 손상되었다는 점을 인용하기 위해 공개되었기 때문입니다. 구텐베르그가 현재 접근 방식으로 진행한다면 워드프레스 5.0과 호환되기 위해 많은 플러그인을 수정해야 할 것이며, 호프만은 레거시 메타 박스를 지원하려는 전체 목적을 무산시킬 것이라고 말했습니다.

호프만은 “메타 박스가 구텐베르그와 계속 협력할 것이라는 증거를 지금까지 본 적이 없다”고 말했다. "대답이 아니오라면 5.0이 또 다른 WordPress 릴리스가 될 것이라고 가장하는 것을 멈추고 이전 버전과의 호환성을 깨는 것에 대해 정직하게 시작해야 합니다."

프로젝트의 공동 작업자인 Edwin Cromley는 팀이 특정 테마와 플러그인이 손상될 것으로 예상하고 있으며 가능한 모든 사용 사례를 수용할 수는 없다고 말했습니다. 그는 iframe 솔루션이 프로젝트의 목표를 달성하지 못할 수도 있음을 인정했습니다. 대신 그는 대다수의 사용자에게 최상의 경험을 제공하는 것을 옹호합니다.

그러나 현재 접근 방식은 WordPress를 주로 메타 상자가 있는 CMS로 사용하는 많은 사이트에 부정적인 영향을 미칩니다. WordPress의 핵심 커미터인 Scott Taylor는 사용자 지정 게시물 유형에 대한 우려를 표명했으며, 그 중 다수는 메타 상자만을 위해 전통적인 "콘텐츠" 섹션을 사용하지 않습니다.

Taylor는 "현재의 반복에서 메타 상자 지원은 추가 기능입니다. 많은 사람들의 현실에서 메타 상자는 CMS를 구성하는 데 사용하는 메커니즘인 UI, API입니다."라고 Taylor가 말했습니다. “iframe은 수용소입니다.

"그리고 우리는 WP가 영원히 구축된 가치를 잊고 있습니다. 최신 버전의 WP로 업데이트할 수 있어야 하고 아무 것도 다시 작성할 필요가 없습니다. 나는 WP에 너무 많은 프로젝트를 가지고 있어서 다시는 만지지 않을 것입니다. 일부는 이 변경으로 인해 크게 깨지지 않을 것이라고 확신할 수 있습니까?”

Hoffman은 많은 플러그인 개발자가 공유하고 Gutenberg에 대한 대안적 접근 방식을 제안하는 Yoast의 게시물에서 자세히 설명된 편집기 구성 요소에 초점을 맞추기 위해 프로젝트 범위를 축소할 것을 옹호했습니다. 이 접근 방식은 편집 화면의 변경 사항을 단계적으로 처리하여 개발자가 플러그인을 업데이트할 수 있는 더 많은 시간을 제공할 뿐만 아니라 Gutenberg 팀이 메타 상자에 대한 적절한 솔루션을 찾을 수 있도록 합니다.

호프만은 “구텐베르그가 전체 페이지를 인수하기보다 편집자 개편을 고수한다면 그 목표를 훨씬 더 달성할 수 있을 것이라고 생각한다”고 말했다. “그러면 기존 후크를 그대로 두고 메타 박스가 지금처럼 계속해서 서로 통신할 수 있습니다. 또한 자산 큐잉은 오늘날과 같이 작동하므로 문제가 되지 않습니다.

“저는 Yoast가 제시한 이 개념에 전적으로 동의합니다. 이 개념은 이미 완료된 작업의 대부분을 유지하면서 프로젝트 범위를 축소하여 편집기 구성 요소에 초점을 맞추는 것처럼 보입니다.”

구텐베르크의 엔지니어인 Riad Benguella는 팀이 이 개념을 개발하는 데 그다지 열성적이지 않다고 말했습니다.

“이 개념을 구축하기 위해 Gutenberg 조각을 재사용하는 것은 비교적 가능하지만, 이것은 우리가 최적화하려는 UX가 아닙니다. 우리는 먼저 가능한 최고의 편집기를 구축하고 이전 버전과의 호환성 문제(새로 설치, 메타박스 없음… )"라고 Benguella는 말했습니다.

“Gutenberg의 이상적인 비전이 출시될 준비가 되었다고 생각되면 업그레이드 경로 전략에 대해 논의할 시간이 있을 것입니다. 이와 같은 개념은 업그레이드 경로에 대한 옵션이지만 확실히 최종 제품은 아닙니다. 다른 업그레이드 경로도 가능합니다.”

그러나 WordPress 개발자 커뮤니티는 이 논의를 다시 한 번 연기하는 데 찬성하지 않습니다. 많은 사람들이 어떻게 메타 박스가 구텐베르그 편집자의 맥락에 맞을 것인지에 대한 질문에 마침내 답하기를 열망하여 어떻게 준비해야 하는지 알 수 있습니다. iframe 접근 방식의 수많은 문제를 감안할 때 새 편집기에서 레거시 PHP 메타 상자를 렌더링하려면 더 많은 실험과 대안 솔루션이 필요합니다.

"기존 사이트와 호환되지 않는 이상적인 편집기를 개발하는 데 수천 시간을 할애하는 이유는 무엇입니까?" 호프만은 말했다. "첫인상이 의존하는 UI를 깨는 것이라면 사용자는 처음부터 이상적인 편집기를 경험하지 못할 것입니다."

WordPress 코어 커미터인 Aaron Jorbin은 "이를 너무 미루는 것은 실수일 수 있다고 생각합니다."라고 말했습니다. "특히 많은 조직이 준비하는 데 최소 1~2분기가 필요할 것이기 때문에."

Mark Kaplun은 Gutenberg 팀이 현재 및 미래의 메타 상자 지원 실험의 성공 여부를 가늠하는 척도로 인기 있는 플러그인을 사용할 것을 제안합니다.

Kaplun은 "나의 생산적인 제안은 Yoast SEO가 제대로 작동하지 않는 한 메타 상자가 준비되었다고 선언하지 않는 것입니다."라고 말했습니다. “상호작용 측면에서 약간 복잡하고 수많은 사이트에 설치됩니다. 구텐베르그가 그것을 사용할 수 없다면 아마 아무도 그것을 사용하지 않을 것입니다.”

Gutenberg의 진행 중인 개발에 대해 광범위하게 테스트하고 글을 작성한 Greg Schoppe는 프로젝트에 대한 Yoast의 대안적 접근 방식을 옹호하기 위해 대화에 참여했습니다.

“저는 구텐베르크에 대한 요스트의 견해를 적극 지지합니다.”라고 Schoppe가 말했습니다. “'비주얼 편집기 업그레이드'가 구텐베르그 팀에서 '전체 편집 후 인터페이스를 대체'하기 위해 어떻게 재해석되었는지 나에게는 분명하지 않지만, 이른바 '테세우스의 배'와 직접적으로 모순되는 것 같습니다.

“이 경우 기존 표준 워크플로에 대한 명확한 방향과 지원이 부족하여 현재 개발자에게 활발히 피해를 주고 있습니다. 신뢰할 수 있는 후크 및 도구 세트 없이 어떻게 프로젝트 빌드를 진행할 수 있습니까? 이러한 대규모 소프트웨어 프로젝트가 단일 업데이트로 개발자의 표준 워크플로를 완전히 뒤집을 것이라고 생각하는 것은 비양심적입니다. 그리고 이러한 대화가 연초에 합병을 승인할 계획인 11월에 지금 막 일어나고 있다는 것은 미친 짓입니다.”

어제 열린 메타 박스에 대한 iframe 접근 방식에 대한 논의는 아직 비교적 새로운 것이지만 지금까지 Gutenberg 팀의 응답은 이 스레드에서 개발자 커뮤니티의 우려를 적절하게 해결하는 데 실패했습니다. 사용자와 개발자를 소외시키지 않으면서 WordPress의 강력한 CMS 기능을 보존하는 메타 박스에 대한 접근 방식을 찾는 것은 구텐베르크 팀의 가장 큰 과제 중 하나입니다. 그들은 여전히 ​​내년 초에 병합 제안을 생성하는 것을 목표로 하고 있지만 메타 상자가 아직 실험 단계에 있기 때문에 팀의 예상 일정은 프로젝트를 계속해서 WordPress 개발자 커뮤니티와 불화하게 만듭니다.