Gutenberg 기고자들은 메타 박스에 iframe을 사용하는 대안을 모색합니다.

구텐베르그에서 메타 박스에 iframe을 사용하는 것에 대한 논의는 주말에 더 뜨거워졌습니다. 우려되는 개발자들이 현재 접근 방식의 단점을 고려하도록 팀에 간청했기 때문입니다. Gutenberg의 지도부는 처음에 우려를 빗나가게 하여 iframe 구현을 "현재는" 작동하지만 팀에서 제공하는 것과는 다른 실험으로 제시했습니다.

iframe 접근 방식의 성능 및 접근성에 대한 특정 문제에 대한 응답을 얻는 대신 Kevin Hoffman은 메타 박스의 미래와 "블록으로 변환되지 않을 경우(있는 경우)"에 대해 생각하도록 촉구받았습니다. 개발자 커뮤니티가 반복적으로 테스트하고 피드백을 제공하라는 요청을 받았지만 WordPress를 CMS로 사용하는 사이트에 중요한 문제에 대한 편향을 만나면 GitHub 토론이 더 뜨거워지기 시작합니다.

"사람들은 걱정하고 좌절하며 구텐베르그에서 작업하는 팀이 메타 박스가 어떻게 사용되는지에 대한 이해가 거의 없고 영향에 대한 관심이 거의 없다는 인식 때문에 그렇게 할 수 있는 모든 권리가 있는 것 같습니다. , 그리고 무슨 일이 있어도 그들의 비전을 향해 전진할 것입니다.”라고 Johns Hopkins의 외부 업무 담당 수석 개발자인 Jimmy Smutek은 구텐베르그 협력자들이 피드백을 무시했다는 사실을 인정한 것에 대한 응답으로 말했습니다.

메타 박스용 iframe이 "지금은 작동한다"는 개념을 폭로하기 위해 스레드에 여러 개발자가 참여한 후 Gutenberg의 수석 개발자 Matias Ventura가 어제 토론에 참여했으며 실험이 곧 중단될 가능성이 있음을 확인했습니다.

“나는 대화가 결국 주제의 문제로 다시 초점이 맞춰져서 기쁩니다. iframe의 메타 박스에 대한 현재 접근 방식이 실행 가능한가? 대답은 아니오입니다.”라고 Ventura는 말했습니다. “iframe은 구현 세부 사항이므로 비교적 쉽게 삭제할 수 있습니다. 그러니 그것에 집중하자.”

그는 또한 WordPress가 메타 상자를 정밀 검사하기 전에 편집기 자체(전체 페이지가 아님)를 반복적으로 개선해야 한다는 대중적 의견에 대해 언급했습니다.

Ventura는 "일부 사람들이 실용적인 접근 방식이라고 부르는 것은 이 프로젝트가 처음부터 전체 사이트 사용자 지정을 향한 디자인 방향과 지금까지 우리의 결정을 지시한 것과 일치하지 않습니다"라고 말했습니다. "여기에 있는 어떤 것도 최종 솔루션일 필요는 없습니다. 우리는 설계 전제 내에서 가능한 것을 탐구하고 테스트를 위해 거기에 배치합니다."

Ventura는 편집 화면의 다른 측면을 변경하지 않는 것이 확실히 Gutenberg가 취할 수 있는 가장 간단한 방법이지만 "프로젝트의 목표와 WordPress의 장기 사용자에 공정하지 않을 것"이라고 말했습니다.

WordPress 개발자 Gary Jones는 더 반복적인 접근 방식을 추구하는 것이 프로젝트의 목표를 변경하는 것은 아니지만 프로세스 중에 더 많은 사이트를 만들 수 있다고 주장했습니다.

Jones는 "한 번에 한 단계씩 진행하는 것은 어떤 식으로든 프로젝트의 목표를 손상시키지 않습니다."라고 말했습니다. "그것이 목표라면 여전히 전체 크기의 사용자 정의로 향할 수 있지만, 단계적으로 수행하면 나머지 개발자 커뮤니티를 함께 가져올 수 있습니다." Jones는 많은 반복을 통해 시간이 지남에 따라 실현되고 있는 개념을 가진 WordPress 내 기능의 예로 Customizer를 인용했습니다.

Ventura는 처음부터 블록 기반 콘텐츠 생성을 지원하는 패러다임 전환인 프로젝트 반복에 대한 Gutenberg 팀의 접근 방식에 대해 설명했습니다.

"우리는 Matt의 원래 새로운 초점 포스트에서 단계적 접근 방식을 제안했지만 단계를 다르게 고려합니다."라고 Ventura가 말했습니다. “구텐베르크 프로젝트에는 일반적으로 포스트 편집기, 페이지 템플릿, 사이트 구축의 세 단계가 있습니다. 근본적인 것은 내용이 단일 영역이고 블록을 기본 개념으로 하고 결과가 과도한 추상화 없이 명확하게 시각적으로 표현될 수 있는 패러다임이라는 것입니다.”

Ventura는 또한 프로젝트가 메타 박스에 대한 지원을 중단하지 않을 것이지만 다른 인터페이스 옵션을 실험하는 데 더 많은 시간이 필요하다고 논의를 따라가는 사람들을 안심시켰습니다.

"WordPress는 항상 사용자와 함께 움직이며 우리는 기존 코드를 쉽게 전환할 수 있도록 개발 경로를 파악하는 부담을 지고 있습니다."라고 그는 말했습니다. “프로젝트로서 우리는 WordPress에서 메타 박스에 대한 지원을 중단하지 않을 뿐만 아니라 클래식 편집기를 로드할 가능성을 포함하여 새로운 패러다임 내에서 어떤 인터페이스 결정을 내려야 하는지 탐구해야 한다고 말했습니다. 콘텐츠와 메타 데이터를 보다 명확하게 설명하려는 편집자와 직접 충돌하거나 처리할 수 없는 메타 상자를 감지하면."

그는 또한 팀이 비호환성을 처리하기 위해 더 많은 메커니즘을 만들 계획이라고 말했습니다. "

iframe을 사용하지 않고 메타 상자를 렌더링하는 새로운 접근 방식이 현재 진행 중입니다. Riad Benguella는 iframe을 실행 취소하고 Tom Nowell이 토론 중에 제안한 제안을 구현하려는 끌어오기 요청을 만들었습니다.

설정 페이지에서 Gutenberg를 로드하는 대신 기본 클래식 편집기 페이지로 로드하고 기본 환경에서 메타박스를 로드한 다음 JS를 통해 컨테이너 DOM 노드를 구성 요소로 호이스트합니다.

그런 다음 다른 종류의 토글을 사용하여 클래식 편집기를 계속 사용할 수 있는지 확인합니다. 이 방법:

– 우리는 iframe 넌센스를 피합니다.
– 메타박스는 등록에 관한 한 항상 그랬던 것처럼 작동합니다.
– 기존 JS는 예상대로 작동하며 PHP 측에서 작동하도록 하는 해킹이 필요하지 않습니다.

새로운 접근 방식은 링크, 모달, 중복 스타일시트 및 iframe 사용에 대한 기타 단점에 문제가 없다는 장점이 있습니다.

Gutenberg 팀은 새로운 커뮤니케이션 전략이 필요합니다

메타 박스에 iframe을 사용하는 것의 장기적 실행 가능성에 대한 논의는 Gutenberg 리드 간의 통합된 메시지 또는 커뮤니케이션 전략의 부족을 강조했습니다. 프로젝트의 공동 작업자는 커뮤니티가 비전을 이해하지 못하는 것에 대해 참을성이 없어졌지만 커뮤니케이션은 다양한 블로그, 댓글, Slack 채널 및 GitHub 토론에 흩어져 있습니다.

Morten Rand-Hendriksen은 Gutenberg의 범위, 방향 및 목표에 대한 일반 언어 개요 역할을 할 수 있는 중앙 집중식 리소스를 요청하는 새로운 문제를 시작했습니다.

Rand-Hendriksen은 "내가 관찰한 바에 따르면 커뮤니티는 이 정보를 포함하는 신뢰할 수 있는 일반 언어 리소스가 없기 때문에 Gutenberg 프로젝트의 더 넓은 범위를 보기 위해 고군분투하고 있습니다."라고 Rand-Hendriksen이 말했습니다. "이는 모든 당사자로부터 높은 수준의 추측, 잘못된 의사 소통 및 좌절을 야기하고 결과적으로 프로젝트가 고통을 겪습니다."

Gutenberg에는 문서 허브가 있지만 지금까지 해당 문서는 더 기술적이고 팀이 목표를 달성하는 방법에 대한 실용적인 로드맵이 부족합니다. 현재 문서의 FAQ 섹션은 Rand-Hendriksen이 티켓에서 요청한 일반 언어 리소스에 가장 가까운 것입니다. Gutenberg의 GitHub 리포지토리와 WordPress.org 플러그인 모두에 대한 readme.txt 파일은 프로젝트가 전체 편집기 화면을 점검하는 것이 아니라 단순히 현재 편집기를 블록 기반으로 업데이트하고 있다는 인상을 줍니다.

"이 정보의 분열된 특성으로 인해 누군가가 전체 프로젝트를 명확하게 파악하는 것은 어렵습니다. Matias와 Matt의 게시물은 프로젝트의 원대한 비전을 잘 설명하고 있지만 구체적인 일반 언어 분석이 부족합니다. 커뮤니티는 이 프로젝트가 무엇이며 어디로 향하고 있는지 확고하게 이해해야 합니다.”라고 Rand-Hendriksen이 말했습니다. "그들은 또한 프로젝트 자체의 핵심 부분이 아니라 프로젝트를 순환하는 독립적인 정보 위성으로 존재합니다."

커뮤니티는 보다 투명한 일반 언어 제품 로드맵에서 답변을 원하는 질문으로 GitHub 문제에 대해 이야기하고 있습니다. 이와 같은 문서는 Gutenberg 팀이 프로젝트의 목표를 더 잘 전달하고 불필요한 혼란을 야기하는 혼합 메시지를 보내는 것을 방지하는 데 도움이 될 수 있습니다.