Gutenberg 개발 팀, Meta Box API가 공식적으로 사용 중단되지 않을 것임을 확인

Gutenberg가 메타 상자를 처리하는 방법에 대한 토론은 참가자가 가장 최근의 이정표에서 제거되는 메타 상자 지원에 대한 우려로 GitHub 문제에 대해 언급한 후 주말 동안 가열되었습니다.

@steveangstrom은 "이 중요한 문제가 모든 이정표에서 제거되었음을 확인했습니다. "블로그 편집을 위한 종소리와 휘파람이 많은 작업을 수행하고 베타에 추가되는 동안 우선 순위가 다시 떨어졌습니다. 이는 CMS로서의 워드프레스의 미래에 대해 매우 걱정스러운 일입니다.”

프로젝트의 수석 개발자 중 한 명인 James Nylen은 구텐베르그 팀이 이 문제를 잊어버린 것이 아니라 “많은 사람들과 함께 이제 막 조사하기 시작한 매우 복잡한 문제입니다. 에디터가 잘 작동하도록 하기 위한 다른 많은 우선순위." 그는 또한 메타 박스 지원을 위한 구현을 계획하고 테스트하는 데 커뮤니티의 도움을 요청했습니다.

이 응답은 많은 것을 불분명하게 남겼습니다. 모든 메타 상자를 React 구성 요소로 다시 작성해야 하는 가능성에 대해 우려하는 개발자가 많은 토론 참가자는 메타 상자가 새로운 Gutenberg 편집기와 함께 작동할 수 없는 이유와 팀에서 메타 상자를 포함하기로 선택한 이유에 대해 궁금해합니다. 프로젝트의 범위.

"메타 박스와 기존 후크를 포함한 나머지 인터페이스를 변경하지 않고 기존 TinyMCE 포스트 편집기를 Gutenberg로 교체할 수 있습니까?" 케빈 호프만이 물었다. Nylen이 오늘 작성된 Gutenberg가 post_content 편집자가 될 것임을 분명히 했을 때 Hoffman은 많은 개발자들이 표현한 우려 사항을 요약했습니다.

Gutenberg가 진정으로 post_content 편집기가 되도록 의도된 경우 메타 상자는 post_content 와 관련이 없으므로 그대로 두어야 합니다.

게다가 PHP 메타 박스를 React 메타 박스로 변환하기 위한 API의 필요성은 제조된 문제입니다. 문제가 될 필요는 없지만 어딘가에서 post_content 편집기를 다시 작성하면 메타 상자의 작동 방식도 완전히 바꿔야 한다고 결정했기 때문에 문제가 되었습니다.

당신은 #2251에서 그러한 API를 작성하는 엄청난 도전을 설명했습니다. ACF와 같은 인기 있는 사용자 정의 필드 솔루션을 위해 PHP 메타 상자를 React로 변환하는 것은 오늘날 인기가 있든 없든 존재하는 모든 메타 상자 구현에 대해 그렇게 하려는 시도는 고사하고 충분히 어렵습니다. 확장되지 않습니다.

Gutenberg 기고자들이 메타 박스 문제를 이제 막 조사하기 시작했다고 밝혔습니다. 이제 프로젝트에서 "레거시" PHP 메타 박스를 처리하는 방법에 대한 로드맵이 없는 이유가 명확해졌습니다. 7월에 Nylen은 다음과 같이 말했습니다. - 물건들.”

메타박스 라이브러리를 관리하는 플러그인 개발자, 에이전시 등 관계자들은 구텐베르그 출시를 목표로 하는 워드프레스 5.0을 어떻게 기획할 것인지 티켓을 쫓고 있다. Andrey Savchenko는 WordPress가 메타 박스 API를 공식적으로 중단할 계획인지 물었고 마침내 팀에서 명확한 답변을 얻었습니다. Matias Ventura는 다음과 같이 대답했습니다.

"WordPress는 Metabox API를 공식적으로 사용하지 않을 계획입니까?"
아니.

아직 완전히 답변되지 않은 질문은 구텐베르크 편집기의 맥락에서 메타박스가 어떻게 작동하는가입니다. 그들은 동일하게 유지해야합니까 아니면 진화해야합니까? 가능한 한 최소한의 중단으로 설계 목표를 향해 나아갈 수 있는 방법은 무엇입니까?

이 문제는 의욕이 없어서가 아니라 자원이 부족해서 맴돌고 있습니다. 이 프로젝트의 주요 초점은 블록 개념을 통해 사용자 콘텐츠를 직접 조작할 수 있도록 최적화된 풍부한 콘텐츠 편집 인터페이스를 제공하는 것입니다. (다양한 프로젝트에서 메타박스를 광범위하게 사용했기 때문에 블록이 더 나은 사용자 경험을 제공하면서 이러한 요구 사항 중 많은 부분에 대해 더 나은 단계를 제공할 수 있다고 믿습니다.)

Ventura는 팀이 메타 상자를 처리하기 위해 고려한 몇 가지 옵션을 나열하고 최상의 솔루션을 구축하기 위해 커뮤니티에 도움을 요청했습니다.

• 메타 박스가 등록된 것을 감지하면 이전 인터페이스로 폴백할 수 있으며 아무 것도 변경되지 않습니다.
• 콘텐츠 편집과 메타 정보 수정을 두 개의 화면 또는 단계로 나눌 수 있습니다.
• #2251 콘텐츠 아래에 있는 그대로(PHP) 렌더링하는 것이 얼마나 실현 가능한지 확인할 수 있습니다.
• 테마/플러그인/CPT는 필요에 따라 새 인터페이스를 등록 취소할 수 있습니다.
• 메타 박스에 의존하는 다양한 항목을 UI용 블록으로 변환할 수 있습니다(여전히 데이터를 별도로 저장).
• Fields API와 같은 API 기반 메타 박스 확장성을 구현할 수 있습니다.

왜 메타 상자가 새 편집기의 컨텍스트에 포함되는지에 대한 질문에 답해야 한다는 질문에 Gutenberg 디자인 책임자인 Joen Asmussen은 팀이 프로젝트 범위에 메타 상자를 포함하기로 결정한 방법을 설명했습니다.

Gutenberg는 편집기 상자에서 시작했습니다. 시작 목표는 단일 통합 블록 인터페이스 아래 여러 개의 서로 다른 인터페이스를 통합하는 것이었습니다. 이 통합 블록 인터페이스를 중심으로 매력적인 경험을 만들기 위해서는 설정 및 게시를 포함한 전체 쓰기 흐름을 고려해야 한다는 것이 금세 명백해졌습니다.

워드프레스의 핵심 강점이 누구나 쉽게 풍부한 게시물을 작성할 수 있도록 하는 것이라면 이미 편집기 사용법을 알고 있는 우리를 위해 디자인할 수는 없습니다. 우리는 이전에 WordPress를 사용한 적이 없는 사용자와 그들이 현대적인 출판 인터페이스에서 무엇을 기대하는지 고려해야 합니다. 그렇지 않으면 이미 무거운 인터페이스에 인지 부하를 추가할 뿐입니다.

메타 박스가 구텐베르크 편집기의 맥락에 어떻게 맞을 것인지에 대한 질문은 여전히 ​​열려 있습니다. 토론 참가자들은 이전 버전과의 호환성을 위해 그리고 구텐베르크 개발 및 화면 디자인에 관한 진행 중인 결정에 영향을 미치기 때문에 이 질문에 대한 답변을 간절히 원합니다.

Xavi Ivars는 이 문제에 대해 "'스크린' 교체 접근 방식에 대해 얼마나 많은 작업이 수행되었는지 완전히 이해합니다."라고 말했습니다. “하지만 '포스트 콘텐츠 에디터' 교체를 목표로 시작한 프로젝트가 일방적으로 전체 에디터 화면을 교체하기로 결정하기 전에 커뮤니티로 돌아가야 하지 않을까요?”

메타 상자 API가 더 이상 사용되지 않지만 Gutenberg가 "레거시" PHP 메타 상자를 지원하는 방법에 대한 명확한 경로도 없습니다. 구텐베르그 팀은 자원 부족으로 문제가 해결되지 않았다고 말했다. 팀이 최소한의 손상으로 대부분의 WordPress 사이트를 Gutenberg 시대로 원활하게 안내하는 솔루션에 착수하려면 프로젝트에 커뮤니티 의견과 더 나은 의사 소통이 필요합니다.

현재 콘텐츠 아래에 레거시 PHP 메타 상자를 렌더링하는 가능성은 많은 도전을 받고 있으며 여전히 논쟁의 대상입니다. 개발자가 작업을 JS 기반 메타 상자에 다시 작성할 시간이나 클라이언트 리소스가 충분하지 않은 경우 레거시 "PHP" 메타 상자를 보존해야 하는 사이트에 대해 Gutenberg 인터페이스를 선택 해제하기 위한 명확한 경로가 필요할 수 있습니다. .