FWIW 웹 개발자와 이야기 할 때 그들은 모두 콘텐츠에 메타 박스를 사용하여 최대한의 제어 권한을 갖습니다. 메타 박스가 많은 사람들에게 "레거시"로 간주 될 것이라고 확신하지는 않지만 오히려 미래의 일부로 간주 될 것입니다. WordPress VIP 직원에게 연락하여 의견을 구하는 것이 좋습니다.

메타 박스가 많은 사람들에게 "레거시"로 간주 될 것이라고 확신하지는 않지만 오히려 미래의 일부로 간주 될 것입니다. WordPress VIP 직원에게 연락하여 의견을 구하는 것이 좋습니다.

죄송합니다. 그 문구가 잘못되었습니다. Metabox는 여기에 있습니다. 이것이 메타 박스 사이드 바가 새로운 "포스트 설정"사이드 바의 형태로 업그레이드되는 이유입니다.

제가 말하고자하는 것은 새로운 메타 박스는 JS로 작성되어야하고, 스톡과 함께 포스트 설정 사이드 바에 나타날 것입니다. PHP로 작성된 메타 박스는 이상적으로는 JS로 업그레이드해야하지만 PHP 형식에서도 계속 작동해야합니다. 이것이 바로 "확장 설정"패널의 용도이며, 사이드 바의 일부가되기를 원하지 않기 때문이 아니라 사이드 바에서 PHP와 JS 메타 박스를 혼합하기가 매우 어렵 기 때문에 하단에 있습니다.

JS 및 Ajax를 통해 PHP로 관리되는 메타 박스를 제출하는 데는 몇 가지 큰 문제가 있습니다. 특히 새로 저장된 상태를 반영하기 위해 메타 박스 렌더 업데이트를 처리하는 방법은 다음과 같습니다. https://core.trac.wordpress.org/ticket/7756

iframe을 통해 레거시 메타 박스를 포함하는 것이 여기서 해결책이 될 수 있을지 궁금합니다. 여기서 iframe src는 /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings 와 같고 해당 메타 박스 하나만 문서에 출력합니다.

제가 말하고자하는 것은 새로운 메타 박스는 JS로 작성되어야하고, 스톡과 함께 포스트 설정 사이드 바에 나타날 것입니다.

이것은 자바 스크립트 메타 박스가 사이드 바에 만 들어갈 수 있고 "확장 설정"섹션의 일부가 될 수 없다는 것을 의미합니까? 내 머리 꼭대기에서 사이드 바가 충분한 공간을 제공하지 않고 사이드 바를 잠재적으로 어수선하게 만드는 많은 플러그인을 생각할 수 있습니다. 이 접근 방식에 문제가있을 수있는 몇 가지 플러그인 :

• Yoast SEO : 사이드 바에 맞지 않을 수있는 많은 필드를 제공합니다. 더 많은 옵션을위한 모달을 여는 사이드 바 메타 박스가있을 수 있지만 불필요한 제한을 해결하는 것처럼 느껴집니다.

• 사용자 정의 필드 플러그인 / 드래그 앤 드롭 페이지 빌더-메인 콘텐츠 영역을 대체하거나 부분적으로 대체하므로 충분한 화면 공간이 필요합니다. 전체 페이지 빌더는 별도의보기로 자체적으로 완전히 사용자 정의 된 인터페이스를 구축 할 수 있지만 경우에 따라 기본 콘텐츠 영역 외에도 여러 가지 추가 구조화 된 필드가 필요합니다 (Guttenburg는 이러한 유형의 플러그인이지만 똑같이 모든 사용 사례를 다룰 수는 없습니다)

• WooCommerce-주 편집기를 제거하는 동안 주문 및 광고 항목 데이터에 대한 메타 박스를 추가합니다 (Woo는 결국 고유 한 사용자 정의 인터페이스를 구축 할 계획이지만 이는 먼 길일 것으로 생각되며 다른 플러그인도 비슷한 상황에있을 것입니다)

(저는 Guttenburg가 단순히 대안이되는 것이 아니라 결국 현재 post-new / post-edit.php 뷰를 대체 할 계획이라고 가정하고 있습니다.)

Ha 감사합니다 @braders -Yoast UX-er가 같은 질문으로 여기에 체크인했습니다 :)

우리의 메타 박스는 많은 일을하기 때문에 현재 꽤 크고 넓습니다. 더 긴밀한 통합을 제공하기 위해 이러한 기능을 사이드 바의 다른 메타 박스로 더 많이 작업하는 것을 신경 쓰지 않을 것입니다.하지만 이것이 가능할지 궁금합니다. 예를 들어, 현재처럼 게시 상자에 SEO 점수를 추가 할 수 있습니까? 그렇지 않은 경우 메타 박스가 JS로 코딩되어 있어도 확장 설정 상자에 연결할 수 있습니까?

사이드 바에 자바 스크립트 메타 박스를 추가 할 수 있도록 새 게시물 설정을 플러그 형으로 만드는 것을 절대적으로 고려해야합니다. 아마도 티켓을 열 때입니다. 이 티켓은 대부분 전환 방식으로 작동해야하는 PHP로 작성된 메타 박스 용입니다.

확장 섹션의 메타 박스와 같은 줄을 따라 게시물 내용 편집을 지원하지 않는 게시물 유형이 표시되는 방법에 대한 논의 또는 모형이 있었습니까? 이러한 경우 중간 영역의 메타 박스는 기본 편집 환경에 의존합니다. 구텐베르크는 "제목 전용"모드를 제시해야합니까? 또는 편집자가 없을 때 게시물 제목을 다르게 처리해야합니다.

확장 섹션의 메타 박스와 같은 줄을 따라 게시물 내용 편집을 지원하지 않는 게시물 유형이 표시되는 방법에 대한 논의 또는 모형이 있었습니까? 이러한 경우 중간 영역의 메타 박스는 기본 편집 환경에 의존합니다. 구텐베르크는 "제목 전용"모드를 제시해야합니까? 또는 편집자가 없을 때 게시물 제목을 다르게 처리해야합니다.

이것은 별도의 티켓을 만드는 것이 좋습니다! 기존 포스트 유형의 스크린 샷을 가지고 있다면! ✨

또한 많은 플러그인이 콘텐츠 편집기없이 메타 상자에 의존하는 사용자 지정 게시물 유형을 사용한다는 점을 강조하고 싶습니다. 게시물 유형이 editor 지원없이 등록 된 경우 메타 상자에서 사용할 수 있도록 전체 캔버스를 여는 제목 전용 모드가 있어야합니다.

WordPress VIP에 연락하기 위해 +1. 이것은 Calypso 스레드의 문제이기도합니다 : https://github.com/Automattic/wp-calypso/issues/587

시장 최고를위한 정말 중요한 기능!

iframe을 통해 레거시 메타 박스를 포함하는 것이 여기서 해결책이 될 수 있을지 궁금합니다. 여기서 iframe src는 /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings 와 같고 해당 메타 박스 하나만 문서에 출력합니다.

나도 같은 생각을 가지고 있었다. 샌드 박싱 및 세션 관리 이유에도 좋은 생각입니다. 그런 다음이 기능의 일반적인 사용 사례를 식별하고이를 처리하기위한 API를 구현할 수 있습니다.

플러그인 개발자이자 주로 전자 상거래 도구로 WordPress를 사용하는 사람으로 들어가고 싶었습니다. 또한 @kevinwhoffman 이 나에게 말했다.

오늘 구텐베르크를 지 쳤고 메타 박스와 편집기 버튼 (media_buttons 후크를 통해 추가됨)이이 부분에 포함되는 방식을 보지 않고는 말 그대로 WordPress로 처리 할 수 ​​없습니다.

나는 또한 WordPress 편집기와 metabox-palooza의 현재 상태에 대한 열렬한 팬이 아닙니다. 방금 계산하고 다운로드 (Easy Digital Download의 제품 게시물 유형) 단일 게시물보기에 Yoast, Easy Digital Downloads 및 CMB2를 사용하는 내 사용자 지정 코드에 의해 추가 된 14 개의 사용자 지정 메타 상자가 있습니다. 많지만 필요합니다. 워드 프레스는 그 인터페이스와 그것이 드러내는 것 없이는 무의미합니다.

ACF, Pods, CMB2 등으로 추가 된 사용자 정의 필드 인터페이스가 전체 편집 경험이었던 너무 많은 사이트에서 작업했기 때문에 이것이 처음부터 고려되지 않았던 것 같습니다.

내 기술적 문제는 다음과 같습니다.
1) media_buttons를 통해 추가 된 버튼. 내 플러그인 Caldera Forms (80K + 활성 설치)에서이 작업을 사용하여 포스트 편집기에 단축 코드를 삽입하는 모달을 표시하는 양식 삽입 버튼을 추가합니다. 아마도 우리는 구텐베르크의 커스텀 블록으로 이동할 것입니다.
2) save_post 액션은 어떻게 하위 호환성을 유지합니까? 많은 플러그인, 테마 및 사용자 정의 코드가 save_action에 연결되고 $ _POST 수퍼 글로벌에 액세스합니다. 좋은 디자인은 아니지만 수백만 사이트에 영향을 미치는 기술적 부채입니다.
3) iFrame에서 레거시 메타 박스를 렌더링하라는 제안이있었습니다. 자바 스크립트를 통해 iFrame의 콘텐츠에 액세스 할 수 없기 때문에 걱정됩니다.

@ Shelob9 안녕하세요!

iFrame에서 레거시 메타 박스를 렌더링하라는 제안이있었습니다. 자바 스크립트를 통해 iFrame의 콘텐츠에 액세스 할 수 없기 때문에 걱정됩니다.

자바 스크립트를 통해 iframe의 콘텐츠에 액세스하는 것은이 경우와 같이 동일한 도메인에있는 한 가능합니다.

save_post 작업은 어떻게 이전 버전과 호환됩니까? 많은 플러그인, 테마 및 사용자 정의 코드가 save_action에 연결되고 $ _POST 수퍼 글로벌에 액세스합니다. 좋은 디자인은 아니지만 수백만 사이트에 영향을 미치는 기술적 부채입니다.

레거시 메타 박스를 구텐베르크로 쉽게 전환하기 위해 할 수있는 일이 너무 많습니다. 구텐베르크에서 데이터가 모델링되는 방식과 현재 포스트 편집 화면에는 근본적인 차이가 있습니다. 즉, 데이터는 이제 실제로 처음으로 모델링됩니다. 데이터 모델링을 통해 마지막으로 $_POST 및 save_post 작업을 사용하여 불가능한 방식으로 postmeta의 변경 사항을 _preview_ 할 수있는 방식으로 postmeta의 상태를 조작하기 위해 JavaScript 인터페이스를 사용할 수 있습니다. 모델을 통해 포스트 메타 변경 사항을 라우팅하면 포스트 메타를 처음으로 미리 볼 수 있습니다. 따라서 구텐베르크는 가능할 때마다 레거시 메타 박스를 포함 할 수 있지만 새 인터페이스를 활용할 수있는 정도는 항상 본질적으로 제한됩니다. 기술 부채가있는 현실만큼이나 현실이라고 생각합니다.

WordPress가 향후 관련성을 유지하는 방식으로 발전하려면 기술 부채를 취소해야한다는 Matt의 의도적이고 의식적인 결정이라고 생각합니다. 구텐베르크가 도입 한 데이터 모델을 사용하기 위해 ACF, Pod 및 CMB2를 더 많이 업데이트할수록이 전환이 더 쉬워 질 것이라고 생각합니다. 앞으로도 많은 도전과 노력이있을 것입니다!

@westonruter 덕분에 확장 설정 영역의 목적이 훨씬 더 명확 해졌습니다.

여기서 논의 중 일부는 사용 가능한 화면 공간에 대한 부분이기도합니다.

구텐베르크 JS 메타 박스는 토글 가능한 사이드 바에 접근 할 수 있고 (저는 괜찮습니다) 레거시 PHP 메타 박스는 화면 하단에있는 훨씬 더 넓은 영역에 접근 할 수 있습니다 (저도 괜찮습니다).

안타깝게도 사용 가능한 화면 공간에 대한 이러한 열망이 레거시 PHP 메타 박스를 효과적으로 처리하는 방법에 대한 의도 된 논의를 방해 할 수있을 것으로 예상합니다.

플러그인 제작자는 모든 기존 방식을 지원하는 대신 메타 박스를 재고하고 새 레이아웃과 더 잘 통합 할 수있는 방법을 고려해야한다는 데 동의합니다. 동시에, 나는 또한 유사한 통합 가능성이 새 편집자에서도 제공되어야한다는 데 동의합니다 (그리고 그럴 것이라고 믿습니다). 나는 # 1352가 현재 그것을 논의하는 주요 장소라고 생각합니다. 이 문제는 출시시 업데이트되지 않은 PHP 메타 박스에 대해 이전 버전과의 호환성을 제공하는 방법을 논의하기위한 것입니다.

iframe을 통해 레거시 메타 박스를 포함하는 것이 여기에 해결책이 될 수 있는지 궁금합니다.

iframe에 액세스하는 것은 스크린 리더 사용자에게 매우 흥미로운 경험이 아닙니다. 다른 옵션이 있습니까?

그냥 여기에 차임하고 싶었는데, 사이드 바는 플러그인과 테마에서 볼 수있는 대부분의 메타 상자에 비해 충분히 크지 않습니다. 우리가이 작은 공간에 물건을 집어 넣도록 강요하는 것은 제 생각에 좌절입니다. 나는이 새로운 편집기가 훌륭하다고 생각하지만 그것이 오늘날 우리가 메타 박스를 사용하는 방식을 희생하는 것을 의미한다면 그렇지 않습니다.

@kevinpmiller에 강력하게 동의합니다. 메타 박스는 많은 공간을 필요로하며 사이드 바에 숨길 수 없습니다. 메타 박스의 현재 상태는 분리되고 잘못된 디자인이지만 WordPress가 무엇인지, 즉 고도로 확장 가능한 CMS도 반영합니다.

@westonruter 에 대한 답장으로 이전 버전과의 호환성을 명확히

특히 콘텐츠 편집기가 CPT의 주요 초점이 아닐 수있는 특정 사용자 지정 게시물 유형에서 메타 박스가 처리되는 방식에 대해서도 우려합니다. 잘 알려진 플러그인이기 때문에 여기에서 WooCommerce를 선택하겠습니다.하지만 유사한 문제가있는 다른 플러그인과 테마가 많이 있습니다.

예를 들어 WooCommerce 주문에는 콘텐츠 편집기가 없으며 단순히 필요하지 않습니다. 순서에 대한 세부 사항은 컨텐츠 편집이 아니라 중요한 것이며 해당 페이지의 주요 초점이어야합니다.

이와 같은 CPT는 필요하지 않은 경우 편집기를 제거 할 수 있습니까? 플러그인은 CPT의 사용자 지정 메타 박스와 완전히 통합되지 않은 것 같아서 이것이 고려되었는지 여부를 말하기가 어렵습니다.

WooCommerce 제품은 또한 두 개의 콘텐츠 영역이있는 또 다른 문제를 제기합니다. 하나는 제품 설명을위한 것이고 다른 하나는 제품의 간단한 설명을위한 것입니다. 하나는 "메인"편집기 영역에서 다른 하나보다 우선해야하는 반면 다른 하나는 사이드 바에 갇혀 있어야합니까? 사이드 바에있는 편집 환경은 최적이 아닌 것 같습니다.

사이드 바에 모두 넣는 대신 편집기 아래 (또는 위) 영역에 이러한 설정을 의도적으로 등록하는 옵션이 있습니까? 이는 현재 add_meta_box 컨텍스트 및 우선 순위 매개 변수와 유사 할 수 있습니다. 페이지의 더 넓은 섹션에 속하는 여러 콘텐츠 편집기 (또는 다른 메타 박스)간에 전환 할 수도 있습니다.

아마도 여기에서 뭔가 빠졌을 수도 있지만 (내가 틀렸다면 수정 해주세요), 실제로는 더 나은 편집기를 위해 엄청난 압박이 가해지고있는 것 같습니다.

Gutenberg (편집자 없음과 동일)를 사용하지 않도록 CPT를 정의하는 방법에 대해 질문 하고 비즈니스가 의존하는 전체 너비 메타 박스 만 표시합니다.
저는 메타 박스에 의존합니다. 대부분의 경우 내 CPT는 다음과 같습니다.
'supports' => array( 'title' )
그리고 거기에서 확장됩니다. 기사 작성보다는 제한되고 안내 된 양식 데이터 입력으로 메타 박스와 함께 CPT를 사용하는 클라이언트를위한 비즈니스 도구를 구축 한 우리를 고려하십시오.
내 작업은 대부분 클라이언트 시스템과 인터페이스하는 CMB2에 대한 사용자 지정 확장입니다. 제 3 자 시스템을 요구하는 EG 부동산 목록.

드라마틱하게 들리고 싶지는 않지만이 문제가 해결 될 때까지 WP4.9를 고수하고 미래에 대해 매우 걱정합니다. 나는 구텐베르크가 "과거에 대한 부채를 취소"하고 있다는 것을 이해합니다! 하지만 빚은 저 같은 사람들에게옵니다.

여기서 주제는 문제가 Guttenburg가 아니라 이전 버전과의 호환성이 없다는 것입니다.

별도의 티켓을 제기해야하는 실제 Guttenburg 문제가 있지만 (메타 박스가 편집자 지원없이 전체 너비, 모형 Guttenburg를 사용하도록 허용) Gutturnberg는 현재 화면을 완전히 복제 할 수 없으며 IMHO를 시도해서는 안됩니다.

그러나 Guttenburg를 옵트 인 / 옵트 아웃하기 위해 더 많은 조치를 취해야할지 궁금합니다. 몇 가지 아이디어 :

• 대부분의 최신 CPT는 메인 편집기보다 메타 박스를 많이 사용한다고 생각합니다. 따라서 플러그인 작성자는 'supports' => array( 'gutenburg' ) 또는 이와 유사한 것으로 Gutturnberg를 선택해야합니다.

• 게시물과 페이지의 경우 Guttenburg는 사이트 설정으로 선택 사항 일 수 있습니다. 5.0 업데이트 이후에 Guttenburg를 사용할 것인지 사용자에게 물어보고이 선택 사항을 DB에 저장할 수도 있습니다.

• 또는 테마는 post_type_supports ()를 통해 지원을 선언 할 수 있지만, 이는 사용자의 이해를 심각하게 해칠 수 있습니다. 또는 더 이상 업데이트되지 않는 유지 관리되지 않는 레거시 테마의 사용자에게 도움이되지 않는 테마를 선택 해제 할 수 있습니다. (아마도 remove-guttenburn 플러그인이 레거시 테마 사용자에게는 충분할까요?)

하지만 구현 여부와 관계없이 현재 뷰가 대다수의 사용자에게 점점 더 가려 지더라도 현재 뷰는 유지되어야한다고 생각합니다.

'gutenberg'지원 플래그가 정의되지 않은 경우 기존 기능을 유지하기 위해 'supports' => array( 'gutenberg' ) 를 명시 적으로 요청하는 CPT의 이론적 아이디어가 마음에 듭니다. WP5로 업데이트 한 화난 클라이언트를 위해 오래된 사이트를 수정하는 작업을 많이 절약 할 수 있습니다.

기존의 '지원'=> 기능 (제목, 편집자, 저자, ...)은 매우 자명 한 이름을 가지고 있으며, 구텐베르크는 여기서 _project_ 이름으로 두드러집니다. 더 설명적인 기능 이름이 해당 용도로 고려되는지 궁금합니다. 아마도 "블록 편집기"? 'supports' => array( 'block-editor' )

물론 'supports' => array( 'title','editor',thumbnail', 'block-editor' ) 와 같은 실수를 포착하기위한 전략이 필요합니다. 'block-editor'플래그가 이전 '에디터'모드를 덮어 쓸 것이라고 가정합니다.

우려되는 또 다른 플러그인 개발자.

사이드 바 메타가 JS를 통해서만 액세스 할 수있는 경우 컨텍스트가 side PHP 등록 메타 박스에 어떤 의미가 있습니까? 제안 된 확장 설정 섹션으로 이동하면 해당 메타 박스가 상황에 맞는다는 생각이 취소됩니다.

우리 모두 알고 있듯이 사이드 바는 디자인에 대한 좋은 결정일뿐입니다. 사용자가 콘텐츠의 우선 순위 및 주요 콘텐츠와의 관계를 이해하는 데 도움이되는 방식으로 관계형 콘텐츠를 자주 보유합니다. 기술적 장벽으로 인해 side 메타 박스에 다른 컨텍스트를 할당하는 것은 약간 잘못된 것 같습니다.

관리 영역의 점진적인 JS- 화를 고려할 때 이러한 "레거시"메타 박스는 플러그인 및 테마 개발자에게 자체 포함 된 React / Vue / 기타 앱에 대한 자연스러운 마운트 지점을 제공하여 편집 페이지에 추가 기능을 제공합니다.

편집기는 훌륭해 보이지만 페이지의 나머지 부분을 잊지 마십시오.

나는 이것에 대해 조금 더 생각할 기회가 있었고 여기에서 다른 사람들이 공유 한 맥락을 가지고 나는 또 다른 문제가 있다고 생각합니다. 이 새로운 편집기는 우리를 단일 레이아웃과 워크 플로우로 강제합니다. 사용자 지정을 제거하는 이유는 무엇입니까? 클라이언트 단위로 데이터 입력을 조각하는 기능은 WordPress 및 대부분의 다른 솔루션을 정말 훌륭하게 만듭니다. 이 편집기를 더 많이 사용할수록 미리보기 영역이 편집기로 바뀌고 사이드 바가 옆으로 바뀐 커 스터 마이저의 부풀어 오른 버전처럼 느껴집니다.

게시물을 작성하는 데 사용할 수 있지만 CPT가 이에 대한 지원을 추가 할 수 있다는 것도 언급되었습니다. 나는 그것이 실제로 작동하지 않을 것이라고 생각합니다. 뉴스 조직은 이러한 유형의 편집자를 좋아할뿐만 아니라 추가 콘텐츠, 일정, 임베드, 인포 그래픽 및 기타 필요한 데이터와 관련된 사용자 지정 워크 플로에 대한 요구 사항도 가지고 있습니다.

이 편집기를 전체 화면 / 산만없는 편집기처럼 작동하게 만드는 것은 어떻습니까? 이렇게하면 기능과 "레거시"코드를 희생하지 않고도 두 세계의 장점을 모두 누릴 수 있습니다. (BTW-현재 우리가 메타 박스를 구축하는 방식이이 프로젝트에서 "레거시 ..."라고 불리는 것은 우스꽝스러운 일이라고 생각합니다.)

시간 내 주셔서 감사합니다.

이 편집기를 전체 화면 / 산만없는 편집기처럼 작동하게 만드는 것은 어떻습니까?

+1

나는 내 주요 관심사를 반복 할 것이다. CPT는 종종 사용자가 안내하는 워크 플로우 (예 : WooCommerce 제품 데이터)에서 크고 동적으로 그룹화 된 메타 박스로 게시물이 작성되기 때문에 '편집기'가 필요하지 않습니다.

이러한 메타 박스는 제안 된 "확장 된 설정"드로어에 맞지 않을 것입니다. 기본 콘텐츠 입력 요소를 형성하고 포스트 편집기에서 눈에 잘 띄고 전체 너비로 열려 있어야하기 때문입니다. 이를 염두에두고 # 952는 중요한 데이터 입력을 닫힌 서랍으로 옮기기 때문에 너무 작은 양보로 ​​보입니다.

개발자가 모든 기존 메타 박스 솔루션을 블록으로 _ 리팩토링 _ 할 것으로 예상되는 경우 Automaticc의 누군가가 해머가 5.0으로 떨어지기 전에 명확하고 공개적으로 언급해야합니다. 팀이 시장의이 부분과 비즈니스에 미치는 영향을 고려했다는 징후는 보이지 않습니다.

여기에 이미 많은 좋은 생각이 추가되었으므로 다음과 같은 간단한 생각을 던져 보겠습니다.

모든 레거시 항목에 대해 하단에 "확장 설정"확장기를 사용하는 대신 메타 박스가 일반 및 고급 컨텍스트에있을 때 정확히 그와 같이 하단에있는 각 메타 박스에 대해 확장기를 만든 다음 측면 컨텍스트에 대한 측면 설정?

우리는 해결책에서 그렇게 멀리 떨어져 있지 않은 것 같습니다. 게시물 유형이 편집기를 지원하지 않는 경우 편집기를 숨기고 다른 모든 항목이 동일한 방식으로 표시되도록합니다. 합리적인 레이아웃입니다. 기본 확장 메타 박스 설정과 같은 옵션을 제공하면됩니다.

메타 박스 레거시를 렌더링하는 현재의 방법을 고려하고 필드를 구축하는 새롭고 js 기반의 선호하는 방법을 제공한다는 생각은 확실히 신경 쓰지 않습니다. 그런 다음 5.0에서 즉시 중단되는 일에 대해 당황 할 필요없이 점진적으로 전환 할 수 있습니다.

이러한 생각이 도움이되기를 바랍니다. 다른 사람이 이미이 효과에 대해 말한 경우 동의로 받아들이십시오. 😄

토론에 다른 두 가지 가치있는 후크를 추가하고 싶습니다 : edit_form_after_title 및 edit_form_after_editor . 현재 편집 후 UI를 완벽하게 제어 할 수 있습니다. 분명히 Gutenberg는 단순히 "wp_editor"를 대체하는 것이 아니라 UI에서 완전히 다른 방식입니다 (현재 보이는 것처럼 향후 모듈 식 확장 성).

나는 이와 같은 문제가 문제를 해결하려고한다는 것을 알지만, "메타 박스에 무슨 일이 일어나는지"가 아니라 워드 프레스가 "제품"으로 향하고있는 질문에 더 가깝다고 생각합니다.

이러한 솔루션을 구축하는 중기 목표를 쉽게 파악할 수 있습니다.이를 프런트 엔드로 옮기는 것이 매우 쉬울 것입니다 (그리고 일부 경쟁 업체와 더 가까워 질 수도 있습니다).

개발자 / 비즈니스 / 기획 관점에서 'Gutenberg'의 (미래) 의도를 이해하는 것이 도움이 될 것입니다. 아니면 누군가가 그러한 사명 선언문이나 유사한 것을 알려줄 수 있습니까?

나로부터 더 많은 의견 ...

기존의 '지원'=> 기능 (제목, 편집자, 저자 등)은 매우 자명 한 이름을 가지고 있으며, 여기서는 구텐베르크가 프로젝트 이름으로 두드러집니다. 더 설명적인 기능 이름이 해당 용도로 고려되는지 궁금합니다. 아마도 "블록 편집기"? '지원'=> array ( 'block-editor')

동의합니다. 접근 방식이 합의되면 정렬 할 수있는 세부 사항처럼 들립니다 😄

물론 'supports'=> array ( 'title', 'editor', thumbnail ','block-editor ')와 같은 실수를 잡을 수있는 전략이 필요합니다. 'block-editor'플래그가 이전 '에디터'모드를 덮어 쓸 것이라고 가정합니다.

구텐베르크는 현재 포스트 유형 지원을 확장하는 것으로 볼 것입니다. 따라서 editor 지원이 없다면 Gutenburg는 제목 / 사이드 바 / 확장 옵션 만 표시 할 것입니다. 그렇다면 Gutenburg 지원은 지원 배열의 일부가 아닌 별도의 CPT 등록 인수로 더 잘 처리 될 수 있습니까?

모든 레거시 항목에 대해 하단에 "확장 설정"확장기를 사용하는 대신 메타 박스가 일반 및 고급 컨텍스트에있을 때 정확히 그와 같이 하단에있는 각 메타 박스에 대해 확장기를 만든 다음 측면 컨텍스트에 대한 측면 설정?

개인적으로이 아이디어가 마음에 듭니다.이 패널을 재정렬하고 현재 가능한 한 숨길 수 있다면 아이디어 솔루션이 될 수 있습니다.

아마도 페이지로드시 하나 (또는 ​​그 이상?) 또는 이것들을 열린 것으로 설정하는 방법이 있어야합니다. 특히 포스트 유형이 메인 편집기를 지원하지 않는 경우에 그렇습니다.

게시물을 작성하는 데 사용할 수 있지만 CPT가 이에 대한 지원을 추가 할 수 있다는 것도 언급되었습니다. 나는 그것이 실제로 작동하지 않을 것이라고 생각합니다. 뉴스 조직은 이러한 유형의 편집자를 좋아할뿐만 아니라 추가 콘텐츠, 일정, 임베드, 인포 그래픽 및 기타 필요한 데이터와 관련된 사용자 지정 워크 플로에 대한 요구 사항도 가지고 있습니다.

새로운 반응 기반 화면이 이전 편집 화면만큼 플러그 가능한 경우 이러한 사용자 정의 워크 플로를 페이지 상단 / 사이드 바 / 편집기 아래 또는 페이지의 다른 곳에 추가 할 수없는 이유가 없습니다. (면책 조항 : 저는 React에 대해 깊이 이해하지 못하므로 PHP 외부에 얼마나 복잡한 후크가 있는지 확인해야합니다). 또한 # 1352

여기서 혼란은 Gutenberg가 편집자를 블록 우선으로 재 구상하는 방식에 근본적인 차이가 있기 때문이라고 생각합니다. 즉, 우리는 메타 박스 추가에 대한 생각에서 벗어나 블록 추가에 대해 생각해야합니다. 이전에 메타 박스에 넣었을 필드는 이제 블록에 넣는 대신 앞으로 나아갈 것입니다.

사용자 정의 포스트 유형을 정의 할 때 필요한 블록과 단순히 허용되는 블록이 포함될 수 있습니다. editor 지원이없는 사용자 지정 게시물 유형의 경우 여전히 Gutenberg에 "편집기"가 표시되지만 기본적으로 _inserter_를 비활성화 할 수 있습니다. 에디터에 나타나는 블록은 포스트 유형에 필요한 것에 따라 제자리에 고정됩니다. 블록이 채워지지 않은 경우 _placeholders_로 표시됩니다. 이러한 블록은 현재 메타 박스와 마찬가지로 postmeta에 속성을 저장할 수 있지만 save_post 작업 및 $_POST 전역을 통해 임시 대신 정규화 된 방식으로 저장합니다.

따라서 여기서 최종 결과는 거의 동일 할 것이라고 생각합니다. 플러그인 작성자는 사용자 정의 필드를 넣을 수있는 "상자"를 계속 받게됩니다. 메타 박스 대신 블록으로 표시됩니다.

여기서 혼란은 Gutenberg가 편집자를 블록 우선으로 재 구상하는 방식에 근본적인 차이가 있기 때문이라고 생각합니다. 즉, 우리는 메타 박스 추가에 대한 생각에서 벗어나 블록 추가에 대해 생각해야합니다. 이전에 메타 박스에 넣었을 필드는 이제 블록에 넣는 대신 앞으로 나아갈 것입니다.

@westonruter 이것은 콘텐츠가 포함 된 메타 박스에 충분히 합리적으로 보이지만 많은 메타 박스는 포스트 콘텐츠에서 의미가없는 특정 포스트 메타를 서비스합니다.

설명을 해주신 @westonruter 에게 감사하지만 이것은 저에게 몇 가지 새로운 질문을 제기합니다.

데이터를 post_meta로 저장하는 블록은 지금까지 데모에서 본 것과 근본적으로 다른 유형의 블록처럼 보입니다. 이 데이터는 게시물 내용의 흐름에 중복 저장됩니까?

작성자가 게시물에 허용 가능한 수 이상의 블록을 추가하는 것을 막는 것이 있습니까? (하나만 의미가있을 때 여러 개의 post_meta 필드 추가)

메타 데이터에 대한 게이트웨이로 블록을 탐색하는 것에 대해 @westonruter 와 동의하는 경향이 있습니다. 하지만 제가 제안하는 것은 post_content에서 블록의 아이디어를 분리하는 것입니다. 사용자 지정 게시물 유형의 블록은 프런트 엔드의 post_content 에서 나오는 항목의 구성원이 될 필요는 없습니다. 다음은 현대 부족의 이벤트 캘린더 (내 해석) 플러그인을 사용한 예입니다.

이 상황에서 주요 콘텐츠는 자유 형식 콘텐츠 영역이 아니라 이벤트 세부 정보입니다. 플러그인은 사용자 정의 포스트 유형의 메타 데이터를 사용하여 자체 마크 업을 조합하고 post_content 는 페이지 하단에 인쇄되는 설명 텍스트 일뿐입니다. 이 때문에 이벤트 세부 정보 블록은 이동, 삭제 또는 실제로 콘텐츠 출력의 일부가되어서는 안됩니다. 그러나이 게시물 유형의 주요 콘텐츠를 나타내므로 먼저 표시되어야합니다.

WooCommerce는 하나 이상의 제품 정보 블록이 제품 게시물 유형의 설명 텍스트보다 우선해야하는 또 다른 예이지만 사용자가 직접 삽입해야하는 선택적 블록이 아니어야합니다.

블록에 대한 기본 개념은 게시물에 대한 적절한 사용자 인터페이스를 조립하는 것이며 해당 데이터가 프런트 엔드에 저장되거나 렌더링 될 위치를 반드시 암시하는 것은 아닙니다.

... 메타 박스 추가에 대한 생각에서 벗어나 블록 추가에 대해 생각해야합니다.

콘텐츠에는 의미가 있지만 많은 플러그인은 양식 또는 지불과 같은 비 콘텐츠에 대해 사용자 지정 게시물 유형을 사용합니다. 이러한 포스트 유형은 어떤 식 으로든 블로그 포스트와 비슷하지 않으며, 추상 메타 필드가 블록 편집기의 이점을 얻지 못합니다. 모든 구성이 블록에 의해 수행되도록 강제하면 플러그인 개발자가 의존하게 된 열린 캔버스, 즉 현재의 플러그인 생태계를 만든 동일한 열린 캔버스가 제거됩니다.

현재의 접근 방식은 지원 역할에 국한된 메타 박스와 함께 블록 우선적 인 것 같습니다. 블록은 많은 콘텐츠 중심 플러그인에 도움이되지만 추상 설정을 정의해야하는 필요성은 메타 상자가 제공하는 명백한 레이블과 친숙한 입력으로부터 여전히 이익을 얻습니다. 이러한 경우 개발자는 전체 캔버스를 자유롭게 사용할 수 있어야합니다.

@westonruter 내 사용자 지정 게시물 유형에 특정 추가 필드가 필요한 경우 해당 데이터를 블록에 입력해야한다는 것을 분명히

그렇다면 몇 가지 후속 질문이 있습니다.

1) 해당 블록을 기본값으로 설정할 수 있습니까? IE는 항상 해당 게시물 유형에 표시되었으며 제거 할 수 없습니다. 예를 들어, 플러그인이 이벤트를 생성하고 각 이벤트에 시작 및 종료 날짜가있는 경우 기본적으로 이벤트 사용자 지정 게시물 유형을 편집 할 때 시작 및 종료 날짜에 대한 블록이 필요하고 게시물 콘텐츠에 있습니까?

2) 해당 블록에서 데이터가 어떻게 저장됩니까? 내가 이해했듯이 블록의 데이터는 post_content에 HTML 주석으로 저장됩니다. 메타를 게시하기 위해 이러한 블록에서 데이터를 어떻게 얻을 수 있습니까? 예를 들어, 가상 이벤트 플러그인의 경우 시작 및 종료 날짜를 포스트 메타로 가져 와서 쿼리 할 수있는 방법은 무엇입니까?

3)이 모든 것이 메인 콘텐츠 편집기 방향으로 진행되고 맞춤 게시물 유형에 적용되는 이유는 무엇입니까? 특히 블로그 게시물 / 기사를 나타내지 않는 사용자 지정 게시물 유형과 관련하여이 디자인 방향을 뒷받침하는 사용자 테스트가 있습니까?

@kevinwhoffman 나는 여전히 블록에 대한 근본적인 충돌을 보지 못합니다. 추상 설정은 여전히 ​​콘텐츠로 간주 될 수 있지만 다른 종류입니다. 모두 데이터입니다. 모든 블록은 "콘텐츠"에서 시각적으로 표현할 필요가 없습니다. post_content 대신 postmeta에 데이터를 저장하는 "메타 블록"도 매우 많이있을 수 있다고 생각합니다. 편집중인 블록은 오늘날 메타 박스가 표시되는 방식과 유사한 제목 / 레이블을 갖도록 스타일을 지정할 수 있습니다.

@ Shelob9 예, 사용자 지정 게시물 유형에 추가 필드가 필요한 경우 블록으로 표시 될 것이라고 생각합니다. "제품"사용자 지정 게시물 유형이있는 경우 가격, 변형 등에 대한 필드가있는 단일 product-details 블록이있을 수 있습니다.

1. 그 블록을 기본값으로 만들 수 있습니까? IE는 항상 해당 게시물 유형에 표시되었으며 제거 할 수 없습니다. 예를 들어, 플러그인이 이벤트를 생성하고 각 이벤트에 시작 및 종료 날짜가있는 경우 기본적으로 이벤트 사용자 지정 게시물 유형을 편집 할 때 시작 및 종료 날짜에 대한 블록이 필요하고 게시물 콘텐츠에 있습니까?

네, 맞습니다. 사용자 지정 게시물 유형, 게시물 형식 및 페이지 템플릿은 모두 "잠긴"필수 블록 개념을 포함 할 수 있으며 제거하거나 재정렬 할 수 없습니다. 이에 대한 한 가지 예는 게시물 발췌 블록입니다. https://github.com/WordPress/gutenberg/issues/1288#issuecomment -310544967

1. 해당 블록에서 데이터가 어떻게 저장됩니까? 내가 이해했듯이 블록의 데이터는 post_content에 HTML 주석으로 저장됩니다. 메타를 게시하기 위해 이러한 블록에서 데이터를 어떻게 얻을 수 있습니까? 예를 들어, 가상 이벤트 플러그인의 경우 시작 및 종료 날짜를 포스트 메타로 가져 와서 쿼리 할 수있는 방법은 무엇입니까?

오늘날 대부분의 블록은 데이터를 post_content 안에 HTML로 저장하지만 반드시 그럴 필요는 없습니다. 예를 들어, https://github.com/WordPress/gutenberg/issues/1288 에서 post_excerpt 콘텐츠를 저장하는 발췌 블록과 postmeta에 콘텐츠를 저장하는 추천 이미지 블록에 대한 토론을 볼 수 있습니다. 따라서 postmeta에 저장되는 시작 및 종료 날짜가있는 event-details 블록을 확실히 가질 수 있어야합니다.

1. 이 모든 것이 기본 콘텐츠 편집기 방향으로 진행되고 사용자 지정 게시물 유형에 적용되는 이유는 무엇입니까? 특히 블로그 게시물 / 기사를 나타내지 않는 사용자 지정 게시물 유형과 관련하여이 디자인 방향을 뒷받침하는 사용자 테스트가 있습니까?

위의 내용에 따라 데이터는 post_content , postmeta, 용어 또는 기타 장소에서 소스 및 저장할 수 있습니다. "블록 우선"이라는 아이디어는 모든 것이 사용하는 공통 빌딩 _block_을 갖는 것이며 그렇게함으로써 블록 구성 요소는 WordPress에서 최대한 재사용 될 수 있습니다. 그것이 제 이해입니다.

@westonruter- 해명 해주셔서 감사합니다. 이 편집기가 블로그 게시물 / 기사 등이 아닌 게시물 유형과 어떻게 관련되는지에 대한 정보가 많지 않기 때문에 매우 유용합니다.

곧 "메타 블록"을 작성하는 방법에 대한 문서를 볼 수 있기를 바랍니다.

포스트 편집 경험을 통해 사용자에게 가르치는 내용과 이것이 사용자 지정 포스트 유형에 매핑되는 방식을 고려해야합니다.

블록 편집기에서 기본 게시물을 편집 할 때 사용자는 각 블록이 콘텐츠를 나타냄을 알게됩니다. 콘텐츠와 관련된 설정은 블록 편집기 외부에있는 패널 / 메타 상자에서 사용할 수 있습니다. 콘텐츠는 블록 안에 있습니다. 설정은 패널에 있습니다. 사용자가 블록 편집기에서 보는 것은 게시 될 때 페이지의 미리보기 여야한다고 다른 곳에서는 언급되었습니다.

그런 다음 사용자 지정 게시물 유형에 대한 블록 편집기의 설정과 콘텐츠를 결합하면 블록 편집기가 미리보기라는 생각이 깨집니다. 저는 우리가 블록 편집기가 가장 잘하는 일, 즉 콘텐츠를 편집하도록하고 개발자가 콘텐츠 블록과 동일한 요구 사항을 공유하지 않는 설정 인터페이스를 구축하도록 권한을 부여해야한다고 생각합니다.

나는 WooCommerce 및 EDD와 같은 메타 상자를 추가하는 광범위한 플러그인을 작업했습니다. 대부분의 경우 필요하지 않기 때문에 화면에서 콘텐츠 편집기를 제거했습니다. 나는 그것이 우리가 구텐베르크와 합병해야 할 것이 아니어야 할 것이 조금 걱정됩니다.
그렇지 않으면이 모든 것이 어디로 갈까요?

저는 @kevinwhoffman의 의견에 동의합니다. 블록이 메타를 나타내려면 사용자에게 이것이 포스트 콘텐츠와 다르며 출력에서 ​​예상되지 않아야한다는 시각적 신호가 필요합니다. 이를 해결하는 한 가지 방법은 구분선입니다. 이것은 본질적으로 콘텐츠가 현재 메타 박스에서 분리되는 방식을 재 해석 한 것입니다.

이것이 저에게 모든 문제를 해결하는 것은 아니지만, 메타 박스에 외관을 개선하는 흥미로운 방법이라고 생각하며 기존 플러그인과 상당히 역 호환 될 수 있지만 사용자에게는 일류 경험이 아닙니다.

다음은 메타 블록이 주요 콘텐츠이고 게시물 콘텐츠가 설명으로 사용되며 추가 메타 블록이있는 경우 사용자에게 알리려는 시도입니다.

@brentjett 모형에 감사드립니다. 콘텐츠와 설정을 분리해야한다는 점을 지적했듯이, Yoast와 같은 설정 상자를 처음부터 블록으로 지정해야하는 이점은 없습니다.

• 그것은 페이지의 내용을 나타내지 _ 아니다 _, 따라서 블록 편집기가 페이지 내용의 미리보기라는 생각을 깨뜨립니다.
• 여러 인스턴스가 필요하지 않습니다.
• 다른 콘텐츠 블록의 중간에 위치를 변경해도 이점이 _ 아닙니다 _.
• 기본적으로 페이지에 있어야합니다.

이러한 각 특성은 블록의 기본 동작에 반하여 실행됩니다. 물론 위치에 고정하고 기본적으로 표시 할 수있는 일회용 블록을 만들기위한 다양한 논의가 있습니다. 하지만 이미이 목적에 부합하는 메타 박스 구현을 개선하는 데 집중할 수 있는데 왜 블록을 메타 박스로 비틀어 야할까요?

나는 Yoast와 같은 설정 상자를 처음부터 블록으로 요구하는 이점을 보지 못했습니다.

잠시 여기로 돌아 갑시다. 두가지. 하나는 PHP로 작성된 오래된 메타 박스에 대한 지원으로,이 게시물에서 "확장 설정"드로어를 모방했습니다.

다른 한 가지는 질문에 대한 답입니다. 우리가 이것을 처음부터 다시 설계하고 싶다면 오늘날 어떤 모습일까요?

여기에서 _blocks_를 여러 이질적인 인터페이스를 통합 할 수있는 새로운 인터페이스로 제안하고 있습니다. 우리는 이미 블록이 단축 코드, 사용자 정의 HTML, 위젯 및 임베딩을위한 어포던스보다 우수 할 수 있다고 제안하고 있습니다. 메타 박스가 수행하는 작업에 따라이 인터페이스도 포함 할 수없는 이유가 없습니다.

동의합니다. 그리고 Yoast에 대해 잠시 이야기하면서, 우리는 새로운 편집기 주변의 많은 장소에 통합하여 구텐베르크가 우리의 오래된 메타 박스를 에뮬레이트하기 위해 하나의 큰 블록을 구축하는 대신 목표로 삼고있는 경험을 향상시킬 계획이지만 위에서 언급 한 다른 예가 있습니다. 블록으로도 작동한다고 생각합니다. 예, 약간의 작업이 필요하지만이 편집기가 좀 더 많은 관심을 끌면 워드 프레스 사용자를 흥분시킬 것이라는 것이 밝혀지면 우리가 어떻게 통합할지 다시 생각할 수있는 흥미로운 기회이며 결과적으로 우리 제품이 더 좋아질 것이라고 생각합니다.

따라서 두 가지 _legacy_ 기능적 사례가 있습니다.
메타 데이터를 처리 한 MetaBoxes (Yoast와 같은)와 구조화 된 인터페이스를 제공하는 데 사용 된 MetaBoxes가 있습니다 (WooCommerce와 같은).

미래를위한 개발
빈 상태에서 시작했다면 ( "과거로의 부채 취소") 메타 데이터를 제안 된 "고급"서랍에 넣는 것이 효과적 일 수 있다는 것은 사실입니다. 또한 구조화 된 콘텐츠 항목은 구텐베르크 내의 잠긴 블록 순서 인터페이스에 맞을 수 있습니다. 둘 다 전적으로 가설이지만 잠재적으로 향후 WP CMS 개발을위한 구현으로 작동 할 것입니다.

레거시 비즈니스 CMS 문제
제 업무의 99 %는 고객 회사에 직접 맞춤형 비즈니스 솔루션을 제공하는 것입니다. 그래서 내 관심은 내가 미래에 구축 할 수있는 위대한 것이 아니라 내 클라이언트 사이트 기능과 비즈니스 관계에 대한 냉정한 사실입니다. 기존 CMS 솔루션 기반 비즈니스를 Gutenberg로 마이그레이션하기 위해 어떤 제안이 있습니까? 제 상황에서 각 클라이언트는 설정된 WP 프레임 워크에 구축 된 서로 다른 맞춤형 CMS 솔루션을 가지고 있습니다. 저에게 "과거에 대한 빚을 취소하는 것"= "목욕물로 아기를 내 던지기"라는 문구가 있습니다.

우려
구텐베르크가 WP5.0의 핵심으로 제공되면 내 클라이언트가 작동하지 않는 사이트를 가질 것으로 예상합니다. 그런 다음 각 사이트를 다시 만들고 각 클라이언트를 수정해야합니다. 약 40 명의 클라이언트가 그 주에 CMS를 수리하기를 원할 수 있습니다.

• 레거시 CMS 메타 박스 의존 사이트와 그 사용자 기반이 핵심 팀에 필수적이지 않은 것처럼 보입니다.
• "고급"추첨 제안 # 952가 우선 순위가 낮아 전체 영역에 대한 관심이 부족함을 나타냅니다.
• "과거에 대한 부채"/ CMS 문제를 해결하기위한 제안 된 방법이 없습니다.

여기에서 우리가 블록을 제안하는 곳은 많은 이질적인 것들을 통합 할 수있는 새로운 인터페이스입니다. 우리는 이미 블록이 단축 코드, 사용자 정의 HTML, 위젯 및 임베딩을위한 어포던스보다 우수 할 수 있다고 제안하고 있습니다.

블록은 단축 코드, 사용자 정의 HTML, 위젯, 임베드와 같은 모든 것에 대해 의미가 있습니다. 페이지에 표시되는 모든 형태의 콘텐츠입니다. 동의합니다. 모두 차단합니다.

설정은 그런 것이 아닙니다. 설정에는 블록의 기본 동작과 겹치지 않는 고유 한 요구 사항 이 있습니다. 대부분의 경우 이러한 설정 상자는 게시물의 프런트 엔드 프레젠테이션과 관련이없는 게시물 메타를 저장합니다. 게시물이 표시 될 때마다 콘텐츠와 함께 비 콘텐츠를 구문 분석하는 것은 불필요 해 보입니다.

고려해야 할 또 다른 사항은 사용자가 텍스트 모드로 전환 할 때 발생하는 일입니다. 게시물 내용 옆에 설정 상자를 나타내는 HTML 주석이 많이 표시됩니까? 사용자가 이러한 익숙하지 않은 것을 삭제합니까?

블록을 콘텐츠로, 설정을 별도의 UI 구성 요소로 처리하여이 모든 것을 단순화 할 수 있습니다. 레거시 메타 박스 ( @steveangstrom이 지적한 큰 문제)를

@steveangstrom Concerns 섹션은 아직 답변되지 않은 우려 사항을 요약 한 것입니다.

이것은 미래에 무엇이 가능할 것인지에 대한 훌륭한 토론이며 모든 것이 훌륭하게 들립니다. WordPress가 정말로 필요하기 때문입니다. 저에게는 큰 문제가 아닌 플러그인 개발자로서 한두 블록을 만들고 잘할 것입니다. 그러나 이전 버전과의 호환성을 기대하면서 Steve의 고객과 고객에게 판매 된 수백만 개의 웹 사이트는 어떻게됩니까?

업데이트로 인해 웹 사이트가 중단 될 수있는 많은 고객도 있기 때문에 이러한 우려를 이해합니다. 나로부터 몇 가지 생각 :

콘텐츠 관리를 위해 ACF를 광범위하게 사용합니다. 예를 들어, 포스트 또는 리피터에 여러 개의 tinymce 편집자가있을 수 있습니다. 목표가 tinymce를 교체하는 것이라면 어떻게 여러 개의 "블록 컨테이너"를 사용할 수 있을까요? 지금 당장은 "블록 컨테이너"가 하나뿐이라는 것을 정확히 이해합니다. 그렇죠?

포스트 편집 흐름에 맞지 않는 또 다른 ACF 기능은 옵션 페이지입니다. 옵션 페이지에서 이것이 어떻게 작동하는지 정말 모르겠습니다.

이전 버전과의 호환성을 원하는 사람들을 위해-누군가 gutenberg로 업데이트 할 시간 / 자원이 없다면 현재 편집 경험을 복원하기 위해 플러그인을 만들 것입니다 (이는 제가 사용할 계획입니다). 또한 5.0은 주요 버전 범프가 될 것입니다. 즉, 최소한 semver 표준에 따라 주요 변경 사항이 괜찮습니다.

WordPress는 semver를 따르지 않습니다.

@westonruter 나는 이것이 의미가 있다고 생각합니다.

이전에 메타 박스에 넣었을 필드는 이제 블록에 넣는 대신 앞으로 나아갈 것입니다.

하지만 어떻게 거기 (메타 박스)에서 여기 (블록)로 이동합니까? 코드 (구텐베르크에 대해 아직 업데이트되지 않은 플러그인)에 대한 백컴 패트와 데이터에 대한 백컴 패트 (플러그인이 업데이트되면 새 콘텐츠 블록에 기존 메타 박스 데이터를 어떻게 표시합니까?) 범위 문제?).

하지만 어떻게 거기 (메타 박스)에서 여기 (블록)로 이동합니까? 코드 (구텐베르크에 대해 아직 업데이트되지 않은 플러그인)에 대한 백컴 패트와 데이터에 대한 백컴 패트 (플러그인이 업데이트되면 새 콘텐츠 블록에 기존 메타 박스 데이터를 어떻게 표시합니까?) 범위 문제?).

이것들은 좋은 질문입니다. 이러한 기능을 구현하면서 답을 모색 할 것입니다.

여기서 끝날 곳을 추측해야한다면 현재 메타 박스는 "레거시"영역으로 이동하고 "새로운 스타일"메타 박스 블록 사물을 등록하기위한 API, 문서 및 예제를 제공 할 것입니다.

@nylen 현재 메타 박스의 _rendering_은 어떻습니까?

메타 박스가 우선 순위를두고 있다는 것은 희소식이지만, 오래된 메타 박스를 서랍에 넣거나 "레거시"영역에 한정하는 것 이상의 해결책을 고려해야합니다.

오늘날에는 Advanced Custom Fields와 같은 플러그인을 통해 주로 메타 박스로 구축 된 수많은 사이트가 존재합니다. 여기서는 게시물 하단에있는 하나 또는 두 개의 상자가 아니라 전체 화면 인터페이스에 대해 이야기하고 있습니다. ACF가 Gutenberg와 함께 작동하도록 업데이트 될 것이라고 확신하지만 이러한 사이트는 다시 빌드되지 않습니다.

그래서 질문은 남아 있습니다. 편집기가없고 완전히 메타 상자로 구성된 인터페이스는 어떻게됩니까?

그래서 질문은 남아 있습니다. 편집기가없고 완전히 메타 상자로 구성된 인터페이스는 어떻게됩니까?

여기서 아이디어는 @mtias 가 틀렸다면 저를

이 편집기를 전체 화면 / 산만없는 편집기처럼 작동하게 만드는 것은 어떻습니까?

+1. 이것은 메타 상자가있는 현재 편집기에 전혀 영향을주지 않으므로 좋은 생각입니다. 산만하지 않은 편집기가 오랫동안 거기에 있었지만 많이 사용되지 않았습니다. 구텐베르크 편집자는 편집자 화면을 다시 작성하는 대신 이것을 가져와 개선 할 수 있습니다.

또한 register_post_type 때 supports 매개 변수로 Gutenberg 편집기에 대한 지원을 등록하면 더 좋을 것입니다.

마지막으로, 메타 박스 개발자로서 메타 박스가 새 편집기에서 작동하도록 만드는 새로운 API를보고 싶습니다. 여기에서 볼 수 있듯이 많은 개발자는 게시물에 대한 추가 콘텐츠를 제공하는 방법으로 메타 상자를 사용합니다. 이러한 콘텐츠는 분류하여 나중에 검색 할 수 있습니다. 게시물 콘텐츠로서의 단순한 콘텐츠 블록이 아닙니다. 따라서 add_meta_box() 함수에 대한 새로운 대체가있는 경우 Meta Box 플러그인을 리팩터링하여 작업 할 수 있습니다.

다시 말한 모든 것에 동의합니다 : 표준 메타 박스가 여전히 작동하고 자리를 잡도록 만드는 것입니다. CMB2의 수석 개발자로서 WordPress 5.0이 출시 될 때 CMB2가 어떻게 든 손상되면 상당히 큰 호소가있을 것이라고 장담 할 수 있습니다. 나는 이것이 위협이 아니라 단순히 현실을 의미합니다.

구텐베르크가 도입 한 데이터 모델을 사용하기 위해 ACF, Pod 및 CMB2를 더 많이 업데이트할수록이 전환이 더 쉬워 질 것이라고 생각합니다.

확실히 장기적으로이 작업을 수행 할 예정이지만, 구텐베르크가 출시 될 때까지 메타 박스 라이브러리가이 작업을 수행 할 것이라는 기대가 확실하지 않습니다. (그렇다고 기대하지 않을 수 있음)

I can guarantee there will be a pretty significant outcry if CMB2 is somehow broken when WordPress 5.0 is released

그리고 업데이트하더라도 이전 설치가 손상됩니다.

ACF의 필드 그룹은 메타 박스에있을 필요는 없지만 'Side', 'normal-after content'및 'high-제목과 편집기 사이에 옵션이있는'Seamless (no metabox) '스타일도 있습니다. (!!!) '. 의미있는 편집 흐름을 만드는 데 중요한 마지막 항목입니다.

아무도 비용을 지불하지 않기 때문에 업데이트되지 않는 중요한 개별 개발이 많이 있음을 명심하십시오. 이러한 구현을 깨는 것은 기업 환경에서 WP의 궁극적 인 킬러가 될 것입니다.

@ wsydney76 또한 ACF의 필드 그룹이 메타 박스에있을 필요는 없지만 'Side', 'normal-after content'및 'high-between title'옵션이있는 'Seamless (no metabox)'스타일도 있습니다. 및 편집자 (!!!) '. 의미있는 편집 흐름을 만드는 데 중요한 마지막 항목입니다.

이것은 WordPress에서 "그냥 작동하는"것이 아니라 일반적인 메타 박스 UI를 제거하기 위해 사용자 정의 플러그인 코드가 필요하다는 점에 주목할 가치가 있습니다. 따라서 Gutenburg와 함께 작동하려면 ACF에서 추가 작업이 필요하다고 가정하는 것이 합리적입니다.

간단하게. 사용자 정의 포스트 유형이 편집자 (Gutenberg)를 지원하지 않는 경우, 상상력, CSS 기술 및 가장 재능있는 핵심 디자이너를 사용하여 전체 편집자를 다른 것으로 변환하십시오. (네이티브) 포스트 편집 화면에서 클라이언트 / 사용자가 볼 수없는 것으로 보이게합니다. 외모에 관한 것입니다. 클라이언트는 구텐베르크가 백그라운드에서 작동하는지 여부에 신경 쓰지 않으며 웹 개발자가 그것에 대해 이야기하더라도 덜 신경을 쓸 수 없습니다. 그들은 시각적 유형의 사람들입니다.

이전 버전과의 호환성과 관련하여 구텐베르크가 5.0을 기록하기 훨씬 전인 2 월에 WordPress의 장기 지원 버전을 제안했습니다.

그 시점에서 그것은 불가능한 작업처럼 보였지만 이제는 4.9를 LTS 버전으로 만들고 4.9 이전 지원을 중단하고 5.0에 집중하는 것에 대해 논의하는 것이 훨씬 더 중요합니다.

게시물은 여기에서 찾을 수 있습니다.
https://khromov.se/wordpress-needs-another-long-term-support-version/

10 년 이상 워드 프레스 개발자. 많은 사람들이 지적했듯이이 개발 은 콘텐츠에 적합합니다. 맞춤 마크 업이있는 동적 콘텐츠 블록을위한 정말 필요한 표준 솔루션입니다. 그러나 이것은 콘텐츠에서 조종하고 WordPress를 프레임 워크에 더 가깝게 만드는 방식으로 게시물 유형의 사용을 제한합니다.

예를 들어, 필자는 게시물 유형에 대한 필드를 생성 할 수있을뿐만 아니라 (다른 많은 유형과 마찬가지로) 이들 간의 관계 (예 : 일대일, 일대 다 등)를 생성 할 수있는 플러그인 제품군을 구축했습니다. 이것은 (더 많은 기능과 함께) 포스트 유형을 Laravel 또는 Rails와 같은 프레임 워크의 모델에 매우 가까운 것으로 변환 한 다음 DSL을 사용하여 해당 포스트, 데이터 및 관계 작업을 수행합니다.

이러한 유형의 사용은 드물지 않으며 WordPress 자체는 개발자가 게시 유형을 공개하지 않음으로 선언 할 수 있도록하여 게시 유형의 창의적인 사용을 장려했습니다. 'public', 'publicly_queryable'및 'show_ui'와 같은 플래그는 모두 개발자가 웹 사이트의 공개 페이지와의 단순한 1 : 1 미러 관계 이외의 목적으로 게시물 유형을 사용할 수 있도록합니다.

구텐베르크가 그 비전에 어떻게 부합합니까?

이 편집기를 선택 사항으로 유지하는 것 외에 다른 해결책은 보이지 않습니다. 즉, 여전히 TinyMCE를 대체해야하지만 TinyMCE가 지금 선택 사항 인 것처럼 편집기는 선택 사항으로 유지되어야합니다.

에디터를 지원하지 않는 포스트 유형을 계속 만들 수 있고 해당 포스트 유형에서 메타 박스를 계속 사용할 수 있다면 훨씬 더 빨리 합의에 도달 할 수있을 것입니다.

테마 및 플러그인 개발자의 새 편집기 채택은 이러한 유형의 접근 방식으로 느려질 수 있지만 솔직히 새로운 프로젝트를 시작할 수있는 4.9 LTS 도로로가는 것을 의미하지 않는 다른 방법을 보지 못합니다. WP 5.0 및 레거시 프로젝트와 함께 4.9 LTS를 유지합니다.

업데이트 : 내가이 주석을 썼을 때 스레드의 제목이 달랐고 메타 박스를 폐기 할 가능성이 논의되고있었습니다 (즉, 핵심 팀은 아직 아래 주석 에서처럼 확고한 "아니오"로이 질문에 명확하게 응답하지 않았습니다). 이러한 시나리오에서 구텐베르크는 단순히 동적 블록을 지원하고 메타 박스에 대한 다른 많은 사용 사례를 무시했을 것이므로 위의 설명입니다.

모든 사람의 댓글을 읽는 데 시간을 투자 한 결과 편집 화면의 이러한 진화의 결과는이 js 기반 편집 화면 내에서 작동하는 새로운 메타 박스 API를 제공하는 것 같습니다. 즉, 위에서 언급했듯이 창의적인 방법으로 게시물을 사용하는 기능을 실제로 잃지 않지만 단순히 새 API를 가져와 UI가 js 기반이됩니다.

WordPress REST API 및 GatsbyJS를 사용하여 React 기반 앱을 빌드하기 위해 Pod 2.7 을 사용할 계획입니다.
Gutenberg는 Pod와 호환됩니까?

이 중요한 문제가 이정표에서 제거 된 것으로 보입니다. 블로그 편집을위한 종소리와 휘파람이 많은 작업을 수행하고 베타에 추가되는 동안 우선 순위가 _ 다시 제거되었습니다. 이것은 CMS로서의 Wordpress의 미래에 대해 매우 걱정 스럽습니다.

저는 GenerateWP에서 영감을받은 제 코드 생성기를 만들었습니다. public이 아닌 localhost에서 나 자신과 개인적인 용도로 사용하십시오.
어쨌든 전환이 완료되면 구텐베르크에서 어떻게 보일지 궁금합니다. ACF 필드, 미리보기를위한 많은 사용자 지정 PHP 코드.

우리는이 문제에 대해 잊지 않았습니다. 오히려 에디터가 잘 작동하도록하기위한 많은 다른 우선 순위와 함께 우리가 이제 막 조사하기 시작한 것은 매우 복잡한 문제입니다.

메타 박스를 연결할 때 직면하게 될 몇 가지 어려움은 기술적 인 관점에서 다음 단계에 대한 정보가 포함 된 # 2251을 읽어 보면 분명해질 수 있습니다.

여기서 강조하고 싶은 것은이 구현을 계획하고 테스트하기 위해 커뮤니티의 도움이 필요 하다는

살펴볼 플러그인 목록의 시작점은 다음과 같습니다.

Plugin                                      Active installs
======                                      ===============
advanced-custom-fields                           1,000,000+
custom-post-type-ui                                400,000+
meta-box                                           200,000+
types                                              200,000+
cmb2                                               100,000+
pods                                                50,000+
custom-field-suite                                  40,000+
wck-custom-fields-and-custom-post-types-creator     20,000+
piklist                                             10,000+
carbon-fields                                        2,000+

위에 나타나지 않는 플러그인은 WP.org 플러그인 디렉토리에 없기 때문일 가능성이 높습니다.

• Fieldmanager

유사한 작업을 수행하는 널리 사용되는 다른 플러그인에 대해 알고있는 경우이 문제에서 여기에 알려주십시오.

이러한 플러그인 중 하나의 개발자이거나 이러한 플러그인이 메타 박스를 추가하고 관련 스크립트 또는 스타일 시트를 대기열에 추가하는 데 사용 하는 WordPress 후크 에 대한 세부 정보를 제공 할 수있는 경우이 문제에서 여기에 알려주거나 새 위 목록의 각 특정 플러그인에 대한 문제. 이 정보는 수집하는 데 시간이 많이 걸리며 모든 정보를 한 곳에 모으기위한 추가 개발 노력에 큰 도움이 될 것입니다. 예를 들면 :

고급 사용자 정의 필드는 admin_enqueue_scripts 후크를 등록하여 메타 박스를 추가합니다. 이 후크는 현재 페이지로드가 post.php 또는 post-new.php 인지 확인하고, 그렇다면 add_meta_box 를 호출하는 admin_head 작업을 추가합니다. WP 코어는 해당 작업 직후 edit-form-advanced.php 에서 do_meta_boxes 호출을 수행합니다.

마지막으로, WordPress가 현재 메타 박스를 렌더링하고 저장하는 방식에 익숙한 개발자라면 여기 및 / 또는 # 2251에 대한 입력에 감사드립니다 .

안녕하세요 여러분,
여기 Elliot-ACF dev.

ACF는 admin_enqueue_scripts 작업을 사용하여 "필드 그룹 일치 논리"를 수행 한 다음 admin_head 작업을 사용하여 메타 박스를 추가합니다 ( add_meta_box() ). add_meta_boxes 작업을 사용하지 않습니다.

여기서 분명한 질문을해도 될까요? 메타 박스의 '어려움'에 대해 논의하는 이유는 무엇입니까? 이들은 모든 WP 웹 사이트의 필수 부분입니다. 확실히 메타 박스 로직은 그대로 유지하고 새로운 Gutenberg 편집기 영역과 함께 사용할 수 있습니다.

@woocommerce 에도 태그를 지정하십시오. 가장 큰 메타 박스 플러그인 일 가능성이 큽니다.

감사
이자형

안녕하세요 여러분-

나는 아직도 몇 가지 생각과 아이디어를 공식화하고 있지만이 토론이 너무 집중되고있는 것 같아서 빠른 질문을 던지고 싶었습니다.

메타 상자에 필드를 추가하는 것에 대해서만 이야기하는 이유는 무엇입니까? 현재 시스템에서는 무엇이든 추가 할 수 있습니다. 데이터, 타사 API를 사용하여 도구를 사용하기위한 자바 스크립트, 메모 또는 도움말 정보의 빠른 표시, 사람들에게 하이 파이브를주는 귀여운 새끼 고양이 사진 (좋아요, 이건 아니지만 누가 옳은지 아세요?!).

여기서 제가하려는 요점은 메타 박스가 필드를 포함하지만 이에 국한되지 않는 다양한 것을 담을 수있는 범용 컨테이너라는 것입니다. 지금은 PHP로이 작업을 수행하는 것이 매우 쉽습니다.하지만 현재 사람들에게 텍스트를 던지기 위해 React Component를 작성하는 방법을 알도록 요청하고 있습니까?

내가 말했듯이 대화의 맥락을 추가하려고합니다.

감사,

Kevin-Piklist의 수석 개발자

이 질문은 위의 많은 의견에서 언급되었지만 내가 아는 한 답변되지 않았습니다.

메타 상자 및 기존 후크를 포함한 나머지 인터페이스는 변경하지 않고 그대로두고 기존 TinyMCE 포스트 편집기를 Gutenberg로 대체 할 수 있습니까?

이렇게 좁혀진 ​​범위를 사용하면 게시물 유형을 등록 할 때 editor 지원을 정의하여 Gutenberg를 사용자 지정 게시물 유형에 포함하거나 제외 할 수 있습니다.

• editor 지원이 등록되면 Gutenberg가 편집 화면에 표시되고 기존 메타 상자가 현재 편집기에서 작동하는 것처럼 계속 작동합니다.
• editor 지원이 등록되지 않은 경우 Gutenberg가로드되지 않고 빈 캔버스를 현재와 같이 메타 상자에 사용할 수 있습니다.

이 접근 방식은 기존 메타 박스 구현과의 역 호환성이라는 엄청난 도전을 피하는 동시에 최고의 편집기를 만들기 위해 리소스를 확보하는 것으로 보입니다.

여기서 분명한 질문을해도 될까요? 메타 박스의 '어려움'에 대해 논의하는 이유는 무엇입니까?

@elliotcondon- 개발 문제를 해결하기 어려운 경우 해결책에 도달하는 유일한 방법은 어려움을 극복하는 것입니다. 저는이 작업을 # 2251에서 시작했지만 거기에서 설명했듯이 빠른 작업이나 쉬운 수정이 아닙니다.

ACF가 메타 박스를 등록하는 방법에 대해 수집 한 정보를 확인해 주셔서 감사합니다. 구체적으로 ACF와 관련된 구현을 좀 더 진행하기 위해 다음 사항을 알아두면 도움이 될 것입니다.

• ACF 메타 박스의 기능을 제어하기 위해 대기열에 추가되는 스크립트 및 스타일 시트
• 대기열에 추가하는 작업은 무엇입니까?
• 대기열에 넣을지 여부를 제어하는 ​​모든 조건.

메타 상자에 필드를 추가하는 것에 대해서만 이야기하는 이유는 무엇입니까?

저는 구텐베르크 코드가 메타 박스가 실제로하는 일을별로 신경 쓸 필요가없는 곳으로 가고 싶습니다.

그 목표를 향해 @kevinpmiller ,

• 메타 박스를 등록하기 위해 add_meta_box 를 호출하는 작업은 무엇입니까?
• 등록 여부를 제어하는 ​​모든 조건 (예 : 현재 화면은 post.php 또는 post-new.php )

이번 호에서는 기존 PHP 메타 박스가 Gutenberg 인터페이스와 함께 작동하도록하는 데 초점을 맞추도록하겠습니다.

지금은 PHP로이 작업을 수행하는 것이 매우 쉽습니다.하지만 현재 사람들에게 텍스트를 던지기 위해 React Component를 작성하는 방법을 알도록 요청하고 있습니까?

예, "새로운 스타일"메타 박스를 만들기위한 API 세트를 만들어야합니다. 다음은 오늘 우리가 블록에 대해 가지고있는 것입니다. 메타 박스는 post_content 이외의 다른 곳에 저장할 수있는 "블록"으로 등록되어있어 매우 유사 할 것으로 예상합니다. : http://gutenberg-devdoc.surge.sh/

새로운 스타일의 메타 박스에 대한 논의는 # 1684 또는 기술 API를 제안하는 별도의 문제에서 이루어져야합니다.

editor 지원이 등록되지 않은 경우 Gutenberg가로드되지 않고 빈 캔버스를 메타 상자에 현재와 같이 사용할 수 있습니다.

@kevinwhoffman- 오늘 작성된 Gutenberg는 post_content 편집자가 될 예정입니다. 따라서 editor 지원이 활성화되지 않은 경우 적어도 지금은 비활성화하는 것이 당연합니다. 이것은 또한 코드 관점에서 매우 쉬운 작업입니다. 이것에 대한 새로운 이슈를 생성 할 수 있습니까? Good First Task 라벨로 태그를 지정하겠습니다.

오늘 작성된 Gutenberg는 post_content 편집자가 될 예정입니다.

@nylen 구텐베르크가 진정으로 post_content 편집기가 될 계획이라면 메타 상자는 post_content 와 관련이 없으므로 그대로 두어야합니다.

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

# 2251에서 이러한 API를 작성하는 데 따르는 엄청난 과제를 설명했습니다. ACF와 같은 인기있는 사용자 정의 필드 솔루션을 위해 PHP 메타 상자를 React로 번역하는 것은 현재 존재하는 모든 메타 상자 구현에 대해 그렇게하려는 시도는 말할 것도없고, 인기가 있든 없든 충분히 도전적입니다. 확장되지 않습니다.

@kevinwhoffman- 아주 잘 말했습니다. 이것은 내가 말한 다른 많은 개발자들뿐만 아니라 나의 정확한 생각을 반영합니다.

이 문제를 주제에서 꺼내고 싶지는 않지만 새 JS 페이지 빌더를 도입 할 때 '메타 박스'문제가 필요한 이유를 이해할 수 없습니다. 이것이 내가 말할 때 의미하는 바입니다.

메타 박스의 '어려움'에 대해 논의하는 이유

나는 그것을 읽을 수있어서 기쁩니다 :

편집기 지원이 등록되지 않은 경우 Gutenberg가로드되지 않고 현재와 같이 메타 상자에서 빈 캔버스를 사용할 수 있습니다.

위의 내용이 참이면 모든 wp-admin 로직 (액션, 기능 등)이 게시물의 편집 화면에 대해 동일하게 유지되어야합니다. 따라서 메타 박스 HTML이 수년 동안 그랬던 것처럼 렌더링 될 수없는 이유가 없어야합니다.

@nylen
ACF는 몇 가지 JS 및 CSS 파일을 대기열에 추가하여 ACF 메타 박스 HTML 요소의 스타일을 지정하고 상호 작용합니다.
ACF는 'admin_enqueue_scripts'작업을 사용하여 이러한 자산을 추가합니다.
다른 많은 플러그인과 테마가 스타일 / 스크립트를 대기열에 추가합니다. 이것이 문제가되는 이유는 무엇입니까?
ACF는 메타 데이터를 저장하기 위해 JS를 사용하지 않습니다. save_post 작업을 사용하여 $_POST 데이터를 저장합니다.

또한 PHP 메타 상자를 React 메타 상자로 변환하는 API의 필요성은 제조 된 문제입니다.

이것은 우리가하는 일이 아닙니다. 더 이상 기존의 post.php 로드 프로세스를 사용하지 않기 때문에 필요한 것을 선택해야합니다.

편집기 지원이 등록되지 않은 경우 Gutenberg가로드되지 않고 현재와 같이 메타 상자에서 빈 캔버스를 사용할 수 있습니다.

명확히하기 위해 : 현재는 그렇지 않지만 PR에서 탐색하는 것이 합리적 일 것입니다. 오늘이 작업에 관심이 있으시면 도움을 주시면 훨씬 더 빨리 진행될 것입니다.

@kevinwhoffman @elliotcondon @nylen 또는 더 좋은 방법은 다음과 같습니다.

• block-editor 지원이 등록 된 경우 Gutenberg를 사용하십시오.
• editor 지원이 등록 된 경우 TinyMCE를 사용하십시오.
• 지원이 등록되지 않은 경우 Gutenberg 또는 TinyMCE가로드되지 않습니다.

나는 구텐베르크의 유무에 따라 WP 관리자 경험을 파쇄하는 것을 선호하지 않습니다.

Gutenberg = New React Meta Boxes 및 No Gutenberg = Old PHP Meta Boxes이면 분리 된 관리자가 우리가 향하는 방향입니다.

메타 상자는 편집기가 있는지 여부에 관계없이 모든 곳에서 동일하게 작동해야합니다.

예 : 별 5 개로 게시물을 평가하는 메타 상자를 추가하는 플러그인이 있다고 가정 해 보겠습니다. 플러그인은 모든 게시물 유형을 평가할 수 있도록 빌드되었습니다. 게시물 유형이 편집기를 사용하는지 여부에 따라 해당 메타 상자의 내부가 변경되어야하는 이유는 무엇입니까?

안녕하세요.

나는 구텐베르크의 유무에 따라 WP 관리자 경험을 파쇄하는 것을 선호하지 않습니다.

block-editor 에 대한 내 제안에 대한 응답 이었습니까?

BTW, 내 제안이 경험을 파쇄하는 것으로 보지는 않지만 WordPress 구성에 존재하는 경우 기존 메타 상자를 포함하라는 제안을 기반으로하는 것으로 생각합니다.

@mikeschinkel 구텐베르크를 활성화 또는 비활성화하는 기능이 필요하지만 메타 박스 동작을 결정하는 구텐베르크의 아이디어는 제가 반대하는 것입니다. 그것들은 별개의 문제입니다.

@kevinwhoffman 나는 당신과 동의합니다, btw.

포드에서 우리는 ACF 및 CMB2와 동일한 작업을 사용하여 정상적이고 문서화 된 표준 작업을 수행합니다. 우리는 지금 당장 권장되는 방식으로 거의 모든 작업을 수행하고 있습니다.

구텐베르크와 함께 메타 상자를 계속 사용할 수있는 능력에 +1하면 궁극적으로 사람들은 콘텐츠에 직접 속하는 항목에 구텐베르크를 사용할 수 있으며 다른 모든 항목에는 여전히 "게시물에 대한 속성 및 추가 정보 에 대해 좋아하는 메타 상자가 있습니다." "(모든 유형).

-1 React에서 모든 것을 다시 작성해야한다는 점, 적어도 모두가 React 메서드에 익숙해 질 시간이 있고 메타 박스 구현을 위해 더 많은 것을 지원할 때까지 둘 다 지원합니다. PHP 메타 박스를 단계적으로 제거하고 백컴 패팅을 위해 유지하고 해당 영역에서 React 메타 박스 문서와 개발자 기술이 향상됨에 따라 플러그인을 마이그레이션해야하는시기가 없다고 생각합니다.

이 티켓에 대한 토론과 여기에 걸친 공개 및 비공개 대화에 이어 여기에 답해야 할 중요한 질문이 하나 있다고 생각합니다.

WordPress에서 Metabox API를 공식적으로 사용하지 않을 계획입니까?

대답이 ' 아니요' 라면 전체 "이리저리 움직여서 약간 절름발이합시다"라는 말은 비스타 터가 아닙니다. API가 WordPress 코어의 하위 호환성 표준을 계속 지원하는 경우 기존 메타 박스 구현이 제대로 작동 할 것으로 기대합니다. 워드 프레스의 경우처럼

대답이 ' 예'인 경우 이는 엄청난 하위 호환성 정책 변경이며 전체적으로 WordPress 개발의 시대가 끝난 것입니다. 구텐베르크에서 메타 박스를 "해결"할 필요가 없습니다. 특정 방식으로 수행되고 특정 수준의 하위 호환성 기대치를 제공하는 WordPress 핵심 개발의 수년에 걸친 기간이 끝났음을 확인하려면 엄청난 재교육과 설명이 필요합니다.

불행히도 현재의 대답은 예라고 말하지 않을 것 같지만, 물건을 부수려고하고, 아니오 인 척합니다 . 개인적으로 저는 주요 핵심 기능에 대해 매우 비정형적인 접근 방식을 발견했으며 이러한 방식으로 수행되고 있다는 것은 매우 불안합니다.

포스트 편집 화면은 베어 본 블로그를 넘어서는 모든 프로젝트에서 가장 사용자 정의 된 화면입니다.

이러한 사용자 지정은 메타 박스 등록에만 국한되지 않습니다. 편집 관리자 화면이 제공하는 모든 후크는 동일한 프로젝트에서 사용 중입니다. 그리고 후크가없는 경우 개발자는 jQuery를 사용하여 UI 요소를 페이지에 삽입합니다.

따라서 이러한 사용자 지정을 위해서는 앞으로 나아갈 방법이 있어야합니다.

메타 박스의 경우 Fieldmanager는 VIP 승인을 받았기 때문에 선택하는 도구입니다. Fieldmanager는 강력하지만 제한된 필드 세트에 중점을 둡니다. 레거시 코드베이스는 종종 Fieldmanager 또는 다른 유틸리티 라이브러리를 사용하도록 개조 할 수 없습니다.

따라서 많은 메타 박스가 여전히 사용자 지정 코드를 사용하여 빌드됩니다. 사용자 정의 코드는 종종 Ajax 기반 상호 작용과 함께 PHP와 JavaScript의 조합을 의미합니다.

신중하게 제작 된 메타 박스를 의도 한 위치에서 편집기 아래 영역으로 채우라는 제안은 터무니 없습니다.

현재 사용 가능한 포스트 편집 화면의 사용자 지정 옵션에서 발생한 회귀는 허용되지 않습니다.

기존 코드를 업데이트해야하는 경우 이러한 업그레이드가 클라이언트 프로젝트에서 발생하도록 모든 새 API가 완료된 시점부터 12-18 개월을 계산할 수 있습니다. 즉, 기존 API와 새 API가 모두 공존하는 이중 실행 기간이 필요합니다.

Metaboxes가 구텐베르그와 어떤 일을해야하는 이유를 모르겠습니다. 하나의 백엔드 페이지, 화면입니다. 수백 가지 방법으로 배열 할 수 있습니다.
현재 구현이 React를 중단한다고 말씀하셨습니다.

개발자가 Metabox를 구텐베르크에 묶을 것인지 아니면 외부에 둘 것인지 선택하게하십시오.
이 모든 문제는 모든 사람이 어떤 식 으로든 구텐베르크 블록을 만들어야한다고 가정하기 때문입니다. 원하지 않으면 필요하지 않습니다.

개인적으로 두 번째로 큰 문제입니다. 나는 항상 자바 스크립트로 어려움을 겪었고, 나는이 언어에 대한 반 재능입니다.
좋아, 모든 것이 내 주위를 돌지는 않지만 단지 말할 것입니다. Metabox를 추가하는 것은 이전보다 더 쉽지 않을 것입니다.

@Rarst 가 문제를 훌륭하게 요약했다고 생각합니다. 커뮤니티는 명확한 답변이 필요하고 개발팀이 지원 중단 방향을 따르는 경향이있는 것 같지만 먼저 해결책을 찾으려고하기 때문에 명확하게 설명 할 수없는 것 같습니다. 우리는 커뮤니티가 몇 달 동안 패닉 모드에 들어갈 필요가 없지만 동시에 같은 커뮤니티가 충분한 헤드 업과 명확한 길을 가지고 있어야합니다. 이것은 솔직히 찾기 어려운 타협입니다.

@ fklein-lu Fieldmanager가 "선택의 도구"가되어야한다는 것에 강력히 동의하지 않습니다. 상위 10 개 필드 플러그인 목록에도 표시되지 않습니다.
https://github.com/WordPress/gutenberg/issues/952#issuecomment -320523428

다른 많은 사람들이 말했듯이, 저는 메타 박스와 구텐베르크를 일관되고 연결된 인터페이스로 만들고자하는 욕구를 이해하지만, 메타 박스의 작동 방식을 변경하면 사람들에게 엄청난 억제력이 될 수있는 놀라운 복잡성이 도입됩니다. 역사에 따르면 버전간에 주요 비 호환성이 도입되면 커뮤니티가 크게 분열 될 수 있습니다.

대시 보드 백엔드 화면에 메타 박스를 어떻게 추가할까요?
구텐베르크와는 아무 관련이 없습니다.

@khromov 내 단어를 잘못 인용하는 대신 내가 실제로 쓴 내용을 읽어 하는 게시물 을 읽으면 Fieldmanager가 Top Ten 목록에 포함되지 않는 이유를 알 수 있습니다.

@ fklein-lu 내가 왜 당신을 잘못 인용했다고 생각하는지 확실하지 않습니다. 여기에 전체 컨텍스트가 있습니다. "메타 박스의 경우 Fieldmanager는 VIP 승인을 받았기 때문에 선택하는 도구입니다." Fieldmanager를 사용하는 사람이 없어서 그 인용문을 이해하기가 어렵습니다.

Fieldmanager가 WPorg에 없다는 것을 알고 있습니다. 내가 말하는 것은 우리가 그것으로부터 사용 데이터가 없다는 것입니다. 나는 그것이 최고의 플러그인 중 일부와 경쟁 할 수 있을지 의심스럽고, 전체 개발자 수에서 사라지는 소수 인 VIP를 위해 사용하는 것 외에는 커뮤니티 지원이 거의 없습니다.

우리 에이전시에서는 3.x WordPress 어딘가에서 Blogging-System에서 Content Management System으로 한 걸음 나아 갔다고 믿습니다. 지금은 프로젝트에 필요한 방식으로 콘텐츠를 구성 할 수 있으며 사용자 지정 게시물 유형과 메타 상자를 사용하여 텍스트뿐만 아니라 다양한 콘텐츠를 만듭니다.

5.0에서 블록 편집자가 의무화되면 이것이 CMS에서 블로깅 시스템으로의 이념적 단계가 될 것이라고 강력하게 믿습니다. 워드 프레스를 호텔 예약 솔루션, 작업 플랫폼, 앱용 헤드리스 CMS, 위치 서비스 등으로 실행하는 수많은 엔터프라이즈 애플리케이션이 있으며 이러한 사용 사례 중 상당수는 편집기가 활성화되어 있지도 않습니다.

현재 메타 박스 구현과의 완전한 하위 호환성은 절대적으로 필수입니다. 깨는 것은 앞으로 수년 동안 클라이언트와 사용자와의 신뢰를 깨뜨릴 것입니다. 내가 가장 좋아하는 솔루션은 "theme_supports"와 산만하지 않은 사용성에 관한 것입니다.

요약 : 엔터프라이즈 클라이언트가 유지 관리 이외의 다른 작업을 위해 향후 12 개월 이내에 코드를 업데이트 할 것으로 기대하지 마십시오. 적절한 타임 라인과 함께 지원 중단 정책 / 경고를 추가합니다. 백엔드 및 코드 유용성 측면에서 변경을 강요 할 때 WordPress에 대한 신뢰가 크게 떨어질 것으로 예상됩니다.

그것은 코딩이 아닌 정치, 투표 / 선거가됐다. 일부 사람들은 오래된 Metabox가 "오래된", "뒤로", "제한적"이며 더 이상 자리가 없다고 결정했습니다. 그들에 대한 진정한 주장과 이유가 없습니다. React와 다른 스크립트가 터보 모던하다는 점을 제외하고는 보지 못했습니다.

나는 여전히 오래된 Metabox를 버리고 구텐베르크 방식으로 상상 한대로 할 해결책을 찾는 데 당신을 지원합니다. 그러나 그것을 해결하는 방법을 모르는 것 같습니다.

나에게 아직 블랙홀이 많을 때이 모든 것을 논의하기는 어렵다. 그리고 나는 유일한 사람이 아닙니다.

이 문제에 대해 내가 얼마나 객관적인지 설명하기 위해 다음을 시도하십시오.

• 나는 여전히 TinyMce와 (Metaboxes가있는) 오래된 포스트 화면이 내가 CMS 세계에서 본 것 중 가장 아름다운 것이라고 생각합니다. 기능, 필터, 확장 및 아름다운 디자인. 예, 순수한 아름다움과 즐거움입니다.
• 그럼에도 불구하고 나는 첫날부터 구텐베르크를 받아 들였다. 예,이 "오래된"모든 것을 버리고 전환하고 결코 뒤돌아 보지 마십시오.

그들은 내가 모르는 것을 알고있었습니다. 그들은 코드를 소유하고 있습니다. 하지만 더 이상 확실하지 않습니다.

두 번째로, 잊어 버렸습니다.이 맥락에서 매우 중요합니다. 여기에서는 이미 몇 번 언급되었습니다.
나는 다른 사람들과 조금 다르게 일을합니다. 내가 구텐베르크 (어쨌든 그들 중 하나)를 처음부터 받아 들인 이유는 개인적으로 내가 웹 사이트를 만든 사람들이 구텐베르크를 사용하도록 설득하는 데 아무런 문제가 없을 것입니다. TinyMce와는 다른 무언가를 강제하면 큰 문제입니다.
모든 플러그인 및 WP 코어 업데이트를 모두 무료로 수행합니다. 그래서 그들이 구텐베르크와 나머지 시간 동안 업데이트를 중단해야 할 때이 딜레마에서. 그들의 선택은 분명하다고 생각합니다.

다른 많은 개발자, 회사에서 업데이트 비용을 청구합니다. 따라서이 딜레마는 그렇게 쉬운 마음이 아닐 것입니다.

@khromov 저는

@Rarst 와 @kevinwhoffman도 +1하고 싶습니다. 기존 메타 박스에 대한 완전한 지원을 유지하면 "레거시"메타 박스를 TBD Gutenberg 등가물로 대체하는 미래가 가능할 수 있습니다. 그러나 현재 이전 버전과의 호환성을 둘러싼 불확실성은 최대한 빨리 완화되어야합니다.

WordPress.org의 플러그인 설치 수는 플러그인 또는 라이브러리의 포함 또는 제외를위한 유일한 지표가 될 수 없습니다. Fieldmanager를 광범위하게 사용하는 _single_ 사이트를 알고 있으며 한 달에 약 2,400 만 명의 순 방문자에게 서비스를 제공합니다.

따라서 소수의 개발자 만이 특정 플러그인을 사용할 수 있지만, 트래픽 양이 많고 가시성이 많은 사이트를 개발하고 유지 관리해야합니다.

따라서 그들은이 토론에서 제외 될 수 없습니다. Automattic의 Gutenberg 팀은 이러한 사용 사례에 대한 통찰력을 얻기 위해 VIP 팀과 협력해야한다고 생각합니다.

이러한 엔터프라이즈 프로젝트는 더 느린 속도로 이동합니다. 실제 코딩 작업이 아닌 메타 박스 및 기타 UI 요소를 업그레이드하는 데 많은 작업이 필요합니다. 5.0 기간 내에 이러한 모든 사이트를 업그레이드 할 수있는 기업 개발자도 충분하지 않습니다.

이 스레드에서 다른 사람들이 지적했듯이이 속도를 고려한 업그레이드 경로가 필요합니다. 이와 같이 사전 예방 적 유지 관리 작업의 일부로 변경 사항이 점진적으로 발생할 수 있습니다.

@ fklein-lu 위 참조, 우리는 듣고 있으며 코드에 대해 협업하고 싶다면 언제든지 연락 할 수 있습니다!

VIP 및 엔터프라이즈 시장에 관해서는 다음 주 덴버 에서 @m에게 연락 했지만 AFAIK는 참석할 수 없습니다.

"5.0"타임 라인과 관련하여 지금까지 인터뷰 한 엔터프라이즈 엔지니어는 기존 TinyMCE 편집기 및 메타 박스를 사용하기에 충분한 옵트 아웃 경로가 있다고 가정하고 있습니다. 구텐베르크 팀이이 가정에도 👍을 부여했다고 믿으십시오.

그리고 Jetpack을 사용하는 웹 사이트가 하나 있고 하루에 2 명의 순 방문자 만 있습니다.
너무 쉽게 기분이 상하는 꿀벌을 그만 두십시오. 새로운 Joomla 버전에 대한 논의가 아니라 WordPress입니다. :)

@ fklein-lu 절대적으로 동의합니다. 그러나 메타 박스 필드의 "선택 도구"가된다면 제안 된 Fields API 가 될 것이라고 생각합니다.

@davisshaver 그게 현명한 일이라고 생각합니다. 워드 프레스가 이전 버전과의 호환성없이 폐기 접근 방식을 강화하려고 시도하면 누군가가 코드의 오래된 덩어리를 "병렬", 레거시 기반 대체 게시물 및 메타 박스 시스템으로 포팅하고 플러그인 또는 이와 유사한 것으로 패키징하는 것을 쉽게 볼 수 있습니다. 개인적으로 그것이 내가 일어나기를 바라는 절대적인 마지막 일입니다. 다시 말하지만, 이것은 확실히 모든 노력을 다하고 있으므로 WordPress 커뮤니티를이 새로운 미개척지로 데려가는 데 관련된 모든 사람들에게 행운을 빕니다.

여기에 들어와 우려와 아이디어를 표현해 주신 모든 분들께 감사드립니다. 이것은 긴 스레드가되고 있지만 몇 가지 요점을 명확히하려고 노력할 것입니다.

WordPress에서 Metabox API를 공식적으로 사용하지 않을 계획입니까?

아니.

아직 완전히 대답되지 않은 질문은 _ 구텐베르크 편집자의 맥락에서 메타 박스가 어떻게 작동 하는가 _입니다. 동일하게 유지해야합니까 아니면 진화해야합니까? 중단을 최소화하면서 어떻게 설계 목표를 향해 나아갈 수 있습니까?

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

그러나 메타 박스와 확장 성을 처리 할 수있는 여러 가지 방법이 있습니다.

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

또는 이들의 조합.

여기에서 최고의 솔루션을 구축하는 데있어 커뮤니티의 도움을 받으면 다시 한 번 확신이 부족한 것이 의지의 부족이 아닙니다. 가능한 솔루션을 실제로 탐색하고 설계 및 개발 측면에서 명확하게 작성해야합니다.

아니.

고마워요 , 많은 사람들이 방금 숨을 내쉬 었다고 생각합니다.

아직 완전히 대답되지 않은 질문은 구텐베르크 편집자의 맥락에서 메타 박스가 어떻게 작동하는지입니다.

Gutenberg 편집자의 맥락에서 왜 _are_ 메타 상자입니까?

답은 Gutenberg가 전체 포스트 에디터 _screen_을 JS 기반 구현으로 대체하는 것을 목표로하는 것 같습니다. 나는 그 이유를 알기 위해 개발을 따르지 않았습니다.

그러나 나는 여전히 그것이 매우 유효한 지적이라고 생각한다. 만약 Gutenberg의 범위가 에디터 컴포넌트라면 _screen_ scope를 대체하는 것은 지나치게 야심적인 것 같다. _ 구텐베르크의 범위가 (적어도 부분적으로) WordPress _admin_ 전체를 대체한다면 _ 놀랍게도 _ 더 광범위하고 까다로운 범위입니다. "단지"편집기를 대체하는 것은 쉬운 일이 아닙니다.

그러나 메타 박스와 확장 성을 처리 할 수있는 여러 가지 방법이 있습니다.

Gutenberg는 기본 _editor_ 구성 요소를 대체하도록 범위가 지정되어 있으며 기존 관리 UI가 계속 작동합니까? _this_가 고려되고 있습니까?

내가 만든 필드 관리자 플러그인에 대해서만 말할 수 있으며 현재 60 개가 넘는 프로젝트에서 사용하고 있습니다. 누구나 자신의 시나리오에 대해 생각하는 데 도움이 될 수 있기를 바라면서이 변경이 의미하는 바를 간략하게 언급하겠습니다.

공통 추상 클래스 및 인터페이스를 사용하여 고도로 분리 된 아키텍처를 구축하는 문제를 겪었으므로 새 "위치"를 추가하기 만하면됩니다. 내 요점과 관련된 아키텍처 구성 요소는 다음과 같습니다.

• 위치 : 필드 그룹이 첨부 된 위치 (예 : 게시물, 페이지, 분류 용어 등), 각 위치에 대한 변형 (예 : 게시물 및 설정 위치는 메타 상자에서 작동). 이 클래스는 아래 언급 된 모든 움직이는 부분을 인스턴스화합니다.
• 위치 데이터 저장소 : 각 위치에 대한 변형이있는 데이터 검색 및 유지를 담당하는 계층 (예 : 포스트 데이터 저장소는 포스트 메타에서 작동, 설정은 옵션으로 작동 등)
• 위치보기 : 필요한 경우 설정 페이지의 경우와 마찬가지로 템플릿 및 도우미 기능을 보유하는 View 클래스입니다.

이제 구텐베르크의 맥락에서 제가이 새 편집자를 지원하려면 개인적으로해야 할 일은 구텐베르그라는 새 위치를 추가하는 것입니다.이 위치에는 다음이 포함됩니다.

• Gutenberg 편집기에 연결하는 자체 초기화 방법입니다. 나는 이것이 대부분 자바 스크립트 기반이라고 생각하므로 내 라이브러리는이 목적에 필요한 공통 스크립트를 등록하고로드합니다.

• 자체보기 / 템플릿 : 각 필드 유형에 대한 반응 구성 요소를 만들어야합니다. 이것은 큰 문제가 아닙니다. 뷰 레이어는 다른 모든 부분이 적절하게 설정되었을 때 매우 간단합니다. 그런 다음 이러한 구성 요소는 metabox 반응 구성 요소에 중첩됩니다. 이것은 내가 이미 php 기반 metaboxes html, 즉 fields html> field group html> location (settings page html, metabox etc.)에 대해 수행 한 작업과 매우 유사합니다.

• 자체 데이터 저장소 클래스. 포스트 메타 기반이기 때문에이 클래스가 포스트 위치 데이터 저장소와 크게 다를 것이라고 생각하지 않습니다 (누구도 포스트 메타를 곧 폐기 할 생각이 없다고 생각합니다).

• 새로운 부분 : 끝점. 이러한 새로운 반응 기반 구성 요소는 값을 검색하고 유지하기 위해 데이터 저장소와 통신 할 수 있어야합니다. 이들은 완전히 클라이언트 측에 존재하기 때문에 위치 데이터 저장소와 통신하기위한 브리지로 엔드 포인트가 필요하며, 메타 저장소는 어떤 컨텍스트에서로드 될 구성 요소를 검색해야합니다.

중요한 것이 누락되지 않았다면 (아직 구텐베르크를 확인할 시간이 없었 음을 인정합니다) 이것은이 새로운 "위치"를 기본적으로 지원하기 위해해야 ​​할 일의 요점입니다. 또한 개발자가 요청하는 것이 가능한지 확인하기 위해 각 위치와 해당 필터에 대한 기본 제공 검사가 있습니다. 예를 들어 게시물 유형이 "비디오 인 경우 형식이"프로젝트 "게시물 유형에 필드 그룹을 추가하려는 경우 "이지만 CPT가 게시 형식을 지원하지 않는 경우 라이브러리에서 예외가 발생합니다. 이 새 위치에 대해 동일한 피드백을 제공 할 수 있기를 바랍니다. 예를 들어 게시물 유형이 "리뷰"인 구텐베르크 위치에 필드 그룹을 추가하는 경우 해당 게시물 유형에 대해 알 수 있기를 바랍니다. 구텐베르크를 지원하기 위해 등록되었습니다.

이것은 결국 내가 예상했던 것보다 조금 더 길어졌습니다. 구텐베르크 개발에 관여 한 사람이나 비슷한 우려를 가진 도서관 저자 중 공유 할 의견이있는 모든 사람의 의견을 듣고 싶습니다.

감사.

Gutenberg는 기본 편집기 구성 요소를 대체하도록 범위가 지정되어 있으며 기존 관리 UI가 계속 작동합니까? 이것이 고려되고 있는가?

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

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

아직 끝나지 않았고 쉽지도 않지만 매일 노력하고 있습니다.

☝️ 오해를 해결하기 위해 티켓 제목과 설명을 업데이트했습니다.

새로운 구텐베르크 편집자와 ButterBean의 미래

위 의

저장소 : https://github.com/justintadlock/butterbean/tree/dev

테스트 목적으로 프레임 워크는 https://github.com/justintadlock/custom-content-portfolio 플러그인에 포함되어 있습니다.

ButterBean은 Backbone.js 및 Underscore.js로 빌드 된 드롭 인 프레임 워크입니다. 핵심 WP의 커 스터 마이저에서 크게 모델링되었습니다.

젊은 프레임 워크이지만 올해 여러 플러그인에 롤링 할 계획이었습니다. 현재 나와 다른 사람들은 구텐베르크의 방향 때문에 이것을하기를 주저하고 있습니다. 그리고 React에서 처음부터 다시 시작하거나 JS 프레임 워크가 궁극적으로 다음에 코어 WP에 추가되기로 결정되어서는 안되는지 확신 할 수 없습니다.

사용 된 후크

다음은 사용되는 기본 코어 WP 후크입니다 (대부분의 메타 박스 프레임 워크에 대해 꽤 표준이라고 생각합니다).

load-post.php
load-post-new.php 
add_meta_boxes
save_post 
admin_enqueue_scripts
admin_footer 
admin_print_footer_scripts

CMB2에 대한 관련 후크를 문서화하기 위해 # 2265를 작성했습니다.

사람들이 목업을 더 추가하도록 장려하기 위해 디자인 라벨을 추가했습니다.

일반적으로 표시되는 콘텐츠의 일부가 아닌 데이터는 메인 에디터 영역의 일부가되어서는 안된다고 생각합니다. 모든 것이 블록이 아닙니다.

1) 대부분의 사용자 지정 메타 상자는 Fieldmanager 로 만들어집니다. 내 눈에는 업데이트 외에 추가 작업이 필요하지 않은 "Just Work"이어야합니다. cc / @mboynes 및 @bcampeau 는이 토론에 가치를 제공 할 수 있습니다.

2) 사용자 정의 메타 상자 중 일부는 jQuery와 PHP가 혼합되어 있습니다. 예를 들어, "지우기"버튼이있는 라디오 인 "하나 또는 없음"메타 상자가 있습니다. 이것이 깨질 것이라고 가정하면 구텐베르크에서 이것을 만드는 방법에 대한 예제가있을 것이며 코드가 깨지기 전에 구텐베르크를 명령하는 WordPress 버전으로 업그레이드하는 데 상당한 시간이 걸릴 것으로 예상합니다.

3) 선택이 이루어질 때까지 게시 버튼을 비활성화하는 jQuery와 PHP 코드를 결합한 또 다른 메타 박스가 있습니다. 두 번째 예와 유사하게 이것이 깨질 것이라고 가정하면 구텐베르그에서 이것을 만드는 방법에 대한 예가있을 것이며 이전에 구텐베르그를 요구하는 WordPress 버전으로 업그레이드하는 데 상당한 시간이 걸릴 것으로 예상합니다. 내 코드가 깨집니다.

4) 과거에 카테고리 메타 상자를 제거하고 다음으로 대체했습니다. 1) 라디오 선택 2) 새 카테고리를 추가 할 수없는 버전 (이건 바보 같았습니다).

5) post_submitbox_misc_actions 를 사용하여 자체 메타 박스에있을 필요가없는 게시 메타 박스에 옵션을 추가했습니다.

상당한 시간이 의미하는 한, Gutenberg API가 동결 된 시점에서 ~ 2 년이라고 말할 수 있습니다.

우리가 여기있는 동안 모든 사람들이 포스트 화면을 확장하기 위해 메타 박스 만 사용하는 것은 아니라는 점을 여기 모든 사람들에게 상기시키고 싶습니다. 우리 중 일부는 다음 후크도 사용합니다.

• 'edit_form_top'
• 'edit_form_after_title'
• 'edit_form_before_permalink'
• 'edit_form_after_editor'
• 'edit_form_advanced'

@mikeschinkel이 edit_form_[POSITION] 후크에 대해 한 말을 두 번째로 하겠습니다 . Piklist는 메타 박스, 워크 플로 및 기타 항목을 많이 사용합니다.

시간 내 주셔서 다시 한 번 감사드립니다.

구텐베르크가 편집자 교체인지 화면 교체인지에 대한 질문은 이전 버전과의 호환성을 염려하는 사람들뿐만 아니라 구텐베르크를 개발하는 사람들에게도 가능한 한 빨리 대답하는 것이 중요합니다. 이 질문에 대한 답은 구텐베르크의 작동 방식과 통제 위치에 관한 매일 내리는 많은 결정에 영향을 미칩니다.

첫 번째 베타 이후로 우리는 이미 화면 교체 경로에있는 것이 분명했지만 화면을 개편하기로 한 결정은 메타 박스 지원 및 누락 된 후크 문제를 야기했습니다. 이러한 문제에 대한 답이 "전체 화면을 교체하지 마라"라면 화면 교체를 전제로 이미 너무 많은 작업이 이루어 졌기 때문에 돌아 가기가 어려울 것 같아 걱정입니다.

첫째, 이것에 대한 실제 진전을 볼 수있어서 좋습니다.

한 가지 관찰은 편집 화면 확장이 독립적으로 작동하는 경우가 거의 없다는 것입니다. 예를 들어 ACF는 상위 게시물 선택 상자의 JS 변경 이벤트를 기반으로 표시되는 필드를 변경합니다.

DOM이 Gutenburg 컨텍스트에서 다르고 React가 외부 이벤트 리스너에 적합하지 않다는 점을 감안할 때이 데이터를 메타 박스 및 기타 플러그인 코드에서 계속 사용할 수 있도록하려면 어떻게해야합니까? 한 가지 가능성은 Redux 스토어가 메타 박스에 제공되지만 이것이 가능한지, 원하는지 또는 충분한 유연성을 제공하는지 모르겠습니다.

메타 박스가 iframe에로드되거나 페이지에 ajax 처리 될 때 이는 더욱 문제가됩니다.

첫 번째 베타 이후로 우리는 이미 화면 교체 경로에있는 것이 분명했지만 화면을 개편하기로 한 결정은 메타 박스 지원 및 누락 된 후크 문제를 야기했습니다. 이러한 문제에 대한 답이 "전체 화면을 교체하지 마라"라면 화면 교체를 전제로 이미 너무 많은 작업이 이루어 졌기 때문에 돌아 가기가 어려울 것 같아 걱정입니다.

나는 "화면"교체 접근 방식을 위해 얼마나 많은 작업이 수행되었는지 완전히 알 수 있습니다. 그러나 "포스트 콘텐츠 편집기"교체를 목표로 시작된 프로젝트는 전체 편집기 화면을 대체 할 것이라고 일방적으로 결정하기 전에 커뮤니티로 돌아 가야하지 않았습니까?

내가 수행 한 거대한 작업을 무시하려는 의미는 아니지만 (편집기가 정말 멋져 보입니다), 너무 많은 워드 프레스는 엄격하게 "컨텐츠"가 아닌 메타 필드에 의존하고 있으며 그 중 많은 부분이 내부에 전혀 맞지 않습니다. 동일한 구텐베르크 컨테이너 (완전히 강제되지 않는 한). 나에게는 구텐베르크의 원래 진술인 다른 방법보다 "해결책이 있고 문제를 만들어야합니다."라고 생각합니다 (포스트 콘텐츠 편집기는 매우 지저분하고 단축 코드는 사용하기 쉽지만 모든 것이 친숙합니다- Shortcake 등의 접근 방식에도 불구하고).

7 월 4 일의 @brentjett 모형은 내용에 맞지 않는 "개선 된 메타 박스"( "설정 영역")와 구텐베르그 블록 (이벤트 정보)으로 쉽게 변환 할 수있는 메타 상자 모두에서 작동 할 수있는 것으로 보입니다.

@rilwis 플러그인에서 Metabox 의 광범위한 사용을 언급해야한다고 생각합니다. 대부분의 제품에서 사용하기 때문에 광범위한 프레임 워크로 사용됩니다. 이 구텐베르크 전체에 어떻게 들어 맞을까요? — 메타 박스를 구축하기 위해 플러그인을 판매하는 사업을하는 사람의 통찰력 (가장 큰 영향을받을 것임)이 여기에 유용해야합니다.

디자인 영감을 얻으려면 무료 및 상업용 (스크린 샷) 백엔드 관리자 테마를 확인할 수 있습니다. 또는 다른 플랫폼.

대시 보드이지만 구텐베르크를 상상해보십시오.

아마도 제안 된 Fields API 는 새 편집기에서 메타 박스를 지원하는 것과 관련된 몇 가지 문제를 해결할 것입니다.

고려해야 할 시나리오는 WordPress가 Gutenberg로 업데이트되고 메타 상자를 구현 한 플러그인이 .

이것은 관리자 경험을 깨는 데 가장 큰 위협이되는 "최악의 경우 시나리오"이지만, 유명 플레이어 및 사용자 지정 일회용 솔루션을 포함하여 메타 박스 플러그인으로 구동되는 사이트의 수를 고려할 때 드문 일이 아닙니다.

대규모 브레이킹 변경 사항을 기꺼이 인정하지 않는 한 이러한 메타 박스 플러그인 업데이트에 의존하는 것은 방정식의 일부가되어서는 안됩니다. Fields API는 좋은 아이디어이지만 앞으로 사용자 지정 필드를 처리하는 방식을 개선하면 이러한 API가 존재하기 전에 작성된 코드에 영향을 미칠 것이라고 가정해서는 안됩니다.

다음은 분명합니다.

• 우리는 큰 규모에서 하위 호환성을 깨뜨리지 않을 것입니다.
• 일부 감지 메커니즘을 사용하여 편집기 페이지를 분기하지 않을 것입니다.
• 우리는 단일 편집자와 편집 경험을 갖게 될 것입니다.
• 현재 구텐베르크 구현이 수용 할 수없는 위의 많은 사용 사례가 있습니다.

따라서:

앞으로 나아가는 방법은 새롭고 오래된 것을 포용하는 방식으로 포스트 편집 화면을 재고하는 것입니다. 이는 어떤 방식 으로든 현재 구텐베르크 구현에 대한 역 추적을 의미 할 가능성이 높습니다. 그것은 디자인의 도전이지 세상의 끝이 아닙니다.

@dmccan 아니요, 지금까지 제안 된 모든 솔루션이 "명확하지 않습니다".

• 관리자 경험을 신규 / 이전간에 분할합니다.
• 플러그인 업데이트에 의존하여 메타 상자를 차단합니다.
• 존재하지 않는 Fields API에 의존합니다.
• 문제를 완전히 방지하려면 새 인터페이스를 등록 취소해야합니다. 이로 인해 관리자 환경이 다시 분할됩니다.

나는 멜로 드라마틱 한 최악의 시나리오를 강조하지 않았다. 나는 우리가 문제에 접근해야하는 제약을 정의하기 위해 그것을했다.

따라서 구텐베르크는 오랫동안 기능 플러그인을 유지해야 할 것 같습니다. 사람들이 원하는 경우 선택하거나 원하지 않는 경우 옵트 아웃 할 수있는 기능 플러그인으로 코어가있는 플러그인으로 포함될 수도 있습니다.

단일 편집자 경험을 갖기 위해 해결해야하는 모든 문제를 해결하는 데는 많은 시간이 걸립니다. Microsoft의 원래 ASP.NET과 일반적인 웹 문제를 얼마나 잘 해결했는지 살펴보십시오. 결국 AJAX가 등장했고 나머지는 역사입니다.

너무 빨리 변경하면 WordPress가 진정한 레거시 전용 플랫폼이 될 수 있습니다.

추신 : "단일 편집기"요구 사항은 비현실적인 것 같습니다. 사용자가 이전 또는 새를 사용할 수있는 옵션이 있으면 이전을 사용하는 데 더 이상 이점이 없을 때까지 시간이 지남에 따라 새 버전을 발전시킬 수 있습니다. 그러나 기존 후크를 사용하여 설치하는 한 _ (나는 믿는다) _ 단일 편집기 솔루션으로 이동하는 것은 무책임합니다. #jmtcw

@kevinwhoffman- 동의한다고 생각하지만, 충분히 장황하지 않았을 수도 있습니다.

내 글 머리 기호가 분명하고 최종 솔루션이이를 수용 할 것이라고 생각합니다. 예를 들어, 솔루션을 찾는 사람들이이 시점에서 제안 할 수있는 내용에도 불구하고 워드 프레스가 이전 버전과의 호환성을 크게 깨뜨릴 것이라고 생각하지 않습니다.

지금까지 제안 된 솔루션은 부족합니다. 내 결론은 새롭고 오래된 것을 모두 수용하기 위해 현재의 구텐베르크 구현을 재고해야한다는 결론입니다. 그렇게하는 것이 정말로 앞으로 나아갈 유일한 방법이라고 생각합니다.

@mikeschinkel- 구텐베르크가 2017 년 Core에서 유일한 편집기 옵션이 될 것이라고는 생각하지 않습니다. 사용자 선택으로 시작하여 모든 필수 기반을 다룰 수있는 지점까지 진화하거나 바로 잡을 시간입니다.

어쨌든 내가 제안하는 것은 모든 것을 버리고 모든 필수 기능을 어떻게 처리 할 수 ​​있을지 궁금해하는 것이 아니라 현재 편집기 화면의 일부 업그레이드 된 버전에 구텐베르크를 통합하는 백 트랙입니다. 사람들이 그것에 동의하면 그것은 가능하고 아마도 그렇게 거대하지 않을 것이라고 생각합니다. 이러한 과정은 더 빠르고 더 나은 최종 사용자 경험을 제공 할 것입니다.

아마도 그들은 (핵심 코더) Matt에게 말해야 할 것입니다. 그는이 모든 것을 시작했고 지금은 답이 없습니다.

@dmccan 내가 매우 중요하다고 생각하는 한 가지는 구현되는 것이 무엇이든 쉬운 확장 성 모델을 가지고 있다는 것입니다. WordPress는 플러그인 작업 및 필터 후크가있는 쉬운 확장 성 모델로 유명하며 그 없이는 Gutenberg가 확장하기 매우 어려운 현재 미디어 관리 시스템만큼 WordPress에 좋지 않을 것입니다.

참고로 React 또는 Vue를 사용해 본 적이 없지만 _ (나는 PHP 개발자입니다) _ React에 대한 빌드 시스템이 필요한 논의와 많은 사람들이 React보다 Vue를 사용하기가 훨씬 더 쉽다는 사실을 알게되면서 매우 불안해졌습니다. Gutenburg가 확장 성 모델을 배우고 사용하기 쉬운 지 여부와 클라이언트 프로젝트에 WordPress를 계속 사용할 수 있음을 의미하는지 여부.

내 우려 사항을 메모하기 위해 내 의견 만 있으면됩니다. 이에 대해 직접 회신 할 필요는 없습니다.

이게 뭔지 아는 것 같아요.
콘텐츠 편집기, "흐름 작성", "오래된 것으로 깨기 .... 뒤로"등이 아닙니다.

전혈의 프론트 엔드 비주얼 테마 편집기에 관한 것입니다.

여러분 모두에게 이메일을 보내서 죄송합니다. 이 특정 문제에 대한 마지막 의견입니다.

@Rarst @kevinwhoffman : Gutenberg가 편집자 교체인지 화면 교체인지에 대해 전적으로 여러분과 함께합니다. 잘 생각한 포인트입니다. 그리고 개발팀이 시작점과 편집자 인 구텐베르크의 본질로 돌아가서 다른 모든 것을 지금 그대로 유지할 수 있기를 바랍니다. 두 부분으로 구성되어 있으며 서로 유무에 관계없이 사용할 수 있습니다. 따라서 분리 된 것으로 유지하는 것이 좋습니다.

또한 Meta Box 플러그인에서 관련 후크를 나열하기 위해 # 2308을 만들었습니다.

@ahmadawais 언급

@nylen 고려할 플러그인 목록에 Posts 2 Posts 를 추가 할 가치가 있습니다. 더 이상 지원되지 않지만 여전히 널리 사용됩니다.

@nylen 플러그인 개발자의 사용자 정의 필드를 유지하지만 더 이상 활발하게 개발되지 않습니다 (요즘에는 CMB2를 사용합니다). 1000 개 이상의 활성 설치 만 있지만 목록에 추가 할 가치가있을 수 있습니다.

나는 Gutenberg Editor에 대한 의견이 내용 편집 부분이라는 것에 동의합니다. 완전한 화면 교체가되는 이유 또는 방법을 잘 모르겠습니다. 인기있는 모든 페이지 빌더가 제대로 작동합니다. TinyMCE를 콘텐츠를 더 쉽게 구성 할 수있는 다른 것으로 바꾸면됩니다.

또한 메타 상자는 일반적으로 콘텐츠의 일부가 아니며 콘텐츠와 관련이 있더라도 일반적으로 블록이라고 할 수는 없습니다.

예를 들어 직원 디렉토리를 살펴보십시오. 개인 정보 필드가 블록이되기를 원하는 이유는 무엇입니까? 이름, 성 등을 입력해야 할 때 다른 블록을 추가하는 것을 원하지는 않습니다.

tldr; Gutenberg는 콘텐츠 구성이 필요한 게시물 유형에 대해서만 TinyMCE 편집기를 대체해야합니다.

여기에 2 센트 만 더하면됩니다.

지금 그대로 두지 않겠습니까? 내 말은 이것이다.

• 지금처럼 게시물 제목 위로 마우스를 가져갈 때 두 가지 편집 옵션을 유지하지만 기본적으로 제목을 클릭하면 Gutenberg로 이동하도록 변경합니다. 그런 다음 Edit 링크를 구텐베르크로 이동하고 추가 링크를 수업 편집 화면으로 이동합니다. Classic Edit 와 같이 부를 수 있습니다.
• 게시물 및 페이지 게시물 유형에 대한 일부 유형의 지원 플래그를 추가하여 개발자가 원하는 경우 Gutenberg를 비활성화 할 수 있습니다. 구텐베르크가 활성화되지 않은 경우 제목 링크를 "클래식"편집 페이지로 이동하고 구텐베르크에 대한 Edit 링크를 제거하면 Classic Edit 링크의 텍스트가 Edit 변경됩니다.
• 그런 다음 사용자 지정 게시물 유형에는 Editor, Featured Image 등과 같은 Gutenberg 지원이 있습니다. 이렇게하면 CPT가 Gutenberg를 지원할 필요가 없습니다.
• 그런 다음 클래식 편집 페이지의 스타일을 업데이트하십시오. 구텐베르크 스타일과 일치하도록 메타 상자와 사이드 바 스타일을 업데이트했습니다. 발췌 및 주석 메타 상자를 구텐베르크와 같은 사이드 바로 이동하십시오.

나는 이것이 모두를 행복하게 할 것이라고 생각합니다. 구텐베르크는 게시물 및 페이지 게시물 유형에 대해 기본적으로 켜져 있습니다. 개발자가 Gutengerg 대신 메타 상자를 사용해야하는 경우 가능합니다. 플러그인 및 테마 개발자에게 Gutenberg로 전환 할 시간을 제공하고 최종 사용자에게 편집기 변경으로 인한 워크 플로우를 방해하지 않고 Gutenberg에 적응할 수있는 기능을 제공합니다.

그리고이를 통해 개발자는 구텐베르크를 사용하는 아이디어를 최종 사용자에게 판매 할 시간을 가질 수 있습니다. 사람들은 변화를 좋아하지 않는 경향이 있습니다. 새로운 편집기에 익숙해지게하는 것이 단순한 변경보다 훨씬 낫습니다.

이것은 또한 두 가지 다른 저장 방법을 허용하는 두 가지를 분리합니다. Gutenberg는 JS를 사용할 수 있고 classic은 PHP를 계속 사용할 수 있습니다.

사용자가 Gutenberg로 게시물을 저장 한 다음 클래식으로 편집하려고 시도한 경우 게시물을 저장하면 다른 편집자에서 게시물의 이전 저장을 재정의한다는 것을 알리는 것과 같은 경고 유형을 추가합니다. 마지막으로 사용한 편집기를 나타내는 포스트 메타와 같은 것이있을 수 있습니다.

아이디어입니다. 어리석은 생각 일지 모르지만 많은 개발자들이 갖고있는 모든 걱정을 덜어 줄 것이라고 생각합니다.

저는 오늘날 많은 사람들이 구텐베르크의 범위에 대해 제기 한 요점에 전적으로 동의합니다. 이 프로젝트는 처음에는 콘텐츠 편집기에 대한 (많이 필요한) 개선으로 시작되었습니다. 이 글을 읽으면서 나는 우리가 존재할 필요가없는 문제를 만들고 있다고 생각할 수밖에

화면을 완전히 개편하면 비전문 콘텐츠 편집자에게 많은 문제가 발생 할까 봐 걱정됩니다. 평균적인 블로거 / 저자는 완전히 다른 화면과 패닉을 보게 될 것입니다. 업데이트가 단순히 편집자를 대상으로하는 경우 온 보딩 환경을 훨씬 더 제어 할 수 있습니다.

이에 접근하는 또 다른 방법은 Beaver Builder 와 동일한 워크 플로우를 사용하는 것입니다. 즉, 일반 게시물 편집 페이지 (일반적인 Meta Box 섹션 등)를 유지하면 버튼을 통해 Gutenberg를 시작할 수 있습니다. 그러면 새 화면으로 이동할 수 있습니다. 산만 자유 쓰기 모드를 대상으로하는 의견과 매우 유사합니다.

또한 기존 메타 박스 UI를 유지하고 콘텐츠 편집기 만 변경 하자는 사람들도 동의합니다.

저는 우리 대부분이 플랫폼을 발전시키는 주된 요소가 혁신이라는 것을 알고 있다고 생각합니다. 워드 프레스는 다른 사람들이하는 일과 일치 할 수있는 (그리고 능가 할 수있는) 더 풍부한 경험을 위해 JS 기반 접근 방식으로 천천히 이동하려고 노력하고 있음이 분명합니다. 솔직히 말하면 전체 메타 박스 시스템과 현재 편집 화면 UI가 다소 낡아 보일 수 있지만 개발자로서 우리는 익숙해 져서 우리에게 두 번째 성격이며 얼마나 많은 학습 곡선을 고려하지 않습니다. 그것입니다.

이 전체 스레드를 읽으면 두 가지 사항이 명확 해집니다.

• 핵심 팀이 완전히 js 기반 편집 화면을 추진하고 싶어한다는 것은 분명하며 imho는 괜찮습니다.
• 아마도 우리 모두가 위의 사항을 받아 들일 수 있다면 대화를 기존 지원 및 마이그레이션 전략으로 이동하여 추구 할 수 있습니다.

메타 박스의 js 버전이 결국 어떻게 작동하는지 이해하자마자 (제안 된 API가 있습니까?) 기존 기술 (플러그인, 필드 관리자 등)을 만드는 브리지를 만드는 방법에 대해 생각할 수 있습니다. 이 새로운 접근 방식으로 작업하십시오.

API에 초점을 맞춘 토론이 이미 일어나고 있다면 누군가 저와 올바른 방향으로 진행되고 있는지 모르는 다른 사람을 가리킬 수 있습니까? 감사!

탭을 통해 탐색되는 두 화면으로 편집기를 분할하지 않는 이유가 있습니까?

내 견해는 구텐베르크가

• 편집기 화면 정리 시도
• 페이지 빌더 / 레이아웃 기능을 코어에 추가하려는 시도
• 개발자가 새 콘텐츠 블록을 더 쉽게 만들 수 있도록하여 메타 박스의 필요성을 최소화하려는 시도입니다.

위에서 강조한 바와 같이 대부분의 개발자와 최종 사용자가 느끼고 예측할 수있는 문제는 Gutenberg,

• 작성자로부터 편집기 스타일 형식 선택을 제거합니다.
• 작성자가 블록을 추가하기 위해 마우스를 많이 클릭해야하는 직관적이지 않은 워크 플로우를 사용하도록합니다.
• 일부는 유지되고 일부는 유지되지 않는 많은 오래된 플러그인을 중단합니다.
• WordPress를 트윗 플랫폼과 같은 느낌으로 변환합니다.

Guttenberg를 사용하여 콘텐츠를 만드는 것은 Mautic 또는 MailChimp에서 이메일 템플릿을 디자인하는 것과 동일한 어색함을 가지고 있습니다. Guttenberg의 UI는 템플릿 디자인에는 잘 작동하지만 긴 포스트 생성에는 적합하지 않습니다.

스톱-스타트 콘텐츠 생성 UI 도입이 아니라 워크 플로우 유동성을 높이는 데 집중해야합니다.

Guttenberg의 UI는 멋져 보이지만 최종 사용자가 현재 형태에 가까운 상태에서 만족할 것이라고 기대하는 것은 비현실적입니다. 콘텐츠 제작에 방해가됩니다.

텍스트 블록은 쓸모가 없습니다. 텍스트 위젯은 작성자를 몇 가지 글꼴 형식 만 사용하도록 제한해서는 안됩니다. 이것은 많은 저자를 짜증나게 할 것입니다.

내 제안은 다음과 같습니다.

• 페이지 편집기에 Tabify 편집 화면 을 소개합니다.
• 메타 박스를 편집기 화면 내에서 자체 페이지 탭으로 이동합니다.
• 메타 박스에 React 기반이 아닌 페이지 사용 (편집기 탭 뒤에 숨겨진 페이지)
• longform에서 잘 작동하고 작성자가 블록을 사용하도록 요구하지 않는 기본 TinyMCE (또는 유사한 기능이 풍부한 편집기) 기반 캔버스를 사용합니다.
• Guttenberg Blocks를 TinyMCE 또는 TinyMCE 유사 제품에 대한 애드온으로 소개합니다.
• 작성자가 블록의 내용을 시각적으로 볼 수 있고 작성자가 각 블록의 편집 버튼을 클릭하지 않고도 페이지 흐름에서 직접 내용을 편집 할 수 있도록 TinyMCE 기반 편집기에 Shortcake 를 도입합니다.
• 개발자가 add_shortcode ()를 블록 생성에 연결하여 Guttenberg에 새 블록을 쉽게 추가 할 수 있도록합니다 (예 : add_shortcode ( 'tag', 'function', 'guttenberg true / false')). 숏 코드가 Guttenberg와 호환되도록 자동으로 add_shortcode를 조정합니다. 이를 통해 개발자는 일부 / 다수의 메타 박스를 Guttenberg 내에서 작동하는 단축 코드로 쉽게 변환 할 수 있습니다.

제가 정말로 말하고있는 것은 Guttenberg는 3 가지 작업으로 나누어 져야한다는 것입니다.

• 편집기 화면 정리
• 개선 된 편집기 UI
• 향상된 편집기 확장 프레임 워크.

대부분의 사람들은 워드 프레스를 사용하여 긴 형식의 콘텐츠를 만들고 콘텐츠를 만들기 위해 블록을 사용하는 것을 원하지 않습니다. 블록은 페이지 레이아웃 생성에 적합하지만 게시물이 작성 될 때마다 사용하면 짜증이납니다.

80 대 고객이 있습니다. 그녀는 콘텐츠를 만들고 싶어합니다. 그녀는 편집기 화면을 사용하는 방법을 다시 배우고 싶지 않습니다. 그녀가 Visual Composer에 익숙해지는 데 1 년 이상이 걸렸으며 사용하기 쉬운 페이지 빌더입니다.

나는 원래의 스레드 주제에서 벗어나 있지만 이것은 말해야 할 필요가 있습니다 : Guttenberg는 WordPress를 죽일 것입니다.

Guttenberg가 현재 형태로 도입되면 WordPress가 분기되고 Guttenberg 버전이 종료됩니다.

블로그 사이트에 WordPress를 사용하고 PHP 테마를 만드는 경우 새 편집기가 더 합리적 일 수 있지만 요즘에는 많은 사람들이 React, PODS / ACF 및 WordPress REST API를 사용하여 웹 애플리케이션을 구축하기 위해 WordPress를 CMS로 사용합니다. 따라서 CPT 간의 고급 연결을 위해 메타 박스 및 관계 필드를 지원해야합니다.

우선 구텐베르크가 멋질 거라고 생각합니다.

즉, 웹 사이트 / 기능을 깨면 신뢰가 깨진다는 데 모두 동의 할 수 있다고 생각합니다. 우리 모두는 서로를 신뢰할 수 있기를 원하고, 고객 / 고객은 우리를 신뢰하기를 원합니다.

우리가 할 수있는 최선의 방법은 개발자가 "레거시"편집기 화면으로 되 돌리는 데 사용할 수있는 필터를 포함하는 것입니다.

이렇게하면 우리 자신의 논리를 적용하여 구텐베르크에 대한 준비가되었는지 여부를 결정할 수 있습니다. 사용자가 구텐베르크에서 완전히 중단 될 메타 상자를 사용하는 경우 레거시 모드로 되돌 리도록 선택할 수 있습니다.

그런 다음 "레거시"메타 상자에 의존하는 이전 게시물이 제대로 작동하도록 유지하면서 메타 상자 또는 아이디어를 구텐베르그에 맞게 마이그레이션하기 위해 자신의 속도로 작업 할 수 있습니다.

레거시 메타 박스가 등록 된 위치 (컨텍스트)에서 렌더링되지 않고 현재처럼 계속 작동 할 수없는 이유는 무엇입니까?

따라서 먼저 (선택 사항) Gutenberg 편집기 섹션을 렌더링 한 다음 등록 된 (레거시) 일반 / 고급 컨텍스트 메타 상자 (등록 된 제목 포함), 새 게시물 설정 열이있는 사이드 바와 그 아래에 등록 된 (레거시) 사이드 바를 렌더링합니다. 컨텍스트 메타 상자 (등록 된 제목 포함).

물론 레거시 메타 박스는 모든 것이 잘 통합 된 새로운 포스트 설정 박스와 같은 스타일이 될 것입니다.

필요할 때로드되는 legacy-meta-box.php 스크립트가 필요할 수 있습니다 (예 : add_meta_box 호출시).

현재의 메타 박스 솔루션을 "레거시"로만 생각하고 처음에 사용하는 이유를 생각하지 않고 이전 편집기를 사용하도록 요구 한 다음 새 편집기에서 해당 기능을 제공하는 더 나은 방법을 작업하는 경우 현재 사이트는 레거시 상태로 유지되고 절대 업그레이드되지 않습니다. 이것은 클라이언트 사이트를 관리하는 사용자에게 큰 문제가 될 것입니다.

우리가 거의 모든 프로젝트에서 ACF 필드를 사용하는 이유는 데이터가 웹 사이트에 일관되게 표시되도록 제어하기 위해서입니다. 다음은 현재 작업중인 두 가지 예입니다. 아티스트와 연결해야하지만 별도로 전시해야하는 작품 / 설치물이있는 대규모 이벤트 사이트 및 축제입니다. 이 두 경우 모두 "컨텐츠", 구텐베르크가 교체하는 부분은 편집 화면에있는 내용의 약 10 %에 불과하며 실제로 가장 중요하지 않은 부분입니다. 이벤트 사이트의 경우 중요한 데이터는 이벤트 유형, 이벤트 범주, 날짜, 시간, 위치, 주최자 등입니다. 편집기에 내용을 입력하지 않고도 의미있는 이벤트 항목을 게시 할 수 있습니다. 페스티벌 사이트의 경우 아티스트를 선택하여 작품에 연결하고, 페스티벌 사이트에서 작품 위치를 선택하고, 특집 이미지를 업로드 할 수 있어야합니다. 다시 한 번 콘텐츠는 불필요합니다. 이러한 사이트의 모든 "일반적인"페이지 콘텐츠에 대해 구텐베르크는 충분히 유연하지 않으며 (기본적으로는 안된다고 생각합니다) 더 나은 기능을 위해 더 많은 기능을 갖춘 페이지 빌더 (Beaver Builder)를 계속 사용할 것입니다. 디자인 옵션.

이 모든 것의 또 다른 핵심 요소는 편집 화면의 내용 순서입니다. 이벤트의 경우 제목을 설정해야하지만 이상적인 편집 흐름에서는 "편집기"에 "내용"을 입력하기 전에 입력 한 날짜, 시간 등과 같은 주요 정보 중 일부를 원합니다. 우리는 편집 페이지에서 컨텐츠가 "컨텐츠"앞이나 뒤의 위치를 ​​제어 할 수 있어야합니다.

모든 "레거시"메타 상자가있는 다른 탭을 만드는 아이디어는 끔찍할 것입니다. CPT의 많은 사용에 대한 편집 흐름을 완전히 깨뜨려 사용자가 발견하기 매우 어렵다고 생각하는 방식으로 콘텐츠를 숨 깁니다.

프로젝트는 그것에 대해 훨씬 더 똑똑해야합니다. 어떤 탭에 어떤 비트가 있는지 (일종의 페이지 템플릿에서) 선택할 수 있다면 탭 프로세스가 훌륭하게 작동 할 수 있습니다. 또한 각 탭을 통해 사용자를 단계별로 안내하는 메커니즘이 필요합니다. 그러나 더 짧은 CPT 항목의 경우 편집기 콘텐츠 위에 특정 핵심 요소를 사용하여 한 페이지에 모두 보관할 수 있어야한다고 생각합니다 (원하는 경우 필수 블록).

사람들이 이야기하는 대부분의 솔루션은 모두 현재 편집 화면의 유연성이없는 것 같습니다.

그렇기 때문에 5.0의 타임 라인이 두렵습니다. 시간이 지나면 좋을 것 같지만 서두르면 조각화가 개발자와 클라이언트 모두의 모든 선의를 파괴 할 것입니다. WordPress는 유연성, 이전 버전과의 호환성 및 일반적인 사용자 친 화성으로 거래되고 있습니다. 우리는 새로운 반짝이는 장난감을 위해 그것을 희생 할 수 없습니다. 워드 프레스에 대한 PHP 요구 사항을 살펴보면 말 그대로 PHP 5.6 또는 7이 요구 사항이되기 몇 년 전에 이야기하고 있습니다. 커뮤니티는 긴 시간이 얼마나 답답하더라도 웹 사이트를 망가 뜨리지 않아야한다는 것을 인식했습니다. 이것은 정확히 같은 종류의 문제가 아닙니까?

이와 같은 변경은 궁극적으로 플랫폼에 적합하지만 신중하게 고려하고 관리해야하며 그렇지 않으면 WordPress의 기반이되는 기반을 위험에 빠뜨릴 수 있습니다.

@avocadesign- 몇 가지 좋은 점. 우리는 앞으로 자바 스크립트 메타 박스를 등록 할 수있을 것입니다. 현재 생각은 두 개의 위치를 ​​갖는 것 같습니다 ... 당신이 언급 한 것만 큼 유연하지 않습니다.

@avocadesign- 잘 설명되어 있습니다. post_content가 항상 게시물의 초점이되는 것은 아니며 '이벤트 및 아티스트'가 좋은 예입니다. 개발자가 WP가 CMS로 사용되는 방식과 일반적인 클라이언트가 포스트 편집 화면을 통해 작동하는 방식을 시각화 할 수 있도록 이러한 포스트 유형의 백엔드 및 프런트 엔드를 보여주는 스크린 샷을 보는 것이 좋습니다.

안녕하세요.

현재 메타 박스 솔루션을 "레거시"라고 생각하고 이전 편집기를 사용해야하는 경우

내가 제안한 (귀하의 의견 위에) '레거시'메타 상자는 구텐베르크 편집기 (게시물 유형에 필요한 경우) 또는 게시물 설정 블록 (등록 된 컨텍스트에 따라 다름) 아래에 있습니다. 이전 편집기를 유지하는 데 필요한 요구 사항이 없습니다.

탭 인터페이스가 작동하지 않을 것에 동의합니다. 내 제안에 대해 어떻게 생각하세요. 내가보기에 익숙한 모든 유연성을 제공하고 준비가되면 새 시스템으로 이동할 수 있습니다.

구텐베르크가 코어의 일부가된다면 언급 한 샘플에 대해 더 나은 UI를 구축 할 수 있습니다. 부분적으로 커스텀 페스티벌 블록 (일종의 WYSIWYG 형식)과 하나 이상의 (JS 기반) 게시물 설정 섹션의 관련 설정으로 구성됩니다. 사용자는 직접적인 피드백이있는 더 빠른 인터페이스의 이점을 누릴 수 있습니다.

WordPress는 유연성, 이전 버전과의 호환성 및 일반적인 사용자 친 화성으로 거래되고 있습니다. 우리는 새로운 반짝이는 장난감을 위해 그것을 희생 할 수 없습니다.

동의하지 않습니다. 나는 당신이 구텐베르크에게 조금 더 공로를 주어야한다고 생각합니다. 그들은 모두에게 적합한 솔루션을 위해 열심히 노력하고 있습니다. 그들은 (당신이 언급 한 것과 같은) 유스 케이스를 듣고 찾고 있습니다. 아직 아무것도 정해지지 않았고, 구텐베르크가 '아마도'의 일부가 될 수도 없습니다.
구텐베르크가 현재 논의중인 모든 문제를 해결하지 못한다면 5.0 릴리스에 포함되지 않을 것이라고 믿을 수 있습니다. 우리는 과거에 다른 기능에서도 여러 번 발생하는 것을 보았습니다.

다음은 호텔 속성을 관리하는 클라이언트를 위해 Advanced Custom Fields로 구축 한 인터페이스의 예입니다.

• 속성 사용자 지정 게시물 유형은 10 개의 탭에서 18 개의 사용자 지정 필드를 사용합니다.
• 탭은 모든 관련 정보를 하나의 화면에 보관하고 버튼 클릭만으로 편집기에 액세스 할 수 있습니다.
• 필드 유형에는 ACF 갤러리 및 관계 필드 외에도 간단한 텍스트 및 숫자 필드가 포함됩니다.
• editor 에 대한 지원이 사용자 지정 게시물 유형 등록에서 선언되지 않았으므로 전체 UI가 사용자 지정 메타 상자에 의존합니다.

이러한 유형의 UI는 일련의 사용자 지정 필드에 페이지 내 콘텐츠와 게시물을 구성하는 데 사용되는 "보이지 않는"메타 데이터가 혼합 된 여러 사용자 지정 WordPress 사이트를 대표합니다.

커뮤니티는 Gutenberg가 소개되면 이러한 유형의 인터페이스에 어떤 일이 발생하는지 알아야하며, @elliotcondon 에게 출시시기에 맞춰 모든 인터페이스를 React로 마이그레이션하도록 요청하는 것은 현실적인 기대라고 생각하지 않습니다.

안녕하세요.

커뮤니티는 구텐베르크가 소개되면 이러한 유형의 인터페이스에 어떤 일이 발생하는지 알아야합니다.

당신 말이 맞지만이 문제 # 952의 목표는 대안을 논의하고 제안함으로써 그 답을 _ 찾아내는 것입니다. 작동하지 않는 것은 무엇입니까? 미래의 어느 시점에서 모든 사람들이 우리 모두가 모든 레거시 및 미래의 경우에서 작동하는 무언가에 도달했다고 생각할 때,이를 구현할 수 있고 (사용자) 커뮤니티가 작동 방식을 설명 할 수 있습니다. 현재 IMHO에 대한 팀의 답변을 기대하기에는 너무 이르다.

여러분이 제공하는 사용 사례와 @avocadesign이 제공하는

귀하의 예와 관련하여 내 제안 (위의 몇 가지 반응 참조)은 스크린 샷에 표시된 모든 상자를 표시합니다 (물론 새로운 Gutenberg 스타일).

안녕하세요.

Gutenberg는 CPT가 현재 편집자에 대한 지원을 선언하지 않는 것과 마찬가지로 CPT를 선택할 가능성이 높습니다. WordPress의 대부분이 매우 유연하기 때문에 CPT를 선택하지 않는 이유를 모르겠습니다. Gutenberg도 다르지 않을 것입니다. 현재 게시물에 대해서만 작동합니다.

나는 구텐베르크가 이와 같은 인터페이스에 대해 전혀 변경하지 않을 것이라고 확신하지 않으며 의도도 아닙니다. 즉, Gutenberg가 제공하는 기능을 탐색하고이를 사용하여 고객에게 더 매력적인 편집 경험을 만들 수 있는지 확인하는 것은 흥미로울 수 있습니다.

예를 들어, 속성 / 속성 블록을 생성하여 클라이언트가 속성 정보를 다른 게시물 등에 빠르고 쉽게 삽입 할 수 있도록 할 수 있습니다. 그런 다음 Gutenberg에서 편집하는 동안 Gutenberg 내부에 표시되는 속성 정보를 보면서 ACF에서 보는 것과 동일한 정보를 변경할 수 있습니다. Gutenberg는 WordPress의 관리 인터페이스를 추월하지 않으며 편집기의 기능을 대체하고 있으며 블록 기반 콘텐츠 템플릿으로 이어질 가능성이 높습니다.

두통이 아닌 구텐베르크에서 좋은 것들이 나옵니다!

다음은 post_content 위에 ACF 필드가 있고 post_content 아래에 The Events Calendar 표준 메타 상자가있는 위에서 언급 한 사이트의 이벤트 편집 화면입니다.

이 사이트는 많은 비 기술 사용자에게 공개 될 것입니다. 우리는 훈련 된 편집 팀을 말하는 것이 아닙니다. 우리는 이전에 워드 프레스를 사용한 적이 없거나 사이트에서 제공하는 도움 외에는 훈련을받은 적이없는 조 평균을 말하는 것입니다.

사용자가 이벤트 유형, 카테고리, 헤더 및 각 이벤트에 대한 추천 이미지를 찾아 입력 할 수 있도록이 방법을 설정했습니다. 또한 기존 메타 박스 위치를 사용하여 화면에 관련 도움말 문서를 제공하여 이벤트를 편집하고 새 사용자에게 방해가되지 않는 방식으로 지원을 제공 할 수 있습니다.

또한 우리는 관리자로 로그인되어 있으며, 관리자가 아닌 사용자는 시각적 혼란을 더욱 줄이기 위해 다양한 사이드 바 메타 상자를 숨겼습니다.

"콘텐츠"는 이벤트에 성공적으로 참가하기위한 다양한 메타 상자만큼 관련성이 없습니다. 날짜를 정확하게 입력하지 않았거나 카테고리를 선택한 경우 이벤트가 사이트에 표시되지 않습니다. 이 전체 토론에 대해 저를 걱정하는 것은 메타 상자가 접을 수있는 섹션에서 화면 하단으로 내려가는 문제 # 1352와 같은 모형입니다. 경험에 비추어 볼 때, 훈련을받지 않은 사용자는 메타 상자를 보지 않고 콘텐츠 영역에 일반 텍스트로 날짜와 위치를 직접 입력 한 다음 이벤트가 시스템에 표시되지 않는다고 불평하는 것뿐입니다. 구조화 된 정보를 필요로하는 게시물 유형의 교육을받지 않은 사용자에게는 검색이 충분하지 않습니다.

또한이 인터페이스에는 필수 필드가 있으며 메타 상자가 축소되면 사용자는 경고를 받지만 문제의 원인을 쉽게 찾을 수 없습니다.

메타 박스 또는 그 기능 유형의 다음 반복은 일류 시민이어야하며 클라이언트가 사용할 수있는 인터페이스를 만들기 위해 콘텐츠 위, 콘텐츠 옆 또는 콘텐츠 아래에 배치 할 수있는 기능이 필요합니다.

Gutenberg는 CPT가 현재 편집자에 대한 지원을 선언하지 않는 것과 마찬가지로 CPT를 선택할 가능성이 높습니다.

구텐베르크에 대한 지원을 CPT에 등록하는 것은 확인되지 않았으며 솔직히 메타 박스 문제를 해결하는 것보다 피하는 것 같습니다. 기존 사이트가 Gutenberg에 액세스하는 유일한 방법이 코드로 지원을 등록하는 것이라면 잠재적 인 청중을 심각하게 제한 할 것입니다.

또한 사용자 지정 메타 상자가 사용자 지정 게시물 유형에만 사용되는 척해서는 안됩니다. 그들은 일반 게시물과 페이지에 존재할 가능성이 큽니다.

Gutenberg는 WordPress의 관리 인터페이스를 추월하지 않고 편집기의 기능을 대체하고 있습니다.

이것은 정확하지 않습니다. 오늘날 존재하는 것처럼 Gutenberg는 포스트 편집 화면을 전체 화면으로 대체합니다.

@ BE-Webdesign 및 @kevinwhoffman

또한 CPT가 현재 편집 화면보다 분명히 더 나은 구텐베르크의 측면을 놓쳐 야하는 이유는 무엇입니까?

콘텐츠와 혼동되지 않도록 게시 컨트롤이 맨 위로 이동하고 전체적인 미학이 깔끔 해져이 프로젝트가 진행되는 곳의 강점입니다.

복잡한 요구 (메타 박스를 통해)를 가진 CPT에 대해 현재있는 것과 동등한 기능을 만드는 방법에 대한 적절한 계획이 없음으로써 우리는 사용자 기반의 많은 부분을 무시하고이를 두 번째 클래스로 강등시켜 궁극적으로 지원되지 않는 경험입니다.

그냥 평범한 IMHO.

메타 박스가 현재 존재하는대로 즉시 작동해야한다고 주장하는 것도 아닙니다. 이러한 종류의 인터페이스 유연성을 구현하는 새롭고 더 나은 방법이있을 수 있습니다.

제가 우려하는 것은 개발팀이 여기에서 "post_content"첫 번째 접근 방식을 시행하는 많은 개발자의 문제를 실제로 파악하지 못하는 것 같습니다. 우리는 구조화 된 데이터 출력이 필요한 CPT를 제외한 모든 사이트에서 Beaver Builder를 사용합니다. Gutenberg가 말하는 페이지 구축 도구는 개별 콘텐츠가 필요한 게시물과 페이지에 적합합니다. 구조화 된 데이터에는 끔찍합니다. 구조화 된 데이터의 경우 인터페이스 일관성, 필수 필드 및 기타 레이아웃 우선 순위가 항상 자유 형식 콘텐츠보다 우선합니다.

안녕하세요.

또한 사용자 지정 메타 상자가 사용자 지정 게시물 유형에만 사용되는 척해서는 안됩니다. 그들은 일반 게시물과 페이지에 존재할 가능성이 큽니다. 이것은 정확하지 않습니다. 오늘날 존재하는 것처럼 Gutenberg는 포스트 편집 화면을 전체 화면으로 대체합니다.

예,하지만 제가 언급 한 전체 관리자 인터페이스를 대체하는 것은 아닙니다. 불완전한 프로젝트를 현재 경험과 비교하고 있습니다. # 2251이 완료되면 전능 한 메타 상자를 다시 도입하므로 크게 다르지 않을 것이며 훨씬 더 나아질 것입니다. 특정 플러그인 작성자가 조정해야 할 사항이있을 수 있지만 대부분의 경우 작업이 원활하게 진행될 것이라고 확신합니다.

안녕하세요.

또한 CPT가 현재 편집 화면보다 분명히 더 나은 구텐베르크의 측면을 놓쳐 야하는 이유는 무엇입니까?

아무도 그들이 내 지식에 있다고 말하지 않았습니까? CPT에 대한 편집기 지원을 추가하는 것과 블록 편집기에 대한 지원을 추가하는 것에는 큰 차이가 없습니다.

복잡한 요구 (메타 박스를 통해)를 가진 CPT에 대해 현재있는 것과 동등한 기능을 만드는 방법에 대한 적절한 계획이 없음으로써 우리는 사용자 기반의 많은 부분을 무시하고이를 두 번째 클래스로 강등시켜 궁극적으로 지원되지 않는 경험입니다.

적절한 계획이 있다고 생각합니다. 분명하지 않을 수도 있지만 구텐베르크가 모든 유형의 사용자 대부분의 요구를 충족시킬 것이라고 확신합니다.

아무도 그들이 내 지식에 있다고 말하지 않았습니까? CPT에 대한 편집기 지원을 추가하는 것과 블록 편집기에 대한 지원을 추가하는 것에는 큰 차이가 없습니다.

구텐베르크가 CPT에 옵트 인하는이 스레드에서 많은 사람들이 언급 한 단계로 인해 현재의 복잡한 사용 사례 중 상당수가 구텐베르크에서 단기에서 중기 적으로 무시되고 이벤트와 같은 사용 사례를 효과적으로 강제 할 수 있습니다. 구텐베르크는 충분히 유연하지 않기 때문에 기존 시스템을 사용하기 위해 위에서 설명한 것입니다. 이는 현재의 복잡한 사용 사례가 프로젝트의 다른 이점을 놓치게 만드는 것입니다.

우리는 "걱정하지 마세요. 괜찮을 것입니다"라는 말을 많이 듣지만 우리 중 일부에게는 계획이 전혀 명확하게 제시되지 않는다고 제안 할 때 @ BE-Webdesign이 맞습니다. 이 문제가 단기적으로 만족스럽게 해결 될 수있는 모든 방법-만약 그것이 저를 계몽하기 위해 토론이나 문제를 가리켜 주시기 바랍니다.

편집하다:
내가 말하는 "단기"는 5.0을 대중에게 공개하는 것입니다. 2018 년 초가 목표 인 것 같습니다. 2 ~ 3 년 후에는이 문제가 훨씬 더 성공적으로 해결되는 것을 볼 수 있습니다.

@BennyVL & @dmccan 유연성이 여기서 핵심 문제입니다. 내가 틀렸다면 정정하십시오.하지만이 작업을하는 개발자들이 제안한 것은 현재 우리가 가지고있는 것만 큼 유연하지 않습니다.

ACF 및 기타 플러그인을 사용하면 콘텐츠 위 (제목 아래), 콘텐츠 아래 및 사이드 바에 메타 박스를 쉽게 등록 할 수 있습니다. 인터페이스 디자인은 나에게 달려 있습니다. 편집자가 첫 번째라는 것을 강요하지 않으며 편집자가 참석할 것을 요구하지 않습니다. 새 메타 박스를 등록하고 다른 메타 박스를 등록 취소하거나 이동할 수 있습니다.

내가 원하는 것은 장기적으로 이러한 유연성을 유지하는 솔루션입니다. 메타 박스를 반짝이는 새로운 JS 형식으로 업데이트해야하는지, 적절한 블록이되어야하는지, 또는이를 가능하게하기 위해 다른 변경이 필요한지 여부는 나를 괴롭히지 않습니다. 저는 구텐베르크에 도달하는 데 사용 된 방법에 관계없이 현재 우리가 누리고있는 유연성이 구텐베르크에 포함되기를 바랍니다.

내가 원하는 것은 장기적으로 이러한 유연성을 유지하는 솔루션입니다. 메타 박스를 반짝이는 새로운 JS 형식으로 업데이트해야하는지, 적절한 블록이되어야하는지, 또는이를 가능하게하기 위해 다른 변경이 필요한지 여부는 나를 괴롭히지 않습니다. 저는 구텐베르크에 도달하는 데 사용 된 방법에 관계없이 현재 우리가 누리고있는 유연성이 구텐베르크에 포함되기를 바랍니다.

그것이 목표이며 대부분의 사람들이 원하는 것입니다.

메타 박스 문제와이 새로운 편집기를 통해 어떤 일이 일어날 지에 대해 많은 이야기를 들었습니다. 내 개인적인 견해는 구텐베르크가 전체 페이지 편집 화면이 아니라 편집자 에만 초점을 맞춰야한다는 것입니다. 그러나 이미 결정된 것 같습니다.

안녕하세요 여러분,

저는 Carbon Fields의 수석 개발자이며 영향을받을 수있는 작업 / 필터 목록을 추가하고 싶었습니다.

필터 :

• postbox_classes_{$page}_{$id}

행위:

• init
• admin_menu
• admin_init
• wp
• admin_enqueue_scripts
• in_admin_header
• admin_notices
• admin_print_footer_scripts
• save_post
• edit_comment
• media_buttons
• edit_form_after_title (설탕 배치-중요하지 않음)

내 질문 :

• 레거시 메타 박스를 유지한다면 데이터 변경과 어떻게 상호 작용할까요?
• 어떤 유형의 이벤트 (jQuery? 일부 노출 된 이미 터 구현?)와 새 편집기에서 정확히 어떤 이벤트를 기대할 수 있습니까 (예 : 제출 성공, 실패 등)?
• 이러한 이벤트는 레거시 메타 박스에서 사용할 수 있습니까, 아니면 React 구현에서만 사용할 수 있습니까?

추신:
모든 노력과 노력에 대해 구텐베르크 팀에게 감사하고 싶습니다. WordPress가 최신 도구와 솔루션으로 이동하고 있다는 사실에 기쁩니다 (여정이 무섭게 느껴지더라도)!

메타 박스 지원은 매우 중요합니다 ...

... 수천 명의 워드 프레스 개발자와 사용자를 위해.

WordPress는 큰 플러그인 플레이어를 무시할 수 없습니다 ...

... Advacend Custom Fields Pro (https://github.com/elliotcondon/acf/issues/622), WooCommerce 또는 Yoast SEO와 같습니다.

사용자 지정 형식, 필드 및 분류를 많이 사용하는 도구 집합 프로젝트를 담당하고 있습니다.

우리는 플러그인이 Gutenberg와 호환되도록 만들고 싶습니다.

이것이 내가 이해하는 것입니다.

• Gutenberg를 사용할 때 페이지와 게시물에 사용자 정의 필드와 분류를 표시하려면 새 API를 사용해야합니다.
• CPT를 위해 Gutenberg에 대해 아무것도 할 필요가 없습니다. 그들은 Gutenberg가 아닌 일반 WordPress 편집기를 사용하기 때문입니다.

이 올바른지? 그렇다면 Gutenberg에 사용자 정의 상자를 표시하는 데 필요한 API 설명서를 참조 해 주시겠습니까?

나는 문서가 여전히 진화하고 있다고 생각합니다. 에서 일부 문서가 있습니다 https://github.com/WordPress/gutenberg/tree/master/docs - http://gutenberg-devdoc.surge.sh/은

@ BE-Webdesign과 다른 사람들이 중단을 최소화하려는 의도에 대해 말하는 것을 듣고 있습니다. 감사합니다. 안심할 수 있습니다.하지만 제 5p의 가치를 추가하고 싶었습니다 (좋아요, 평소에 사용하는 105p의 가치).

한동안 개발해 온 사람이라면 누구나 맞춤형 데이터베이스를위한 웹 인터페이스를 수동으로 생성하는 고통을 기억할 것입니다. 지루하고 시간 소모적이며 오류가 발생하기 쉬우 며 개발자 시간 측면에서 매우 비쌉니다.

WordPress와 Advanced Custom Fields (Pro)는 매력적인 프런트 엔드, 엄격한 데이터 입력 확인, 직관적이고 일관된 사용자 인터페이스 등을 사용하여 맞춤형 데이터베이스 기반 웹 사이트 (및 인트라넷 데이터 관리 도구)를 효율적으로 만드는 데 유용한 도구입니다. 이러한 시스템은 그렇지 않을 수 있습니다. 방대한 양의 관계형 데이터에 대해 확장 가능하지만 매우 많은 경우에 그럴 필요가 없습니다. 클라이언트를 위해 비용 효율적인 방식으로 만들 수있는 간단한 시스템입니다. 이것이 WordPress를 블로그 플랫폼이 아닌 정말 유용한 CMS (실제로는 가벼운 RDBMS)로 만드는 이유입니다.

저 (그리고 다른 많은 중소기업)에서 WP + ACF (또는 유사한 사용자 지정 데이터 플러그인)를 사용하여 큰 IT 예산이없는 고객 조직 및 개인을위한 맞춤형 사이트 및 시스템을 만듭니다. 구텐베르크의 도입이 기존의 편집 / 데이터 입력 흐름, 메타 박스 등을 지원하는 데 대한 충분한 고려없이 이루어 졌다면 두 가지 "비 기술적"이지만 그럼에도 불구하고 중요한 문제가 있습니다.

1 / 내 최종 사용자는 재교육이 필요할 것입니다 (기술자로서 비 기술적 사용자가 인터페이스 변경으로 얼마나 혼란 스러울 수 있는지 잊는 것은 쉽습니다. 분류하는 데 너무 많은 시간을 낭비하고 있기 때문에 Clarify Password Reset 플러그인을 작성했습니다. 4.3에 도입 된 새로운 암호 재설정 프로세스로 인해 완전히 방해받은 사용자).

2 / 다른 메타 박스 접근 방식을 위해 자체 플러그인을 업그레이드하는 것 외에도 전문적인 수준의 성실함으로 모든 클라이언트 사이트를 업그레이드하고 테스트하는 데 시간을 투자하여 모든 타사 플러그인이 있는지 확인해야합니다. 를 사용하여 코드베이스를 올바르게 업데이트했습니다. (그리고 5.0 릴리스 이전 또는 이후 언젠가는 타사 플러그인이 얼마나 빠르게 업데이트되는지 제어 할 수없는 상황에서 워크로드 계획이 정말 어려워집니다.)

위의 어느 경우에도 추가 작업에 대해 고객에게 추가 비용을 청구하는 것이 옳다고 생각하지 않습니다. 결국 저는 사이트와 시스템을 구축 할 플랫폼을 선택했는데 변경이나 개선을 요청한 것과는 다릅니다. 어쩌면 내가 "너무 착하고"그런면에서 순진 할 수도 있지만, 사람들이 위에서 언급했듯이 그것은 신뢰의 문제입니다. 우리는 워드 프레스가 이전 버전과의 호환성을 깨뜨려 우리를 똥에 빠뜨리지 않기를 믿습니다. 그래서 우리 고객은 예상치 못한 추가 비용으로 그들을 찌르지 않도록 우리를 신뢰할 수 있습니다. 결과적으로 나는 갑자기 엄청난 양의 추가 무급 작업을하게되며, 업그레이드로 인해 사이트가 즉시 중단되는 경우 급하게 작업 할 수 있습니다.

저는 워드 프레스 사용을 정말 좋아하고, 로프를 배우고, 편리한 프로젝트 프레임 워크 등을 개발하는 데 많은 시간을 투자했습니다. 이제 워드 프레스 기반 개발 프로젝트를 통해 제 삶을 최대한 활용하고 (가족에게 먹이를주는 등) 많은 시간을 투자했습니다. 나는 또한 OSS, 커뮤니티 기반 개발 등을 소중히 여기기 때문에 WordPress.com에 개발 한 유용한 작은 플러그인을 공식적으로 릴리스하는 데 시간을 할애하여 무언가를 돌려 보려고 노력했습니다. 이것은 대부분 문제를 해결하기위한 탄원이라고 생각합니다. 이 문제에서 가능한 한 많이 마음에 새겨 넣었습니다. 그렇지 않으면 코드베이스가 분기 될 수있는 실제 위험이 있다는 데 동의합니다. WordPress 팬이자 플러그인 기여자로서 저는 이것이 정말 나쁜 결과라고 생각합니다. 그러나 WP에 의존하는 솔로 개발자로서 저는 경제적 필요성 때문에 포크 버전 (즉, 이전 버전과 호환되는 버전)을 사용해야 할 수도 있습니다. 이런 일이 일어나지 않게하십시오!

@konamac 은 몇 가지 훌륭한 포인트를 제공하며 그중 일부는 다른 스레드에 게시했습니다.

이를 피기 백하기 위해 메타 박스의 미래에 대해 안심할 수있는 답변을 제공하지 않는 것은 전적으로 용납 할 수 없습니다.

1. 기존 메타 박스의 향후 지원에 대한 직접적인 대답은 없습니다. 이것은 개발 에이전시와 테마 / 플러그인 작성자에 대한 매우 실망스럽고 무거운 핸드입니다. "Gutenberg는 오픈 소스이므로 스스로 알아 내십시오" 는 무책임합니다.

2. 구텐베르크는 굉장합니다. 저는 인터페이스, 비주얼 디자인을 좋아하고 이것이 콘텐츠 편집 측면에서 미래의 방식이라고 생각합니다. 그러나 4.9 또는 5.0 릴리스를 고려하기 위해 필요한 위치에 훨씬 뒤쳐져 있습니다.

3. 내가 유산에서 할 수있는 모든 것은 구텐베르크에서 할 수있는 모든 것입니다.

4. 화면 옵션
5. 메타 박스 (ACF, Yoast 등)
6. 퍼머 링크?! 아직 1.0에서 편집 할 수없는 이유를 이해할 수 없습니다.
7. 클래식 컨텐츠 블록이 localhost 환경에서 제대로로드되지 않습니다.
8. 다른 스타일 블록을 생성하려면 문서가 핵심이어야합니다. 몇 가지 예와 몇 가지 사용 사례를 제공합니다. 모든 테마 개발자가 백엔드는 아니므로 가정하지 마십시오. 명확하게
9. 차단 설정은 작업이 필요합니다. 블록 당 어떤 설정을 사용할 수 있는지 말하기는 매우 어렵습니다. 무작위로 보입니다. 블록 설정을 편집해야하는 경우와 편집하지 않는 경우는 언제입니까?
10. Gutenberg 텍스트 편집기 주변의 전체 주석 태그는 ...보기에 슬프다.

우리 중 일부는이 과정에 극도로 좌절하고 있습니다. 죽은 간단한 대답이어야합니다.

구텐베르크는 메타 박스 / ACF의 현재 사용을 보호 할 것이며 이러한 지원을 무기한으로 보장 할 계획이 있습니까?

지금 당장 솔루션이 무엇인지 알 필요가 없습니다. 고객이 해결하고 있다는 것을 알고 있습니다. 그러나 우리는 이것에 대한 명확한 답을 아직 가지고 있지 않습니다. 특히 ACF는 업데이트 비용에 동의하지 않는 이전 클라이언트를 지원해야하는 것과 똑같은 방식으로 작동해야합니다. )

구텐베르크 사랑 . 그러나 나는 합창단에 가입해야한다. 이것은 우스꽝스러워지고있다. 프로젝트 팀이 이러한 기대치를 전달하는 방식은 간단하지 않았습니다. 예 또는 아니오는 우리가 찾고있는 전부입니다.

@ BE- 웹 디자인

완료되면 전능 한 메타 상자를 다시 소개합니다.

따라서이 문제에 대한 전체 게시물을 작성하고 실제로 표시 한 메타 상자는 현재 상태 그대로 유지 될 것이라고 제안 할 수 있습니까? 이것은 자신의 비즈니스에 대해 걱정하는 커뮤니티의 많은 걱정 개발자를 방지합니다.

또한 팀이이를 우선적으로 추가하여 지금 추가하도록 권장합니다. 이것은 내가 확신하는 프로젝트에 대한 많은 부정성을 막을 것입니다.

# 2308에서 언급했듯이 사용자 정의 필드를 생성 / 저장할 때 Meta Box 플러그인이 사용하는 후크를 복사했습니다.

• 스크립트, 스타일은 admin_enqueue_scripts 사용하여 대기열에 추가됩니다. 현재 화면 ( get_current_screen 을 통해)을 확인하여 해당 페이지에 대해서만 스크립트와 스타일이 대기열에 포함되었는지 확인합니다. 핵심 플러그인의 경우 게시물 유형별로 확인합니다. 확장 (용어 메타, 사용자 메타, 설정 페이지)의 경우 분류, 사용자 프로필 페이지 또는 설정 페이지를 더 많이 확인합니다.
• 또한 print_media_templates 를 사용하여 밑줄 템플릿을 인쇄합니다.
• 플러그인에서 사용하는 스크립트에는 색상 선택기, 밑줄, 백본, 미디어 스크립트, tinymce (편집기 필드 용)가 포함됩니다.
• 플러그인의 모든 후크를 초기화하기 위해 init 를 사용합니다.
• 메타 상자는 add_meta_boxes 후크를 사용하여 등록됩니다.
• 숨겨진 메타 상자는 default_hidden_meta_boxes 합니다.
• 또한 post_edit_form_tag 하여 파일 업로드를 허용합니다.
• save_post_{$post_type} 및 edit_attachment , add_attachment 을 사용하여 게시물 및 첨부 파일의 메타 값을 저장합니다.

구텐베르크의 위 / 아래 / 사이드 바에 메타 박스를 표시하기 위해 후크를 구축하는 것이 잘못된 이유는 무엇입니까?

타사 개발자가 가장 잘하는 일을 수행하고 작업에 또 다른 거대한 렌치를 던지는 것이 나을 것이라고 생각했습니다.

Mattias는 메타 박스를 post_meta에 저장하는 블록으로 재구성 할 수 있다고 말합니다. 이것이 병합의 목표라면 해결해야 할 몇 가지 문제가 있습니다.

많은 메타 박스가 the_editor($custom_id); 를 등록하여 구텐베르크의 맥락에서 지원되도록합니다. 첫날부터 중첩 된 블록을 생성하기위한 인터페이스와 API가 필요하거나 메타 박스가 2 급 편집기 인터페이스 만 가질 수 있다고 말합니다. , 블록의 이점이 없습니다. 이는 현재 ACF Flexible Layouts을 사용하여 설계하는 다수의 에이전시에게 특히 문제가 될 것입니다. 다양한 컨텍스트 및 영역에 대해 별도의 Gutenberg 블록을 생성하는 방법이 필요하기 때문입니다. "블록으로 생각하기"조차도 첫날부터 "메타 블록"에서 중첩을 지원하지 않고 "콘텐츠 영역 다음에 템플릿 부분 다음에 콘텐츠 영역"문제를 해결할 수있는 좋은 방법을 찾지 못합니다.

그로부터 파생되는 것은 post_content에 저장되지 않은 블록과 관련된 중첩의 기술적 문제입니다. Mattias는 블록이 postmeta에 저장할 수 있지만 블록이 저장 위치를 ​​정의 할 수있는 경우 중첩 작동 방식, 상위 블록이 postmeta에 저장하고 사용자가 다른 post_meta에 저장하는 하위 항목을 추가 할 때 어떻게 작동 할 것이라고 말합니다. (또는 병리학적인 경우, Tha가 postmeta에 저장하는 중첩 된 블록은 동일한 postmeta 필드에 저장되는 블록을 포함합니다.

이로 인해 세 번째 메타 박스 문제가 발생합니다. Gutenberg가 the_editor() 의 대체가 아니라 전체 편집 페이지 대체 인 경우 사람들은 the_editor() 를 사용하는 메타 박스 또는 사용자 정의 관리 패널과 같은 다른 컨텍스트 및 다른 페이지에서 블록을 대기열에 추가하고 사용할 수 있습니다

사용자에게 구텐베르크의 선택권이 주어지고 주장한대로 혁신적이라면 이러한 경우에 새로운 인터페이스를 제공하지 못하는 것은 대행사에게 재앙을 초래할 수 있습니다.

기존 메타 박스의 향후 지원에 대한 직접적인 대답은 없습니다.

나는 반복해서 우리가 메타 박스를 설명하겠다고 말했다. 유일한 불확실성은 기술적으로 실행 가능한 항목과 새 UI에 표시되는 방법입니다.

우리는 단축 코드, 사용자 정의 필드 등 어떤 것도 깨뜨 리려고하지 않습니다. 모든 것이 여전히 작동해야합니다. 이들과 상호 작용하는 UI는 변경 될 수 있으며 (구텐베르크를 완전히 비활성화하지 않는 한) 메타 박스에 대한 특정 사용 사례는 향후 블록에 더 적합 할 것입니다.

구텐베르크는 굉장합니다. 저는 인터페이스, 비주얼 디자인을 좋아하고 이것이 콘텐츠 편집 측면에서 미래의 방식이라고 생각합니다.

듣고 기뻐요!

퍼머 링크?! 아직 1.0에서 편집 할 수없는 이유를 이해할 수 없습니다.

REST API는 아직이를 지원하지 않기 때문입니다. 모든 도움을 환영합니다 : https://github.com/WordPress/gutenberg/issues/1285

나는 반복해서 우리가 메타 박스를 설명하겠다고 말했다.

@mtias 메타 박스 지원에 관한 혼란은 기존 기능을 복원하는 데 레거시 플러그인을 사용할 수 있다는 @m의 결과라고 생각합니다. 기존 인터페이스의 어떤 측면 (메타 박스, 메타 박스 위치, 후크 등)이 계속해서 구텐베르그와 함께 작동하는지와 레거시 플러그인이 계속 작동해야하는 측면을 명확히하는 것이 도움이 될 것입니다.

나는 반복해서 우리가 메타 박스를 설명하겠다고 말했다.

@mtias 내 사과, 다른 곳에서 설명을 놓친 것 같습니다. 다행! 현재 반복을 시각적으로 더 매력적이고 목적에 맞게 만들면 큰 성공을 거둘 것입니다.

REST API 지원에 대해 말씀하신 내용을 이해합니다. 스레드에서 업데이트를 확인하겠습니다.

명확히 해주셔서 감사합니다. 이제이 통찰력을 얻었으므로 구텐베르크를 위해 전속력을 발휘하고 있습니다. 모든 두려움은 제쳐두고 있습니다.

@kevinwhoffman 맞습니다. 문제의 핵심은 "기존 기능"에도 프레젠테이션이 포함되어 있다는 것입니다. 구텐베르크가 UI를 크게 변경하기 때문에 이전 버전으로 돌아가려면 플러그인을 비활성화해야합니다. 메타 박스가 새 UI에 어떻게 적합하고 개발자 개입없이 이전 메타 박스를 지원할 수 있는지는 작업중인 것입니다. 어떻게 될지 정확히 모르기 때문에 구체적인 결과를 약속 할 수 없었습니다. 또한 이것이 메타 박스 기능을보다 명확하게 표현할 수 있다고 생각합니다.

@brograhamer 사과가 필요하지 않습니다. 큰 스레드입니다! 우리는 아무것도 서두르고 싶지 않습니다. 이것은 움직이는 부분이 많은 꽤 큰 프로젝트입니다. 때때로 일부는 무시되는 것처럼 보일 수 있지만 그렇다고해서 문제를 해결할 계획이 없다는 의미는 아닙니다.

현재 tinymce 편집기를 사용하지 않는 10 개의 사용자 지정 게시물 유형으로 ACF를 사용하여 웹 앱을 구축하고 있습니다. 저는 제목 기능과 각 CPT에 대해 평균 약 15 개의 ACF 필드를 사용하고 있습니다.
현재 CPT가 지원하는 기능 (예 : 편집기, 썸네일, 발췌 등)을 선언 할 수 있습니다.
편집 화면에서 "스토리 쓰기"단락 블록과 "블록 삽입"아이콘을 숨기거나 제거 할 수 있습니까?

@ cr101 CPT 지원에서 "편집기"를 삭제하면 아마도 블록 삽입

반면에 메타 박스 v1을 사용하면 메타 박스 창을 아래쪽에서 확장 할 수 있습니다.이를 유지하면 "편집기"지원이없는 CPT에 대해 항상 "열려"있어야합니다. 메타 박스가 항상 편집기 아래에 표시되는 경우에는 필요하지 않을 수 있습니다 (위의 일부 디자인 제안처럼).

이것이 적합한 장소인지 확실하지 않지만 핵심 사용자 지정 메타 필드는 어떻습니까? 타사 플러그인에 대해 많은 이야기가 있었지만 핵심 사용자 지정 메타 필드는 어떻습니까? 나는 그것들이 그렇게 인기가 없다는 것을 알고 있지만 내가 작업 한 몇 개의 사이트를 생각할 수 있습니다.

핵심 사용자 지정 메타 필드를 구텐베르크에 통합하기위한 계획이 있습니까?

안녕하세요 @jawittdesigns ,

핵심 메타 박스 (최소한 대부분)가 이미 구텐베르크에서 다시 구현되었다고 확신합니다! 분류법 등을 처리하는 데 더 좋은 작업 흐름이 있습니다.

모든 사람이 블로그에 WordPress를 사용하는 것은 아닙니다. 우리 중 많은 사람들이 WordPress를 CMS로 사용합니다. 현재 WordPress REST API 및 ACF를 사용하여 웹 앱을 구축하고 있습니다. 10 개의 사용자 지정 게시물 유형이 있고 각 CPT에는 20 개의 사용자 지정 필드가 있으며 모든 CPT는 ACF 관계 및 게시물 개체 필드와 ACF Post-2-Post 플러그인을 사용하는 양방향 관계를 통해 서로 연결됩니다

구텐베르크는 현재 편집기를 사용하지 않기 때문에 현재 형식으로는 쓸모가 없습니다. CPT에 제목 텍스트 상자 만 사용하고 나머지는 post_meta 테이블에 저장되는 사용자 정의 필드입니다.

저는 구텐베르크 편집자가 현재 상태에서 핵심의 일부가되어서는 안된다고 강력하게 믿습니다. 나는 워드 프레스를 프로젝트로서 자신의 사용자 정의 테마로 작업하지 않는 사이트 빌더에게 어느 정도 플레이해야한다는 것을 알고 있습니다. 그러나 구텐베르크 편집자는 고급 사용자 정의 필드를 사용하여 컨텐츠를 복잡하게 입력하는 사용자에 대한 직접적인 공격 인 것 같습니다. 사이트 소유자에게 콘텐츠를 입력하는 매우 구체적인 방법을 제공함으로써 상당히 "멍청한 증거"를 제공합니다. 현재 상태의 구텐베르크 편집자는 ACF를 사용하는 우리들에 대한 직접적인 공격 인 것 같습니다.
Gutenberg 플러그인을 사용하면 헤더의 편집 링크가 사용자를 구텐베르그 인터페이스로 직접 보냅니다.이 인터페이스는 ACF 메타 상자를 표시하지 않으며 화면 상단에 활성화 할 화면 옵션 탭이 없습니다. 예, 사용자는 페이지 / 포스트 배열로 돌아가서 "클래식 편집기"옵션을 선택한 다음 메타 상자를 볼 수 있지만 이는 사이트 편집기가 ACF 필드로 이동하기 위해 추가 단계를 수행해야 함을 의미합니다. 많은 경우에 ACF를 사용하는 목적이 비 기술적 인 편집자를 위해 복잡한 레이아웃을보다 유연하고 간단하게 편집하는 것이 었음을 고려할 때 정확히 최적은 아닙니다.

이것은 얼마나 오래 지속되는 문제였습니까!

# 3345와 # 3554의 병합으로 메타 박스 지원은 _feature complete_라고 부르게되어 기쁩니다. 특히 스타일링, 더 복잡한 JavaScript 처리 및 클래식 편집기로 돌아 가기위한 규칙 결정과 관련하여 메타 박스 경험을 다듬기 위해 수행해야 할 작업이 분명히 남아 있기 때문에 이것은 _complete_와 다릅니다.

이 문제에 건설적으로 참여 해주신 모든 분들께 감사 드리며, 어렵고 때로는 논란의 여지가있는 과정이라는 것을 이해합니다. Gutenberg가 메타 상자를 처리하는 방법과 메타 상자를 Gutenberg와 호환되지 않는 것으로 표시하는 방법 (원하는 경우)에 대한 문서는 핸드북을 참조하십시오.

특정 플러그인 또는 메타 상자와 관련된 버그가 발생하는 경우 올바르게 추적하고 수정할 수 있도록 새 문제를여십시오.

이는 기능 완성과는 거리가 멀어 야합니다.

@coffeeneed 건설적인