Gutenberg는 CPT에 의해 선언된 편집기 지원을 존중하며 지원되지 않는 경우 로드되지 않습니다.

이것이 구텐베르크가 전혀 로드되지 않고 대신 클래식 편집기가 사용된다는 것을 의미한다면 구텐베르그와 클래식 환경 간에 분할된 분열된 WP 관리자로 향하는 경로를 설정합니다. 이것은 여러면에서 WordPress에 나쁠 것입니다.

• 새로운 사용자는 두 가지 유형의 인터페이스가 서로 다른 주요하고 미묘한 방식을 배워야 합니다. 게시물을 게시하거나 텍스트 보기로 변경하는 것과 같은 간단한 작업은 Gutenberg 및 Classic 편집기에서 다르게 작동합니다.

• 기존 개발자는 두 환경 모두에서 테마와 플러그인의 기능을 유지해야 합니다. 전환 기간에 대해 이야기하는 것이 아닙니다. 우리는 무기한 이야기하고 있습니다. 모든 게시물 유형을 확장하기 위한 플러그인이 가장 큰 영향을 받습니다. 해당 개발자가 결국 메타 상자를 블록으로 변환하는 경우 누군가가 구텐베르그가 아닌 게시물 유형에서 플러그인을 사용하는 경우를 대비하여 이전 메타 상자를 유지해야 합니다.

• WordPress 개발에 입문하는 새로운 플러그인 개발자는 두 가지 다른 방법으로 플러그인을 빌드하는 방법을 배워야 합니다. Gutenberg 블록을 수용한다고 가정하면 플러그인 기능은 Classic 편집기를 사용하는 게시물 유형에서도 사용하지 못할 수 있습니다.

메타 박스를 작동시켜야 한다고 생각하는 한 단순히 Gutenberg를 끄는 것이 장기적으로 최상의 솔루션은 아닙니다.

이것이 구텐베르크가 전혀 로드되지 않고 대신 클래식 편집기가 사용된다는 것을 의미한다면 구텐베르그와 클래식 환경 간에 분할된 분열된 WP 관리자로 향하는 경로를 설정합니다.

CPT가 편집기를 전혀 활성화하지 않으려는 경우에는 이것이 최선의 경로인 것 같습니다. 단순히 다른 경험에 최적화된 다른 관리자 보기입니다. (예를 들어 Woo의 "orders" 보기.) 누군가 Gutenberg 컨텍스트 내에서 렌더링하려고 시도하는 데 도움이 되지 않습니다.

이는 Customizer의 출현과 유사합니다. 다른 컨텍스트에서 동일한 작업을 수행하는 새로운 인터페이스 패러다임이었습니다. 우리는 항상 "관리" 인터페이스와 "편집" 인터페이스가 필요합니다. 이것이 부분적으로 인터페이스의 다양한 목적을 명확히 함으로써 우리가 앞으로 나아가는 방법입니다.

그러나 Gutenberg의 범위 이동 때문에 단순히 편집기 유형을 활성화하거나 비활성화하는 것이 아닙니다. 이제 구텐베르크가 전체 편집 인터페이스를 결정하므로 위에 나열한 편집기 유형과 관련된 전체 부작용 목록이 있습니다.

우리는 항상 "관리" 인터페이스와 "편집" 인터페이스가 필요합니다.

이것이 바로 오늘날 에디터와 메타 박스가 수행하는 역할입니다. 그것들은 고립된 경험이 아닙니다. 그들은 함께 일합니다.

그러면 아마도 범위 크리프가 해결되어야 하고 Gutenberg는 wp_editor() 채워진 영역으로 제한되어야 합니다. 그것은 확실히 많은 호환성 문제를 해결할 것입니다.

스코프 크리프

스코프 크립을 해결하는 것이 제가 선호하는 사항이며 지난 몇 달 동안 많은 사람들이 요구해 온 것입니다. 그렇게 하면 관리 환경을 분할하지 않고도 편집기를 개선할 수 있습니다.

게시물 유형별 Gutenberg 활성화

게시물 유형별로 Gutenberg를 비활성화하는 기능과 관련하여 저는 문제를 피하는 것이 솔루션에 도달하는 것과 같지 않다는 점을 강조하고 싶습니다. 게시물 유형별로 Gutenberg를 끄면 일부 플러그인에 대한 메타 상자 비호환성을 피할 수 있지만 장기적으로 WordPress 환경이 손상됩니다.

이유를 알 수 없다면 Gutenberg가 합병된 후 2년 후에 업계에 진입하는 새로운 플러그인 개발자가 된다고 상상해 보십시오.

• 개발자로서 플러그인 UI를 블록으로 작성합니까 아니면 메타 상자로 작성합니까? 모든 게시물 유형을 지원하려면 둘 다로 작성해야 합니다.
• 사용자가 플러그인을 검색할 때 플러그인 페이지에서 약속한 기능이 Gutenberg 지원 게시물 유형에서만 작동한다는 것을 알고 있습니까? Classic 편집기와 함께 사용할 수 없다는 사실을 알게 되면 실망할까요?
• 동일한 사용자가 지원을 위해 귀하에게 연락할 때 귀하의 플러그인이 Classic 편집기 또는 Gutenberg 편집기에서 작동하는 방식에 대해 질문하는지 알고 있습니까? 그 고객은 그 차이를 알고 있습니까?
• 출시 몇 개월 후에 기능을 추가하고 싶을 때 PHP 메타 상자와 JS 블록 모두에 해당 기능을 구축하기 위해 개발 시간을 늘릴 의향이 있습니까?

그것들은 우리가 UI에서 특이점으로 향하는 경로가 없고 두 명의 편집자를 가지고 앞으로 나아갈 때 풍경을 혼란스럽게 하는 몇 가지 질문에 불과합니다.

show_in_rest

show_in_rest 가 설정되지 않은 경우 게시물에서 Gutenberg를 사용할 수 없다는 사실은 편집 환경에 영향을 미치는 관련 없는 기능의 또 다른 예일 뿐입니다. REST API의 공개 게시물 가시성에 대한 선호도가 편집할 때 사용하는 인터페이스에 영향을 미칠 이유가 없습니다. 기술적인 이유는 이해하지만 논리가 거기에 없으며 많은 개발자가 현재 이것이 한계라는 사실조차 인식하지 못하는 것 같습니다.

Gutenberg가 어떻게 wp_editor() 매개변수의 범위를 벗어나게 되었는지는 여전히 저를 당황하게 합니다. Gutenberg "편집기"가 wp_editor()로 제한되면 게시물 유형별 "옵션으로 활성화"가 현실이 되며 앞으로 훨씬 더 관리하기 쉽고 확장 가능합니다. 나는 여전히 Gutenberg 스코프 크립이 축소될 수 없고 wp_editor() 내에 포함될 수 없는 이유에 대한 합리적인 설명을 보지 못했습니다.

편집기를 사용하지 않고 프런트엔드에 직접 표시되지 않는 사용자 정의 게시물 유형에 대해 Gutenberg를 활성화하는 것은 의미가 없습니다.

CPT가 단순한 게시물 유형뿐만 아니라 다양한 설정 및 요소에 대한 관리자 인터페이스를 만드는 방법으로 사용되는 다양한 웹 사이트를 보았습니다.

예를 들어, 내가 작업한 저자 사이트에는 "도서" 및 "쇼핑 링크"에 대한 CPT가 있습니다. Books 목록 페이지의 편집자로 Gutenberg를 사용하는 것은 절대적으로 의미가 있습니다. 그러나 "쇼핑 링크"에는 자체 게시물이나 페이지가 없지만 각 "도서" 페이지의 온라인 서점에 대한 링크에 대한 논리를 제공하는 데 사용됩니다. 도서 페이지 템플릿은 지역(예: 영국, 미국) 및 형식(예: 전자책, 인쇄판)과 일치하는 제품 페이지에 대한 Shop Links를 표시하고 포스트 메타 필드에 저장된 ISBN을 각 온라인 상점의 URL 구조에 삽입합니다(스크린샷 참조).

CPT는 이러한 종류의 데이터 및 설정을 관리하는 가장 좋은 방법은 아니지만 편집기가 없는 CPT와 사용자 정의 메타 필드를 사용하여 다양한 기능을 결합한 웹 사이트가 많이 있습니다. 이러한 종류의 사용에 대한 다른 예를 제공할 수 있습니다. 편집기를 전혀 사용하지 않는 CPT에 Gutenberg 편집기를 강제로 적용하는 것은 혼란스럽고 비생산적입니다.

편집기를 사용하지 않고 프런트엔드에 직접 표시되지 않는 사용자 정의 게시물 유형에 대해 Gutenberg를 활성화하는 것은 의미가 없습니다.

말이 안 됩니다. 하지만 Gutenberg가 전체 화면을 대체하는 한 Gutenberg를 포함하거나 제외하는 결정은 게시물 유형에 편집자를 원하는지 여부를 넘어 더 큰 영향을 미칩니다.

예를 들어, 귀하가 플러그인 개발자이고 "쇼핑 링크 설정" 메타 상자를 Gutenberg를 사용하는 하나의 게시물 유형과 사용하지 않는 두 번째 게시물 유형에서 사용할 수 있기를 원한다고 상상해 보십시오. 모든 게시물 유형에서 작동할 것으로 기대하는 수천 명의 사용자에게 플러그인을 배포하는 경우 선택의 여지가 없습니다. 그 때 https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341867663에 언급된 질문이 작동합니다.

자체 게시물 유형 내에서 격리된 메타 상자가 구텐베르크의 영향을 가장 적게 받는다는 점을 반복할 가치가 있습니다. 따라서 게시물 유형 전반에 걸쳐 제공되는 플러그인 기능에 미치는 영향을 고려해야 합니다.

예, 플러그인이 Gutenberg 및 비-Gutenberg 인터페이스를 모두 지원해야 하는 것은 주요 진행 중인 문제가 될 것임을 알 수 있습니다.

그러면 질문은 Gutenberg가 편집기를 지원하지 않는 CPT를 어떻게 처리해야 하는지 입니다. Gutenberg는 블록에서 페이지를 빌드하는 것이 이해가 되지 않는 컨텍스트에서 어떻게 작동합니까?

...구텐베르크가 편집기를 지원하지 않는 CPT를 처리하는 방법 - 블록에서 페이지를 구축하는 것이 이해가 되지 않는 상황에서 구텐베르크가 어떻게 작동합니까?

Gutenberg가 축소되고 내가 https://github.com/WordPress/gutenberg/issues/3304#issuecomment -341474018에서 언급한 Yoast 개념과 같이 편집기만 교체하는 경우 Gutenberg를 활성화하거나 비활성화하는 것이 매우 간단합니다.

• editor 가 활성화된 경우 블록 편집기가 존재하고 사용되는 후크에 따라 메타 상자가 그 위 또는 아래에 나타날 수 있습니다.
• editor 가 비활성화된 경우 블록 편집기가 없고 메타 상자가 위로 슬라이드되어 게시물 유형의 기본 인터페이스가 됩니다.

그것이 오늘날 기본적으로 작동하는 방식이며, 그 동작을 유지함으로써 플러그인이 의미가 있는 경우 메타 상자를 블록으로 점진적으로 전환할 수 있습니다. 또한 분할 관리 경험과 관련하여 위에 나열된 많은 혼란스러운 질문을 피할 수 있습니다.

킥오프 포스트 와 프로젝트가 받은 축복을 감안할 때 "스코프 크립"이 사용하기에는 이상한 용어라고 생각합니다. 편집 경험을 전체적으로 개선하는 방법에 대해 논의하고 연구하기 시작한 1월 11일 이후 공개적으로 이미 완료된 작업에 대해 모욕감을 느낍니다. 아무 것도 우리에게 다가오지 않았습니다. 이것은 항상 계획이었고 초점에 대해 정해진 기간이 없는 이유입니다.

그럴 수도 있겠지만 저는 디자인 관점 에 대해 조금 이야기하고 싶습니다. 그리고 왜 편집자가 콘텐츠 영역을 교체하는 데 초점을 맞추는 디자인을 하는 것이 완전한 상태를 유지하기 위해 터무니없이 타협적인 경험이 되었을 것이라고 생각하는 이유입니다. 지난 10년 동안 편집기를 확장하기 위해 구축된 모든 플러그인과의 하위 호환성. 현상 유지 는 쉬운 방법이지만 항상 올바른 방법은 아닙니다.

흐름을 재고하지 않고 기존 편집기에 블록을 추가하면 이미 복잡성이 있었던 곳에 복잡성이 추가되었을 것 입니다.

짧은 코드, 사용자 정의 HTML, 위젯 등을 대체하기 위해 블록을 포함하도록 포스트 작성을 재고하라는 명령이 주어지면 전체 작성, 편집 및 게시 흐름을 전체적으로 보지 않음으로써 디자이너로서의 책임을 낭비하게 될 것입니다.

프로젝트 전체가 미래를 맞이하기 위해 과감한 조치를 취하지 않는 한 WordPress가 5년 안에 관련이 있을 것이라고 확신하지 못합니다 . JavaScript 코어는 수년 동안 State of the Word 기조 연설에서 광고되었습니다. 이를 염두에 두고 풍부한 포스트 콘텐츠 작성을 근본적으로 단순화해야 하는 기회를 유지하면서 작은 창 대신 전체 편집 경험을 보는 것은 기회일 뿐만 아니라 그것이 가져오는 어려움에도 불구하고 그렇지 않은 디자인을 하는 것은 틀림없이 태만할 것입니다. 그것으로.

전체 화면을 보지 않고 좋은 편집기를 디자인하는 것은 불가능합니다 . 이것은 불편하고 프로젝트를 어렵게 만들고 WordPress의 유산을 감안할 때 여전히 더 어렵게 만듭니다. 쉽지 않았으며, 특히 Gutenberg가 기본적으로 확장될 수 있는 방법에 대해 여전히 갈 길이 있습니다. 그러나 콘텐츠 텍스트 영역만 대체하도록 Gutenberg를 구축하는 것은 반 단계를 수행하는 것이므로 WordPress에 큰 피해를 입히고 부팅하기에 좋지 않은 디자인이 될 것입니다.

현재 편집 화면 에 구텐베르크의 한 구성 요소 , 편집기 캔버스만

그러면 질문은 Gutenberg가 편집기를 지원하지 않는 CPT를 어떻게 처리해야 하는지 입니다. Gutenberg는 블록에서 페이지를 빌드하는 것이 이해가 되지 않는 컨텍스트에서 어떻게 작동합니까?

@CalebWoodbridge 이것이 이미 작동하는 방식입니다. 참조: https://github.com/WordPress/gutenberg/blob/master/lib/register.php#L290

나는 '스코프 크리프'라는 용어를 사용하는 것이 옳지 않다는 것을 두 번째로 말하고 싶다. 구텐베르크가 하는 일을 하려는 프로젝트에는 확실히 적용되지 않는 용어입니다.

이것에 대해 곁눈질을 해서 미안하지만 말할 가치가 있다고 생각합니다. 개발자가 기술적인 말을 할 때 존경을 표하는 것처럼 디자이너도 같은 시각으로 생각하십시오. 이 프로젝트에 참여하는 디자이너들은 많은 경험과 기술을 가지고 있습니다. 나는 그 작업을 깊이 존경하고 이렇게 훌륭한 디자이너들과 함께 프로젝트의 디자인 리더가 되는 것을 기쁘게 생각합니다.

구텐베르크에 있는 디자이너들과 작업할 수 있는 기회를 갖게 되어 영광입니다. 그것은 매일의 즐거움이며 우리가 WordPress에서 항상 얻지 못하는 것입니다. 핵심적인 디자이너로서 대부분의 경우 당신은 외로운 사람입니다. 함께 일하게 된 것은 정말 놀라운 일이었습니다.

디자인 접근 방식을 볼 때 경험이 중요합니다. @matias 와 함께 원래 비전의 @jasmussen 은 완전한 경험의 기초를 설정했습니다. 두 번째 디자인 리더로서 그것은 내가 소중히 여기고 보존하고 싶은 것입니다.

디자인 관점에서 과거 WordPress의 큰 문제 중 하나는 작은 반복 위에 작은 반복의 나선형이었습니다. 처음 몇 가지는 작동하지만 시간이 지남에 따라 개선 패치와 함께 유지되는 경험이 추가됩니다. 이것으로 고통받는 WordPress가 많이 있습니다. 편집자는 하나이고 미디어는 또 하나이며 지적할 수 있는 것이 훨씬 더 많습니다.

구텐베르그는 우리에게 패치를 제거하고, 우리가 가지고 있는 것을 보고, 다시 구축할 수 있는 공간을 주었습니다. 결과적으로 사용자 지정 및 그 이상으로 이동할 강력한 시각적 언어의 시작이 주어졌습니다. 실제로 WordPress를 향후 10년으로 발전시키는 시각적 언어를 갖는 것. 예, 우리는 멀리 생각해야 합니다.

나는 또한 Frankendesigns에 대해 경고하는 요점을 갖고 싶습니다. 전 세계의 모든 디자이너는 누군가에게 '여기에 x 또는 y를 넣어라'고 제안한 적이 있습니다. 이것은 디자이너가 디자인하는 것을 허용하지 않습니다. 디자이너에게 디자인을 맡기지 않는다면 프로젝트로서 우리는 하락세에 접어들고 있습니다. 이것은 직설적으로 디자이너의 불을 죽이는 일종의 프로세스입니다. 계속 불을 냅시다.

이것은 구텐베르크를 넘어선 개인적인 메모입니다. 저는 디자이너가 번성하고 성장할 수 있는 공간을 만드는 데 열정을 가지고 있습니다. 항상 프로젝트로 진행되는 것은 아닙니다. 우리가 그렇게 하고 있다는 것을 구텐베르그와 함께 보여줍시다. 열정은 훌륭하지만 WordPress의 기술 비전에서와 마찬가지로 디자인 비전을 존중합니다. 최신 JS 프레임워크에 대해 말하는 사람들의 말을 듣는 것만큼 디자이너의 이야기를 들어봅시다.

@jasmussen 이 과감하게 제기한

분명히 말하고 싶습니다. 구텐베르그가 디자인으로서 '완료'되거나 완벽하다고 말하는 것이 아닙니다. 반복해야 하고 테스트해야 합니다. 우리가 필요로 하지 않는 것은 거꾸로 돌아가서 확립된 강력한 디자인 언어에서 벗어나는 것입니다. 우리는 Frankendesign을 할 필요가 없습니다. 우리에게 필요한 것은 테스트하고 피드백을 받고 디자이너가 반복할 수 있도록 하는 것입니다.

디자인 관점에서 과거 WordPress의 큰 문제 중 하나는 작은 반복 위에 작은 반복의 나선형이었습니다. 처음 몇 가지는 작동하지만 시간이 지남에 따라 개선 패치와 함께 유지되는 경험이 추가됩니다.

이와 같은 진술을 http://matiasventura.com/post/gutenberg-or-the-ship-of-seus/ 와 같은 공개 진술과 조화시키려고 하면 사용자가 작업에 대해 정직한 의사 소통을 받고 있다고 느끼기가 매우 어렵습니다. 끝 나가고있다. 워드프레스는 수백만 명의 사람들이 수백만 가지 방식으로 사용하고 있으며, 메타박스 지원이나 포스트 스토리지 형식과 같은 기술적 측면과 관련하여 가능한 한 파손이 적은 점진적인 접근이 필요하다는 것이 충분히 분명해졌습니다. 이 결정은 구현의 여러 부분을 복잡하게 만들고 차선책이지만 여러 면에서 더 잘 지원되는 결정을 강요했습니다.

개발을 한 표준으로 유지하고 디자인을 다른 표준으로 유지하는 것은 합리적이지 않습니다. 때때로 '대담한 디자인'은 합리적인 생산을 위해 축소되어야 합니다. 이것은 자동차 제조 분야에서 잘 알려져 있으며 구텐베르그를 컨셉트카에 비유하기 쉽습니다.

물론 관리자 전체에 대해 자바스크립트를 사용하는 전체적인 디자인을 원하지만 수백만 사용자의 경험을 손상시키지 않고는 v5 릴리스가 될 수 없습니다. 대신 편집 페이지가 아닌 편집기에 초점을 맞추기 위해 축소하면 중단 없이 훨씬 더 나은 경험을 제공할 수 있습니다.

그런 다음 잘 문서화된 Fields API를 제공하여 플러그인과 테마를 동일한 인터페이스를 보다 쉽고 논리적으로 생성하여 내년에 Gutenberg 블록 사고 방식으로 변환할 수 있습니다. 매우 신속하게, 메타박스는 작업을 수행하는 오래된 방식이 되고 모든 고가치 플러그인은 블록으로 전환됩니다... 다시 한 번, 이것은 유기적으로 발생해야 합니다. 기능을 더 이상 사용하지 않거나 플러그인 작성자가 구텐베르크와 메타박스 모두에 대해 코딩해야 하는 분할 인터페이스를 만들어 사람들의 손을 잡는 것은 지지할 수 없습니다.

재작업이 필요한 영역으로 미디어 오버홀을 언급하는 것은 좋은데.... 폭주하고 융통성 없는 오버홀로 인해 피해를 입은 영역입니다. JS 프레임워크를 완전히 수용한 것은 워드프레스의 첫 번째 섹션이었고, 개발자들에게 크게 후퇴했습니다. 미디어 라이브러리의 사용자 지정 기능이 부족하다는 것은 완벽하다는 표시가 아니라 미래 및 현재 사용 사례를 고려한 사려 깊은 디자인이 부족하다는 의미입니다. 나는 미디어 인터페이스를 여러 번 수정하려고 시도했지만 누군가가 주요 구성 요소를 백본 템플릿에 하드 코딩해야 한다고 결정한 것을 발견했습니다. 나는 문자 그대로 어제 이러한 경우 중 하나에 부딪쳤습니다! (여기의 일곱 번째 단락에서 볼 수 있듯이: https://gschoppe.com/wordpress/disable-attachment-pages/)

편집 페이지가 아니라 구텐베르그를 다시 편집기로 확장하면 모든 것을 손상시키지 않는 앞으로 나아갈 수 있습니다. Gutenberg가 사용자 정의 포스트 인터페이스의 기초로 잘 확립되면 JavaScript 전용 비전이 나머지 편집 페이지를 인수할 수 있습니다. 이러한 종류의 반복은 (matt가 허용할 수 없다고 주장한 것처럼) LTS 릴리스를 제공하고 각 주요 버전을 완전한 주요 버전으로 만들지 않는 한 대규모 소프트웨어 패키지에서 절대적으로 중요합니다.

당신이 빠질 위험이 있는 두 개의 구덩이가 있고 당신은 하나를 식별했습니다. 예, 최신 기술을 사용하는 통합 인터페이스로 이동하지 않으면 WordPress는 향후 50년 안에 사라질 것입니다. 그러나 이 전환 기간 동안 WordPress가 대규모 개발자 및 전문 사용자 커뮤니티에 대한 적절한 지원을 제공하지 못하면 훨씬 더 빨리 죽게 될 것입니다.

기존 워크플로를 중단하지 않으면서 비트를 줄이고 축소하고 사용자에게 도구 상자를 여는 무언가를 제공하십시오. 그런 다음 버전별로 앞으로 확장할 수 있습니다. 당신은 아름다운 컨셉트 카를 가지고 있지만 우리에게 필요한 것은 실제 운전의 모든 경우에 사용할 수 있는 양산차입니다. 그러나 개념을 제공함으로써 아이디어를 더 제한된 범위에 적용할 수 있으며 1년 후에는 이러한 원칙이 유비쿼터스될 것입니다.

@gschoppe , 시간을 내어 답변해 주셔서 감사합니다.

첫째, 약간의 명확성. 내 의견이 Matias의 게시물에 반대한다는 데 동의하지 않습니다. 나는 그가 만든 게시물에 완전히 서 있고, 그것이 나의 비전이기도 하고 우리가 방향을 보는 방식으로 뭉친 이 프로젝트의 리더입니다. 당신의 개인적인 의견은 당신의 것이므로 그 지점에서 넘어 갑시다.

개발을 한 표준으로 유지하고 디자인을 다른 표준으로 유지하는 것은 합리적이지 않습니다.

나는 동의하고 내 의견은 디자인이 더 많이 들리거나 다른 표준을 갖는 것을 목표로 하는 것이 아니라 모든 목소리를 듣고 모든 사람에게 동일한 표준을 적용하는 것에 관한 것입니다.

재작업이 필요한 영역으로 미디어 오버홀을 언급하는 것은 좋은데.... 폭주하고 융통성 없는 오버홀로 인해 피해를 입은 영역입니다.

저는 미디어가 처음부터 디자이너와 개발자와 함께 초점을 맞추는 것을 보고 싶습니다. 그러나 그렇지 않았습니다.

그러나 이 전환 기간 동안 WordPress가 대규모 개발자 및 전문 사용자 커뮤니티에 대한 적절한 지원을 제공하지 못하면 훨씬 더 빨리 죽게 될 것입니다.

아무도 어떤 기능도 빼앗지 않고 있기 때문에 당신이 이것을 말하는 것이 흥미롭습니다. 구텐베르그의 어떤 디자인 제안도 그렇게 하지 않았습니다. 어떤 식으로든 기존의 모든 기능을 수행할 수 있습니다. 이는 클래식 편집기 플러그인을 사용하는 경우에도 마찬가지입니다.

iframe에 의존하여 UI를 구성하는 것보다 Frankendesign보다 더 좋은 것은 없습니다. 메타 박스가 디자인 프로세스에 큰 영향을 미치고 있다는 것을 이해하지만 디자인의 일부는 제한 사항을 처리하는 것입니다. 이러한 제한이 존재하지 않는 것처럼 앞으로 나아가거나 전환 계획을 끝까지 미루는 것은 이미 걱정하고 회의적인 커뮤니티에 더 많은 우려를 더할 것입니다.

구텐베르크의 장기 계획이 플러그인 영역이었다면 무한한 실험을 했다고 말하고 싶습니다. 그러나 사람들이 옵트아웃하기보다 옵트아웃해야 하는 플러그인이 될 운명이 아니라면 핵심과 함께 가져오는 모든 짐을 현실적으로 다루어야 합니다.

내 의견은 디자인이 더 많이 들리는 것을 목표로하지 않습니다.

전 세계의 모든 디자이너는 누군가에게 '여기에 x 또는 y를 넣어라'고 제안한 적이 있습니다. 이것은 디자이너가 디자인하는 것을 허용하지 않습니다. 디자이너에게 디자인을 맡기지 않는다면 프로젝트로서 우리는 하락세에 접어들고 있습니다. 이것은 직설적으로 디자이너의 불을 죽이는 일종의 프로세스입니다. 계속 불을 냅시다.

전 세계의 모든 비즈니스에서 설계는 구현의 제약 조건에 맞게 조정됩니다. 메타박스에 대한 이전 버전과의 호환성이 제약 조건인 경우 설계는 이를 수용하고 제약 조건 내에서 작업해야 합니다.

솔직히 말해서, 접근성의 손실 없이 메타박스를 완벽하게 지원합니까? 디자인 제약이 있습니까? 수천 명의 다른 사람들과 마찬가지로 명확한 답변을 원합니다.

구텐베르그의 어떤 디자인 제안도 그렇게 하지 않았습니다. 어떤 식으로든 기존의 모든 기능을 수행할 수 있습니다. 이는 클래식 편집기 플러그인을 사용하는 경우에도 마찬가지입니다.

현재 Gutenberg는 모든 메타필드를 iframe에 넣습니다. 이는 매우 깊은 수준에서 기능을 손상시킵니다. 우리는 접근성의 시대에 있으며 맞춤 사용자 경험을 만들고 iframe에 가두는 기본 방법을 사용하면 이러한 도구에서 모든 접근성이 근본적으로 제거됩니다. 또한 편집기를 로드하는 데 필요한 요청 수를 세 배로 늘리고 사용자에게 끔찍한 UI를 제공하여 전체 화면 모달 경험을 작은 영역에 감금합니다.

현재 이 스레드는 Gutenberg가 사용자 정의 게시물 유형에 대해 옵트인 또는 옵트아웃해야 하는지 여부에 대해 논의합니다. 옵트인하면 모든 게시물 유형을 지원하려는 개발자가 이전에 내린 일관된 UI 결정이 구텐베르그 경험과 클래식 경험 사이에서 분리되어 둘 모두에 합당한 사용자 경험을 제공하고 일관성을 보장하기 위해 두 배의 개발 작업이 필요합니다. 사용자 경험의.

현재 wp_editor() 기능(비편집 페이지에서 편집 환경의 완전한 기능을 구현하는 현재 모범 사례)은 Gutenberg 인터페이스를 제공하지 않습니다. 즉, 게시물이 아닌 페이지에서 사용자 정의 편집 경험을 만드십시오 ... 사용자에게 분할 UX를 제공하는 것 외에 앞으로 나아갈 길은 무엇입니까?

Gutenberg를 제거하는 플러그인은 일부 문제를 해결할 수 있지만 플러그인 개발자를 위한 솔루션으로 제공할 수는 없습니다. 그들은 "게시물 유형 전반에 걸쳐 일관되고 접근 가능한 사용자 인터페이스를 원한다면 새 편집기를 비활성화해야 합니다"라고 말할 자유가 없습니다.

기능 제거는 표준 워크플로에 대한 이전 버전과의 호환성이 아닙니다. 기능 제거는 일류 경험으로 수용할 수 없는 1%의 사용자를 위한 최후의 수단입니다. 이 경우 내가 제시한 예 중 어느 것도 1% 문제가 아닙니다.

화염에 약간의 기름을 추가하려면: 지난 주에 iFrames를 사용하는 데 큰 문제가 발생했습니다. 데스크톱 시스템에서는 훌륭하게 작동하지만 테스트한 경우의 90%에서 모바일/반응형에서는 크게 실패합니다. 수많은 게시판 스레드, 인터넷 기사 및 Stack Overflow에 대한 질문을 파헤친 후 iframe 접근 방식을 완전히 포기하기로 결정했습니다. 응답성이 em으로 인해 끔찍하게 복잡해지기 때문입니다. uh. 일부 변환 작업은 iframe에 의존하는 대신 "프로젝트가 있는 실제 하위 도메인으로 리디렉션 사용"과 같이 비교적 쉽게 수행되어 가정된 기본 도메인만 표시하는 멋진 장식을 표시하지만 다른 작업은 훨씬 더 비참했습니다.

그럼에도 불구하고 iframe으로 작업하기 위해 RWD를 적절하게, 그리고 무엇보다도 안정적이고 유지 관리가 용이하도록 해야 하는 엄청난 양의 작업에 비해 전환은 훨씬 적은 노력으로 이루어졌으므로 더 나은 방법이었습니다.

요약하자면 iframe은 언뜻 보기에 쉬운 탈출구처럼 보이지만 (많은) 접근성 문제 때문이 아니라 매우 나쁜 디자인 선택입니다.

내 0.02센트,
cu, w0lf.

이 문제를 보여 주신 @mtias 에게 감사드립니다.
벨로우즈 저는 구텐베르크가 워드프레스 플러그인 개발자를 위해 어떻게 문을 열 수 있는지에 대한 제 생각을 게시하고 있습니다.

기존 블록에 대한 사용자 정의 가능한 CSS 클래스

필요: 각 블록 래퍼에 대한 CSS 클래스와 이를 사용자 정의할 수 있는 전체 액세스 권한. 구텐베르그가 제3자 개발자라도 최상위 요소에 CSS 클래스를 요구한다면 좋을 것입니다.

목적: 이 방법으로 고급 스타일을 위해 블록에 사용자 정의 클래스를 추가할 수 있습니다. 클래스를 사용하여 애니메이션이나 기타 고급 블록 속성을 추가할 수도 있습니다.

사용 예: 우리는 엄격하게 정의된 디자인 언어를 사용하여 대규모 고객을 위한 웹사이트를 만듭니다. 사이드 에디터는 특히 이 클라이언트를 위해 디자이너가 생성한 미리 정의된 수의 스타일로 블록을 생성할 수 있어야 합니다.

기존 블록에 대한 사용자 정의 가능한 데이터 속성

필요: 모든 블록 래퍼에 대해 사용자 정의 데이터 속성을 추가할 수 있습니다.

목적: 위에서 설명한 사용자 정의 CSS 클래스에 대한 보다 깨끗하고 유연한 대안. 데이터 속성을 사용하여 페이지의 모든 요소에 스타일을 지정할 수 있습니다. 스타일 지정 외에도 사용자 지정 데이터 속성을 사용하여 JS에 대한 추가 메타데이터를 저장할 수 있습니다.

사용 예:

• 반응형 블록 : 모바일/데스크톱에만 표시되는 블록 표시
• 조건부 블록 : JS <div data-condition="if-adblock"... , <div data-condition="if-from-facebook"... 로 표시/숨길 블록 표시
• 블록 애니메이션 : <div data-animation="on-load animation-style-3"...
• 블록 디자인 : <div data-skin="dark"...