Gutenberg: iframe은 메타 박스를위한 실행 가능한 장기 솔루션입니까?

1. ... Gutenberg는 현재 기본 열과 사이드 바에 대해 두 개의 개별 iframe을 사용합니다. 제목 뒤에 나타나는 메타 상자를 지원하면 이론적으로 세 번째 iframe이 생성됩니다. 모든 iframed 메타 박스에 영향을 주어야하는 플러그인이 애셋을 대기열에 추가하는 방법에 관한 문제가 있습니까?

오늘 밤 성능 테스트를 수행했는데 네트워크 탭에서이 발견을 발견했습니다. 상위 창에 추가 된 모든 CSS 및 JS 자산이 기본 열 iframe 및 사이드 바 iframe에도 추가되는 것으로 보입니다. 즉, 각 자산이 총 세 번 요청되어 사용할 때 자산 요청 수를 효과적으로 세 배로 늘립니다. 구텐베르크 .

브라우저 캐싱을 사용하면 페이지 가중치 손상이 줄어들지 만 자산 요청 수는 여전히 3 배입니다. 나는 이것이 각 iframe이 메타 박스가 작동하도록 허용하는 데 필요한 자산을 갖도록 수행되고 있다고 가정하지만 앞으로 자산을 대기열에 넣는 솔루션이 될 수는 없습니다.

@kevinwhoffman 문제와 통찰력을 만들어 주셔서 감사합니다. 구텐베르크의 메타 박스에 대해 오늘날 우리가 가지고있는 것이 실험이라고 생각하는 것이 좋습니다. 여러 측면에서 프로젝트가 취해야 할 방향을 결정하는 동안 유지 패턴입니다. '당분간'작동하지만 우리가 함께 제공 할 제품이 아니라는 말에서.

위의 모든 내용은 앞으로 메타 박스가 어떤 용도로 사용 될지 살펴 보는 것이 중요하다고 생각합니다. 블록으로 변환되지 않는 경우 (있는 경우)는 무엇입니까? 모든 메타 박스가 모바일에서 작동해야합니까? 우리가 탐색하지 않은 대체 인터페이스가 있습니까? 나는 거기에 틀림 없다. 지금 당장은 그러한 가능성을 살펴보고 현재 주와 미래의 주를 위해 일하는 길을가는 것입니다.

현재 구텐베르크의 현재 버전의 메타 박스에 존재하는 버그를 수정해야하며 이것이 초점입니다. 이 수정에는 성능이 필요합니다. 모바일 측면에서 메타 박스는 오랫동안 문제가되어 왔으며 여기서 더 나빠지는 것은 아닙니다. 그것은 우리가 미래에 더 나은 솔루션을 위해 노력해야한다고 말했습니다. 우리가 반복하고 더 나은 옵션을 생각할 수있는 자유를 계속 유지하기 때문에 반복해서 되돌아 가서 이것이 '오늘의'해결책 일뿐임을 기억하는 것이 중요합니다.

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

iframe 접근 방식은 '현재'뿐만 아니라 작동하지 않습니다. 위에 나열된 관련 문제는 주요 방식으로 작동하지 않는 메타 상자의 예를 제공합니다. 또한 이러한 문제가 수정 되었더라도 페이지 가중치와 요청 수를 3 배로 늘리는 것은 어떤 상황에서도 '작동하는'것으로 간주되어서는 안됩니다.

위의 모든 내용은 앞으로 메타 박스가 어떤 용도로 사용 될지 살펴 보는 것이 중요하다고 생각합니다.

정중하게도 이것은 메타 박스 문제가 제기 될 때마다 발생합니다. 대화를 미래의 메타 블록으로 옮기기보다는 기존 메타 박스가 직면 한 문제를 중심으로이 토론을 구성하는 것이 정말 도움이 될 것입니다. 다시 한번:

메타 박스를 생성하는 테마 나 플러그인을 수정하지 않고도 이러한 문제를 해결할 수 있습니까?

메타 박스가 구텐베르크와 계속 협력 할 것이라는 증거는 지금까지 보지 못했습니다. 대답이 '아니요'이면 5.0이 또 다른 WordPress 릴리스 인 척하는 것을 중지하고 이전 버전과의 호환성을 깨는 것에 대해 정직하게 시작해야합니다.

안녕 케빈,

자세한보고를 해주셔서 감사합니다. 많은 이슈들이 어느 정도 수정 될 수 있다고 생각합니다. 이것은 또한 iframe 접근 방식이 작동하는지 여부와 얼마나 멀리 걸릴 수 있는지에 대한 탐구이기도합니다. 따라서 이런 종류의 대화를 통해이 접근 방식의 단점을 기록하는 것이 좋습니다.

iframe을 넘어 확장되는 메타 상자에서 콘텐츠 창을 시작할 수 있습니까?

전체 페이지를 차지해야하는 모달 라이트 박스와 같은 의미입니까?

전체 페이지를 차지해야하는 모달 라이트 박스와 같은 의미입니까?

이것이 하나의 예이지만 iframe의 범위 내에 있지 않은 콘텐츠를 공개해야하는 모든 시나리오를 더 많이 언급합니다.

예를 들어 페이지 중앙의 콘텐츠 상자를 트리거하는 사이드 바의 버튼을 클릭 할 수 있습니까? 해당 콘텐츠 상자가 iframe 내부에있는 경우 사이드 바의 iframe 크기 외부에 표시되지 않습니다.

논리적 다음 단계는 iframe의 상위 문서에서 함수를 대신 호출하는 것입니다. 그러나 플러그인은 현재 그렇게 작동하도록 작성되지 않았으며 수정을 요구하면 _legacy_ 메타 상자를 지원하는 모든 목적을 무력화시킬 수 있습니다. 어떤 솔루션이 결정 되든 기존 테마 또는 플러그인을 수정하지 않고 작동해야한다고 강조 할 수는 없습니다.

플러그인 / 테마 자산과 관련하여 iFrame 구현이 얼마나 부정적인지 알면 프로젝트가 일시 중지되어야한다고 생각합니다. 여기서 진정한 답은 WordPress가 Fields API https://github.com/sc0ttkclark/wordpress-fields-api 를 제공하는 것입니다. 그것 없이는 성능에 관심이 있다면 Gutenberg로 메타 박스를 효과적으로 구현하는 것이 사실상 불가능합니다.

"준비"될 때까지 구텐베르크를 실제로 출시하지 않는다면, 구텐베르크의 React에서 metbox가 올 바르고 원활하게 작동하도록 Fields API에 동일한 관심을 기울여야한다고 말합니다.

논리적 다음 단계는 iframe의 상위 문서에서 함수를 대신 호출하는 것입니다. 그러나 플러그인은 현재 그렇게 작동하도록 작성되지 않았으며 수정을 요구하면 레거시 메타 박스를 지원하는 모든 목적을 무너 뜨릴 것입니다. 어떤 솔루션이 결정 되든 기존 테마 또는 플러그인을 수정하지 않고 작동해야한다고 강조 할 수는 없습니다.

네,이 일을하는 동안 확실히 걱정거리였습니다. iframe 간의 교차 통신은 그다지 좋지 않습니다. 탐색 할 다른 대안도 있습니다.

그러나 특정 테마 플러그인이 손상되는 경우가있을 것이며 가능한 모든 사용 사례를 수용 할 수는 없습니다. . 현재 iframe 솔루션이 해당 목표를 충족하지 못할 수도 있습니다.

최근의 Core Customizer Dev Note Post 에서 iframe을 _improvement_로 사용하지 않도록주의를 기울였습니다. 여기서 솔루션으로 iframe을 구현하는 것은 한 걸음 뒤로 물러 난 것처럼 보입니다.

안녕하세요 Mathetos,

"준비"될 때까지 구텐베르크를 실제로 출시하지 않는다면, 구텐베르크의 React에서 metbox가 올 바르고 원활하게 작동하도록 Fields API에 동일한 관심을 기울여야한다고 말합니다.

Fields API가 다소 좋을 것이라는 데 동의합니다. 그러나 이는 또한 필드 API를 채택 할 사람들이 필요합니다. Gutenberg를 위해 플러그인 / 테마를 재 작성하려는 사람이 많지 않다면 Fields API를 위해 그렇게 할 의사가 없다고 생각합니다. 나는 또한 그것이 이전 호 어딘가에서 제기되었다고 생각하므로 GitHub 역사에서 찾아보고 Fields API가 어떻게 Gutenberg에 도움이 될 수 있는지에 대한 생각을 추가하는 것이 좋습니다.

... 가능한 모든 사용 사례를 수용하는 것은 불가능합니다. 더 나은 목표는 방대한 대다수의 사용자와 사용 사례를위한 좋은 경험을 만드는 것입니다.

동의합니다. 구텐베르크가 전체 페이지를 넘기지 않고 편집자를 고집한다면 목표를 훨씬 더 달성 할 수있을 것이라고 생각합니다. 그런 다음 기존 후크를 그대로두면 메타 상자가 지금처럼 계속해서 서로 통신 할 수 있습니다. 또한 자산 대기열에 추가하는 것은 오늘날처럼 작동하므로 문제가되지 않습니다.

저는 Yoast가 제시 한이 개념에 매우 동의합니다.이 개념은 에디터 구성 요소에 집중하기 위해 프로젝트의 범위를 축소하면서 이미 수행 된 작업의 대부분을 유지하는 것처럼 보입니다.

출처 : https://yoast.com/gutenberg-alternative-approach/

나는 또한 Yoast가 제안한 제안에 강력히 동의합니다. 플러그인 작성자에게 메타 박스를 새 블록으로 변환 할 시간을 제공하는 좋은 중간 단계를 제공합니다. 그런 다음 전체 편집기 경험의 최종 교체 계획의 일환으로 프로젝트로서의 WP는 "x 버전에서는 메타 박스가 더 이상 사용되지 않을 것입니다"와 같이 말할 수 있으므로 더 나은 최종 목표를 향해 이동하기위한 _plan_이 있습니다.

이 개념은 통신 할 중앙 TinyMCE 인스턴스가 없기 때문에 기존 메타 박스를 깨뜨립니다. 메타 박스의 80 %를 지원하는 대신 90 %를 지원합니다 (이 숫자를 구성했습니다).

이 개념은 이전 버전과의 호환성 문제를 해결하지 못하지만 동일한 문제로 해결을 지연시킵니다. 구텐베르크는 WP의 JS 인터페이스를 향한 첫 번째 단계이며 구텐베르크에서 멈추지 않을 것입니다.

구텐베르크 조각을 재사용하여이 개념을 구축하는 것은 상대적으로 가능하지만 이것은 최적화하려는 UX가 아닙니다. 먼저 가능한 최상의 편집기를 구축하고 이전 버전과의 호환성 문제가없는 사람들이 사용할 수 있도록 만들고 싶습니다 (새 설치, 메타 박스 없음 .. .).

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

지금 최고의 편집기를 만들어 봅시다.

구텐베르크의 이상적인 비전이 출시 될 준비가되었다고 생각되면 업그레이드 경로 전략에 대해 논의 할 시간이 있습니다.

나는 이것에 더 동의 할 수 없었다. 기존 사이트와 호환되지 않는데 이상적인 편집기를 개발하는 데 수천 시간을 투자하는 이유는 무엇입니까? 첫인상이 그들이 의존하는 UI를 깨뜨리는 것이라면 사용자는 애초에 이상적인 편집기를 경험하지 못할 것입니다.

기존 사이트와 호환되지 않는데 이상적인 편집기를 개발하는 데 수천 시간을 투자하는 이유는 무엇입니까?

명확하게 말하자면

• 플러그인은 DOM에 대한 전체 액세스 권한을 가지고 있기 때문에 편집기에 대해 선택한 옵션과 상관없이 기존 웹 사이트와 100 % 호환되는 것은 불가능합니다.
• 변경 사항에 대해 이전 버전과의 호환성을 100 % 보장하는 방법은 한 가지뿐입니다. 변경하지 마십시오. Gutenberg를 비활성화하는 플러그인이 이미 사용 가능합니다.
• 이 편집기는 이미 수많은 웹 사이트와 호환됩니다. 그러나 다른 모든 것과 마찬가지로 깨지면 항상 더 잘 보입니다.

기존 웹 사이트와 100 % 호환되는 것은 불가능합니다.

이제 명확 해 졌으니 WordPress의 미래에 가장 적합한 편집기를 만들어 보겠습니다.

모든 메타 박스가 모바일에서 작동해야합니까?

그래, 왜 안 그래?

블록으로 변환되지 않는 경우 (있는 경우)는 무엇입니까?

블로그 게시물의 경우 Blocks For Everything이 왜 의미가 있는지 이해하지만 메타 데이터의 일반적인 사용 사례 인 보이지 않는 데이터를 무시할 수 있습니다. 마찬가지로 메타 박스를 사용하여 UI를 노출하여 분석 데이터를 게시물에 추가 할 수 있습니다.

메타 상자만으로 구성 될 수있는 Custom Post Types와 같은 경우 새 UI를 이해하는 데 어려움이 있습니다. WordPress에는 데이터에 대한 포괄적 인 CRUD API가 없기 때문에 많은 개발자가 WP_Query 및 관련 API 제품군을 독립형으로 사용하고 특정 데이터를 추가하기위한 UI를 격리하기 위해 CPT 편집 화면에서 메타 상자를 사용하거나 협회. 많은 (대부분의) 사용자 지정 게시물 유형은 "콘텐츠"의 전통적인 사용을 덜 강조하거나 무시합니다. 따라서 블로그 게시물의 경우 콘텐츠가 전면 중앙이지만 많은 CMS 사용 사례의 경우 WYSIWYG가 만들지 않습니다. 많은 감각.

이 현재 반복에서 Meta Box 지원은 많은 사람들의 현실에서 Meta Box가 UI, API, CMS를 구성하는 데 사용하는 메커니즘 인 경우 추가 기능입니다. <iframe> s는 gulag입니다.

그리고 우리는 WP가 영원히 구축해 온 가치를 잊고 있습니다. WP의 최신 버전으로 업데이트 할 수 있어야하고 아무것도 다시 작성하지 않아도됩니다. 나는 WP에 야생에 너무 많은 프로젝트가있어서 다시는 건드리지 않을 것입니다. 그들 중 일부는 이러한 변화로 크게 깨지지 않을 것이라고 확신 할 수 있습니까?

이 예제로 끝낼 것입니다. "오래된"메타 상자 중 하나가 미디어 용 UI를 열도록 트리거하는 경우 iframe 내에서 누군가 (더 이상 함께 작업하지 않는 클라이언트)없이이 "새로운"시나리오에서 어떻게 작동합니까? ) 코드 재 작성?

이러한 대화를 따라 가면서 구텐베르크와 관련하여 개발하고 촬영하는 힘이 메타 박스 자체를 사용하거나 처리하지 않는다는 것을 느낄 수밖에 없습니다. 그것은 수단이 처음부터 그다지 가치가 없기 때문에 그렇게 말하기 쉬운 일종의 목적을 정당화하는 일종의 논쟁처럼 느껴집니다.

우리 중 많은 사람들에게 WordPress 5.0으로 업데이트하면 즉시 중단되는 수십 개의 사이트가 있다는 점을 이해하십시오.이 제품은 이전 버전과의 호환성에 대한 조증 때문에 업그레이드하는 것이 안전하다고 역사적으로 사람들에게 가르쳐 온 제품입니다. 여기서 논의되는 것은 사소한 (예 : 스타일링) 중단이 아니라 수천 (또는 그 이상) 사이트의 관리자 측을 즉시 사용할 수 없게 만드는 잠재적 인 쇼 스토퍼입니다. 무서운 일입니다. 업계로서 우리는 WordPress의 견고한 안정성으로 사람들을 팔았습니다.

@staylor 가 위에서 지적한 것처럼 대부분의 웹 사이트 (중간에서 고급 수준의 복잡한 기업 사이트)에서 메타 박스는 UI입니다. 편집기 (만일 사용하는 경우)는 그 일부일뿐입니다.

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

나는 이것을 멀리 미루는 것이 실수라고 생각한다. 특히 많은 조직이 준비하는 데 최소 1 ~ 2 분기가 필요하기 때문입니다.

내가 기억해야 할 WordPress의 여러 리드 개발자로부터 들었던 격언이 있습니다. 누군가가 자신의 사이트에 WordPress를 채택하면 WordPress 3.7 또는 WordPress 4.8을 채택하는 것이 아니라 WordPress를 채택하는 것입니다. 이 경로를 가능한 한 원활하게 진행하는 것은 절대적으로 필요합니다. 이로 인해 문제가 발생하고 괜찮습니다 (워드 프레스의 모든 릴리스에 대해 역 호환성 중단이 있음). 최소화하고 문서화하고 전달해야합니다.

기존 웹 사이트와 100 % 호환되는 것은 불가능합니다.

당신이 양립 할 수 없을 거라면 반드시 가서 부수십시오. 첫 번째 릴리스 WP ++ 또는 WPNG를 호출하십시오. 일이 깨질 가능성이 가장 높고 사람들이 준비하도록 미리 선언하는 것이 훨씬 좋습니다. 평소와 같이 작동하는 것처럼 현재의 "기만"은 모두에게 나쁜 일입니다.

Iframe은 사용성 측면에서 막 다른 골목입니다. 메타 상자에서 jquery 기반 날짜 선택 위젯을 열었고 창에서 다른 임의의 위치를 ​​클릭해도 닫히지 않았을 때 놀랐습니다. 클릭 이벤트가 상위 창에 있고 iframe으로 전파되지 않는다는 것을 깨달았습니다. 그래서 깜짝 놀랐지 만 결국 알게됐는데 어떻게 유저들에게 그런 설명을 해주실 건가요? 각 플러그인이 이러한 사소한 UX 기대에 대한 각 사용자의 질문에 답할 것으로 기대하십니까?
그리고 외부 링크가 어떻게 작동 할 것으로 기대합니까?

사람들이 iframe을 최후의 수단으로 만 사용하는 데에는 큰 이유가 있습니다.

내 생산적인 제안은 서서가 제대로 작동하지 않는 한 메타 상자 준비를 선언하지 않는 것입니다. 상호 작용 측면에서 약간 복잡하며 많은 사이트에 설치됩니다. 구텐베르크가 작업 할 수 없다면 아마 아무도 사용하지 않을 것입니다.

내 생산적인 제안은 메타 박스를 준비하지 않는 것입니다.

위의 @karmatosed 가

실제 데이터를 제공하기 위해 이전에 작업 한 WordPress 사이트에서이 인터페이스를 공유하고 싶습니다. 콘텐츠 필드는이 사용자 지정 게시물 유형의 일부이며 일부 사용자 지정 메타 박스 필드는 블록으로 변환 될 수 있지만 대부분은 관리자가 사용하거나 REST API를 통해 타사 서비스에서 사용하는 데이터를 포함합니다. 항목에 메타 데이터를 추가하는 데 사용됩니다. 다소 혼란스러워 보일 수 있지만이 설정은 클라이언트의 워크 플로와 함께 작동하도록 특별히 설계되었으며 명확한 분리를 기반으로 한 엄격한 콘텐츠 모델을 사용하여 사이트의 향후 버전이 각 유형의 콘텐츠를 독립적으로 처리 할 수 ​​있도록합니다.

이 사이트를 구텐베르그 현실 내에서 작동하도록 리팩토링하는 데 오랜 시간이 걸리고 상당한 리소스가 필요하므로 메타 박스가 이미 존재하는 것과 거의 일치하는 방식으로 처리되지 않는 한이 사이트 소유자는 구텐베르크 이전 버전의 WP로 되돌려 계속 머물 것입니다. 거기에 무기한 시간 동안.

참고로 이것은 광범위 해 보이지만 내가 만든 것 중 가장 복잡한 메타 박스 설정도 내가 본 것 중 가장 복잡한 설정도 아닙니다. 이 예제가 보여주는 것은 메타 박스를 통한 실제 해결 방법으로, 적절한 콘텐츠 모델링 및 콘텐츠 블롭을 넘어선 분리에 대한 필요성을 충족하기 위해 Gutenberg _must_는 우아하고 기능적으로 처리해야합니다.

이 경로를 가능한 한 원활하게 진행하는 것은 절대적으로 필요합니다.

동의 함

이로 인해 문제가 발생하고 괜찮습니다 (워드 프레스의 모든 릴리스에 대해 역 호환성 중단이 있음). 최소화하고 문서화하고 전달해야합니다.

동의 함

플러그인은 DOM에 대한 전체 액세스 권한을 가지고 있기 때문에 편집기에 대해 선택한 옵션에 관계없이 기존 웹 사이트와 100 % 호환되는 것은 불가능합니다. DOM에서 수정하는 것은 역 호환성을 깨는 것입니다.

동의합니다. 여기에서 당신과 반대하는 사람은 없을 것 같습니다. 하지만, 무엇이 깨지고 언제 깨 졌는지 논의

이 모든 것이 실험이라는 것을 _get_합니다. @kevinwhoffman 도 마찬가지라고 생각합니다. 나는이 문제를이 실험에 대한 _ 평가 _에 대해 잘 생각한 것으로 생각하며, 그렇게 받아 들여야합니다. 이 실험이 최종 솔루션으로 충분합니까? 아니요. 다음 실험은 무엇입니까?

또한 병합 제안이 자리를 잡을 때까지 기존 작업을 구텐베르그로 변환하는 개발자가 크게 증가하지 않을 것이라고 생각합니다. 구텐베르크의 초기 릴리스에서 무엇이 중단되는지는 중요합니다.

tldr; 구텐베르크와의 파손이 예상됩니까? 예! 그러나 우리는 여전히 _ 무엇을 깨뜨리는 지, 그리고 구텐베르크가 코어에 합쳐진 _ 초기 _ 반복에서 얼마나 멀리 가는지에 대해 선택해야합니다.

예, 우리 모두는 한 릴리스에서 다음 릴리스로 일부가 중단 될 것으로 예상 할 수있을만큼 WordPress 개발 주위에있었습니다. 그리고 그것이 바로 제 요점입니다. 우리가 구텐베르크를 또 다른 WordPress 업데이트로 제시하는 한 다른 업데이트보다 더 많거나 적은 것을 중단해서는 안됩니다. 우리가 그 신뢰를 깨면 편집자가 하루가 끝날 때 얼마나 좋은지는 중요하지 않습니다.

다음은 지난 몇 달 동안 개발해온 플러그인의 현재 스크린 샷입니다. 이 상황에서 비주얼 편집기는 아무런 가치가 없으며 콘텐츠의 시각적 편집을 위해 설계된 인터페이스에 필요한 종류의 인터페이스를 통합하려는 것은 의미가 없습니다.

내 모든 작업이 다음 버전에서 취소 될 수 있다는 점을 감안할 때 WordPress 용으로 계속 개발해야할지 여부를 실제로 심각하게 고려하고 있습니다.

보시다시피 메타 필드의 미디어 업 로더에 대한 액세스 권한이 필요하며 페이지의 대부분을 iframe으로 강등하면이 인터페이스가 매우 어색해집니다.

WordPress에 구축 된 플러그인, 도구 및 사용자 지정 사이트에는 이와 같은 수백만 개의 인터페이스가 있습니다. 블록의 "새로운 매력"에 찬성하여 이러한 사용자를 이등 시민처럼 대하는 것은 용납 할 수 없습니다. 메타 박스는 편집 페이지에서 현재 수준의 통합과 눈에 잘 띄도록 유지해야합니다.

나는 구텐베르크에 대한 Yoast의 견해를 매우지지합니다. 구텐베르크 팀이 "비주얼 편집기 업그레이드"를 "전체 편집 후 인터페이스를 대체"하는 것으로 재 해석 한 방법은 분명하지 않지만, 이른바 "테세우스의 배"와는 직접적으로 상충되는 것 같습니다.

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

@aaronjorbin 음 , https://make.wordpress.org/core/2017/10/24/whats-new-in-gutenberg-24th-october/ 에서와 같이 여기에 통신 문제가있는 것 같습니다.

이 릴리스에는 오랫동안 기다려온 메타 박스 지원이 포함되어 있습니다 (테스트 필요!).

그것은 "아이디어"가 아니라 "실험"이 아니라 모든 소프트웨어와 마찬가지로 여전히 버그를 포함 할 수있는 것입니다. 그 게시물에서 "실험"이라고 불렸다면 테스트하지 않았을 것입니다.

주제로 돌아가서, 여기서 주요 문제는 파손 선언을 피하려는 시도라는 것을 알 수 있습니다. JS 프레임 워크에 대한 나의 제한된 이해로 볼 때, 그들과 "반 임신"하는 것은 매우 어렵습니다. 그리고 일단 당신이 메인 화면 제어가 그들과 함께 이루어 졌다고 결정하면, 모든 것이 그들과 함께 이루어져야합니다. 구텐베르크 편집 화면에서 메타 상자를 일류 시민으로 만드십시오.
"레거시"플러그인은 적응할 가능성이 낮기 때문에 구텐베르크가 기존 사이트에 대한 명시적인 옵트 인 옵션이 필요함을 의미합니다. 나는 UX 포크에 대한 아이디어가 싫지만 적어도 이런 식으로 작동 할 방법이있을 것이고 지금 선언된다면 사람들은 준비 할 수있을 것입니다.

토론을 읽고 WordPress로 구축 한 프로젝트와 사람들이 WordPress로하는 일에 대해 생각한 후 Gutenberg가 사용자 지정 게시물 유형을 선택해야한다는 결론에 도달했습니다. 이렇게하면 구조화 된 데이터에 CPT를 사용하는 현재 웹 사이트가 계속 작동하고 WordPress가 CMS로 사용되는 새로운 웹 사이트가 구축 될 수 있습니다. 게시물 유형을 등록 할 때 다른 기능과 함께 편집기 필드에 대한 지원을 명시 적으로 선언 할 수 있음을 상기시키고 싶습니다. 그렇다면 구텐베르크에 대한 명시적인 지원을 추가하지 않는 이유는 무엇입니까? 물론 이것은 게시물과 페이지에 추가 된 메타 상자 문제를 해결하지 못하지만 향후 WordPress를 CMS로 사용할 수있게합니다.

해당 iframe에 하나의 새로운 문제를 추가 할 수 있습니다. 사용자 세션이 나가면 WP 로그인 화면이 Gutenberg 위에 표시되고 iframe 내부에 두 번 표시됩니다.

개발자가 인식 할 수 있도록합니다.

더 많이 나는이 모든 것을 더 많이 따른다. 가능한 유일한 방법은 마이크로 소프트가했던 것과 같을 것이라고 확신한다.

Windows XP = Gutenberg가없는 WordPress
Windows 10 = Gutenberg의 Wordpress.

이 2 개는 다른 패키지와 혼합 및 업데이트 할 수 없습니다.

Joomla와 Drupal이 해냈습니다. 왜 안돼. 내가 선호하는 것은 아니지만 대안은 무엇입니까?

토론을 읽고 WordPress로 구축 한 프로젝트와 사람들이 WordPress로하는 일에 대해 생각한 후 Gutenberg가 사용자 지정 게시물 유형을 선택해야한다는 결론에 도달했습니다.

분할 관리자는 구텐베르크에서 나올 수있는 최악의 결과 중 하나입니다. https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341752490에 이유를 설명했습니다.

이 토론은 정말 카프카 에스크가되고 있습니다. 얼마나 많은 사람들이 현재의 고충 점에 대한 실용적인 해결을 제안하더라도 비판에 완전히 영향을받지 않는 핵심적인 사람들이 몇 명있는 것 같습니다. 불행히도이 사람들이 최종 발언권을 가진 사람들입니다. 지금까지 토론에서 몇 명의 핵심 사람들이 수백 명의 개발자를 걱정할 수 있음을 보여줬 기 때문입니다. WordPress 생태계에 미치는 모든 피해에 대해 걱정합니다. 편집 화면이 아닌 Gutenberg를 편집자로 만드십시오. WordPress를 깨지 마십시오.

Kevin Hoffman :

저는 Yoast가 제시 한이 개념에 매우 동의합니다.이 개념은 에디터 구성 요소에 집중하기 위해 프로젝트의 범위를 축소하면서 이미 수행 된 작업의 대부분을 유지하는 것처럼 보입니다. 출처 : https://yoast.com/gutenberg-alternative-approach/

Yoast가 제안한 경로는 WordPress Core의 큰 개선이 될 것이라고 믿습니다. 많은 사용자가 현재보다 개선 사항으로 수용 할 콘텐츠를 만드는 새로운 편집기. WordPress에 대한 작은 단계이지만 사용자에게는 큰 개선입니다.

이것은 뜨거운 주제입니다. 나는 때때로 우리 (적어도 나는)가 내 의견을 무시할 수 있음을 인정하고 이에 대해 사과합니다. 우리는 좋은, 나쁜, 객관적, 쓸모없는 피드백을 많이 받고 있으며 때로는 그들을 구별하기가 어렵습니다. 우리는 인간입니다. 방정식의 반대편에 서서 이것을 만들고이 모든 피드백을받는 사람이 되십시오. IT는 "개인적 공격"에 가깝다고 느낄 수 있지만 뇌는 무시하는 방식으로 반응하는 경향이 있습니다.

댓글을 달고 블로그 게시물을 읽는 사람들은 종종 우리가 메타 박스 문제와 관련된 모든 것을 발견하고 있다고 생각합니다. 하지 않았다. 우리는 지금 1 년 동안 구텐베르크에서 일하고 있습니다. 구텐베르크를 방금 발견 / 시도했지만 그렇지 않을 수도 있습니다. 대부분의 이전 버전과의 호환성 문제에 익숙해 지도록 충분한 시간 동안 작업하고 있으며 대부분에 대한 답변을 제공합니다.

마음을 열고 몇 가지 질문에 답하는 것으로 시작하겠습니다.

구텐베르크의 목표는 무엇입니까?

구텐베르크의 주요 목표는 워드 프레스 코어의 미래로가는 길을 닦는 것이 아닙니다. 기술적으로는 REST API, 클라이언트 측 UI를 활용하고 핵심 개념 (위젯, 단축 코드, 블록, 콘텐츠 메타 박스)을 고유 한 개념 "블록"아래에 통합하고 다음 질문에 답하여 현명한 경험을 할 수 있습니다. 웹 사이트 구축을 단순화 할 수있는 방법 (사용자 지정 고려) 워드 프레스에서 콘텐츠 (편집기)를 게시합니다.

구텐베르크 편집자의 목표는 무엇입니까?

여기저기서 읽는 것과 달리 초점은 항상 전체 페이지를 재 설계하는 것이 었습니다. 구텐베르크 편집자 페이지의 첫 번째 모형은 매주 두 번째 또는 세 번째 구텐베르크 회의에서 표시되었습니다. 우리는 아직 프로토 타이핑 단계에있었습니다. 첫 알파보다 몇 달 전. 디자인은 지금 우리가 가진 것과 비슷했습니다.

Metabox는 어떻습니까? WordPress에 중요합니까?

그들은. Shortcodes, Custom TinyMCE Buttons와 마찬가지로 WordPress의 편집기 페이지를 확장하기 위해 많이 사용되고 남용됩니다.

Shortcodes, TinyMCE Buttons 및 Metaboxes의 차이점은 무엇입니까?

가장 큰 차이점은“Metaboxes”에는“목적”이 없다는 것입니다. Shortcodes 및 TinyMCE 버튼에는 일관성없이 편집기 페이지를 확장하는 방법 일뿐입니다.

단축 코드는 렌더링 단계에서 콘텐츠로 변환 된 문자열이고, TinyMCE 버튼은 TinyMCE 도구 모음에 추가 된 사용자 지정 버튼이며 TinyMCE API를 사용하여 편집기의 콘텐츠와 통신합니다. 메타 박스? 모르겠습니다. 그것들은 무엇이든 될 수 있습니다. HTML, 자바 스크립트 및 PHP를 추가하여 편집기 페이지를 확장하고 저장시 작동하는 방식을 추가합니다.

이“목적”의 부족이 문제입니까, 아니면 이점입니까?

잘! 플러그인은 다음과 같은 것을 포함하여 에디터로 원하는 모든 것을 할 수 있기 때문에 "프로"로 볼 수 있습니다.

• 버튼, 텍스트 영역, 입력, div 등을 대체합니다. DOM에 대한 전체 액세스
• TinyMCE의 전역 인스턴스를 포함한 전역 자바 스크립트 변수 사용

유연한 권리! 그러나 WordPress 업데이트는 어떻습니까? 편집자 화면에 대한 모든 업데이트. 모든 TinyMCE 업데이트, 모든 클래스 변경, 모든 새로운 div , 모든 버튼 제거 / 이동, 모든 변경 사항은 플러그인과의 호환성을 깨고 있습니다. Core WordPress 개발자는 Metabox를 사용하는 플러그인이 무엇인지 알 수 없기 때문입니다.

WordPress의 장기적인 관점에서 Metaboxes가 (구텐베르크에 관계없이) 진화를 잠그고 있다고 결론을 내릴 수 있습니까?

네, 그렇습니다. 인터넷 역사는 진화하지 않는 기술이 죽을 정도로 여러 번 증명되었습니다. (이 답변이 마음에 들지 않으면 의견이 아니라 사실입니다)

좋아요,하지만 우리가 Metaboxes에 갇혀 있다면 어떻게 워드 프레스를 발전시킬 수 있을까요?

좋은 질문입니다. 답변하기 전에 WordPress 플러그인에서 현재 메타 박스 사용을 이해해야합니다.

현재 플러그인은 Metabox를 어떤 용도로 사용합니까?

"Metaboxes"플러그인에는 두 가지 범주가 있습니다.

• 콘텐츠로서의 메타 박스 (종종 포스트 메타에 저장되지만 항상 그런 것은 아님)
• 에디터 경험 향상을위한 메타 박스 (SEO, 맞춤법 검사,…)

좋아, 이것을 알면 어떻게 앞으로 나아갈 수 있습니까?

세 가지가 필요합니다.

• Gutenberg (또는 WordPress에 대한 모든 업데이트)가 배송되는 동안 이러한 플러그인을 빌드하거나 업그레이드하는 방법을 제공합니다.
• 이러한 플러그인을 사용하는 사람들에게 가능한 최상의 업그레이드 경로를 제공하십시오. 여기에는 다음이 포함됩니다. 이러한 플러그인이 향후 진화와 함께 계속 작동하는지 확인하고 파손을 최소화하는 방법을 확인하십시오.

좋습니다.하지만 에디터 페이지를 변경하면 플러그인이 깨질 것이라고 말하지 않았습니까 (콘텐츠 영역 만 교체하는 것을 포함하여)?

권리! 따라서 플러그인을 중단하지 않으려는 경우 고유 한 옵션이 남습니다. 변경없이 현재 편집 페이지를 유지할 수있는 방법을 제공합니다. 이것이 바로 Gutenberg를 비활성화하는 플러그인의 목적입니다.

개인적으로 좋은 업그레이드 경로라고 부르지 않을 것입니다. 업그레이드도 아닙니다. 더 좋은 것이 있습니까?

이 업그레이드 경로 (구텐베르크 비활성화)는 필수이지만 더 잘할 수 있습니다. 메타 박스를 사용하여 플러그인을 살펴보면 90 %가 콘텐츠 영역과 상호 작용하지 않으므로 콘텐츠 영역 만 교체하면 (요스트 접근 방식) 플러그인의 10 % 만 중단됩니다.

따라서 파손되지 않는 유일한 방법은 구텐베르크를 비활성화하는 것입니다.

최적의 Gutenberg User Experience는 메타 박스 플러그인을 새로운 Gutenberg Extensibility API로 동일한 기능을 제공하는 플러그인으로 대체하는 것으로 구성됩니다.

즉, Metabox를 사용하는 대부분의 플러그인은 메타 박스를 게시하기 위해 저장되는 콘텐츠로 사용하고 있으며 플러그인 작성자가 플러그인을 업그레이드하는 동안 전체 경험을 즐길 수 있도록 Gutenberg 화면에서 작업 할 수 있습니다.

이것이 모두가 말하는 iframe 솔루션입니까?

네, 그렇습니다. 우리는 단점 (링크, 모달, 자산 재로드)이 있지만 동시에 전체 Gutenberg Experience를 즐기면서 플러그인의 80 %가 작동 할 수있는 iframe의 메타 상자를 보여줍니다. 이 솔루션은 방금 도착했으며 아직 실험 중입니다. 확실한 것은 모든 메타 박스를 작동시키고 편집기를 변경할 수있는 방법이 없다는 것입니다.

업그레이드 가능성을 요약 해 주시겠습니까?

확실한.

1- 구텐베르크 비활성화 : 플러그인을 100 % 중단하지 마십시오.
2- 구텐베르크가 콘텐츠 영역 만 대체 : 플러그인의 90 %가 작동하고 UX가 어려움
3- Gutenberg가 전체 화면을 대체합니다. 플러그인의 80 %가 작동하고 UX가 더 좋습니다.
4- 호환 가능한 플러그인이있는 구텐베르크 : 최상의 UX

그래서 우리는 무엇을해야합니까?

우리의 목표는 WordPress의 미래를위한 최상의 옵션이기 때문에 4 번째 옵션을 구축하는 것입니다. 또한 우리의 목표는 필요한 경우 두 번째 및 세 번째 옵션을 달성하기 위해 조각을 재사용 할 수있는 방식으로 구텐베르크를 만드는 것입니다.

다른 옵션보다 옵션을 선택하려면 어떻게해야합니까?

이것은 아직 결정되지 않았습니다. 원하는 업그레이드 경로를 선택할 수있는 플러그인이있을 수 있습니다. 일부 Metabox를 감지하여 자동으로 다운 그레이드하는 것은 옵션입니다.

이것이 바로 이러한 문제의 원인을 설명하는 것입니다. "어리 석음", "잘 관리되지 않음", "불완전한 구현"과 같은 단어로 대답하고 싶다면 제발 ... 저의 인내심은 1 년 내내 WordPress 전체 (코어 및 커뮤니티)를위한 최선의 방법은 한계에 가깝습니다. 개인적으로이 문제에 대해 더 이상 답변하지 않을 수도 있지만 피드백에 귀를 기울이고 있으며 피드백에 확신이 들면 추론을 조정할 것입니다.

우리는 모두 같은 배를 타고 있으며 WordPress에 최고를 원합니다.

매우 철저한 설명, Riad. 시간을 내 주셔서 감사합니다. 💪과 🤗으로 그 한계를 벗어나도록 도와 드리겠습니다. 도움이 되었기를 바랍니다.

메타 박스와 관련하여 필자는 Fields API를 코어에 포함하고 싶어합니다. 시간이 지나면 수집되는 사용자 지정 메타 박스 솔루션이 엉망이되는 모든 것을 없애기 위해 플러그인을 다시 작성할 것입니다.

이제 복잡한 메타 박스 설정을 가진 사람들을 위해 Fields API는 ACF 또는 CMB와 같은 프레임 워크를 기반으로 구축 한 한 그들의 구원입니다. 이러한 프레임 워크의 개발자는 새 API로 전환하기 만하면됩니다. 쉬운 일은 아니지만 모두에게 좋습니다. 이제 "하드 코딩 된"물건이있는 사람들을 위해 이제는 더 깨끗하고 미래를 대비 한 방식으로 물건을 재구성하는 것이 그 어느 때보 다 좋은 때입니다. 구텐베르크 여부에 관계없이 더 나은 몸매입니다.

우리는 인간입니다. 방정식의 반대편에 서서 이것을 만들고이 모든 피드백을받는 사람이 되십시오. IT는 "개인적 공격"에 가깝다고 느낄 수 있지만 뇌는 무시하는 방식으로 반응하는 경향이 있습니다.

구텐베르크에서 매우 열심히 일하는 사람들이 있습니다. 구텐베르크의 영향을받는 생계 (테마 및 플러그인)를 가진 인간이 있습니다. 그리고 구텐베르크의 영향을받은 테마와 플러그인을 사용하여 자신의 작업을 수행하는 인간이 있습니다. 우리는 모두 서로를 찾고 있으며 하루가 끝나면 WordPress에 가장 적합한 것을 원합니다. 우리는 "최고"가 무엇을 의미하는지에 대해 열정적으로 동의하지 않을 수 있습니다.

여기저기서 읽은 것과 달리 초점은 항상 전체 페이지를 재 설계하는 것이 었습니다. 구텐베르크 편집자 페이지의 첫 번째 모형은 매주 두 번째 또는 세 번째 구텐베르크 회의에서 표시되었습니다.

Mockup만으로는 전체 편집 페이지의 코드 기반이 React에서 다시 작성 될 것이라는 신호를 보내지 않았습니다. 중요한 후크가 제거되거나 메타 상자가 손상 될 것이라는 모형을 보는 사람은 아무도 모릅니다. 그러나 전체 페이지를 차지하는 것이 메타 박스에 문제가 될 것이라는 것이 분명해 졌을 때, 나는 0.1.0 이 출시되기 전날 인 6 월 15 일에 그 우려

나는 알파 이전 단계부터 Gutenberg를 면밀히 따르고 테스트 한 경험을 바탕으로이 문제를 만들었습니다. 이것은 진행중인 메타 박스 챌린지와 관련된 최신 문제 일 뿐이지 만, 중요한 것은 구텐베르크의 메타 박스 구현에 대한 구체적인 테스트를 기반으로 한 첫 번째 문제입니다.

가장 큰 차이점은“Metaboxes”에는“목적”이 없다는 것입니다. Shortcodes 및 TinyMCE 버튼에는 일관성없이 편집기 페이지를 확장하는 방법 일뿐입니다.

이것은 플러그인 및 테마 개발자가 메타 상자를 사용하는 방법에 대한 근본적인 오해를 다시 나타냅니다. 단축 코드와 TinyMCE 버튼은 실제로 콘텐츠 편집기 내에서 사용되기 때문에 조정이 필요합니다. 메타 상자는 없습니다.

사용자 지정 WordPress 개발의 기본 구성 요소 인 메타 상자가 다시 의미가 없다고 제안하면 구텐베르크가 플러그인 및 테마 개발자를 희생하여 "새 설치"의 핵심 경험을 우선시하고 있음을 커뮤니티에 알립니다.

편집자 화면에 대한 모든 업데이트. 모든 TinyMCE 업데이트, 모든 클래스 변경, 새 div, 모든 버튼 제거 / 이동, 모든 변경 사항은 플러그인과의 호환성을 깨고 있습니다. 핵심 WordPress 개발자는 Metabox를 사용하는 플러그인이 무엇인지 모르기 때문입니다.

우리는 메타 박스의 목적을 모를 수도 있지만 메타 박스를 등록하기위한 기본적인 요구 사항과 그들이 사용하는 후크를 알고 있습니다. 우리는 그들 중 어느 것도 iframe 내에서 작동하도록 개발되지 않았다는 것을 알고 있습니다. 수년 동안 우리는 WordPress를 중단하지 않고 확장하고 향상시키는 방법을 이해했습니다. 다시 말하지만 5.0이 또 다른 WordPress 릴리스 인 경우 파손 정도는 다른 릴리스와 다르지 않습니다.

우리는 단점 (링크, 모달, 자산 재로드)이 있지만 동시에 전체 Gutenberg Experience를 즐기면서 플러그인의 80 %가 작동 할 수있는 iframe의 메타 상자를 보여줍니다.

지속적으로 참조되는 80 % / 90 % 숫자에 대한 증거가있는 경우 공유하십시오. 그렇지 않으면 커뮤니티에이 정도 규모의 결정을 내릴 때 가상 통계를 사용하지 마십시오.

잠시 중단하고 나중에 다시 평가하십시오.

이 토론의 모든과 내가가 iframe이 가능한 장기적인 해결책없는 것이 었습니다 증거를 생각하면, 나는 우연히 https://github.com/WordPress/gutenberg/issues/3165#issuecomment 외모가 세 번째를 추가하는 것을 -341476059

한계가없는 것처럼 이상적인 편집기를 추구하는 것을 멈추고 WordPress를 깨지 않는 접근 방식을 고려하기 시작할 때입니다.

1 일차부터 구텐베르크 편집자를보고 논의 해 온 개발자로서 Riad의 주장에 큰 구멍이 있다는 점에 유감입니다.

첫째, 사람들은 첫날부터 메타 박스 문제를 제기 해 왔으며 아직 진행중인 몇 가지 다른 문제도 있습니다. Mockup 단계에서 우리는 "모든 것이 시각적으로 가장 좋은 경우입니다. 나중에 메타 박스를 다룰 것입니다"라는 말을 들었습니다. 그런 다음 프로토 타입 단계에서는 "이것은 모두 개념 코드의 증명이며 메타 박스는 나중에 다룰 것입니다"였습니다. 그런 다음 기능 플러그인의 첫 번째 반복이 출시되었을 때 (아무에게도 놀랍게도 처음부터 다시 작성하는 것이 아니라 현재 개념 증명 코드를 다시 패키징 한 것이 었습니다) 논쟁이 갑자기 시작되었습니다. "메타 박스와 같은 레거시 인터페이스는 현재 약간의 지원을받을 것입니다." 그런 다음 대중의 외침이 귀를 멀게 만들었을 때 "우리는 잘못 이해했습니다. 메타 박스는 유산이 아닙니다"였습니다. 그러나 이제이 주장은 "레거시"의제를 다시 밀어 붙이고 있습니다.

메타 박스는 현재 실행 가능한 대체가 없기 때문에 레거시 코드가 아닙니다.

메타 박스에서는 wp_editor 사용하여 모든 기능을 갖춘 중첩 편집기를 간단하게 추가 할 수 있습니다. Gutenberg는 현재 중첩 된 블록에 대한 UI가 없으며 5.0 릴리스가 예정되어 있지 않으므로 엄청난 양의 사용자 정의 UI 코드 없이는 동일한 작업을 수행 할 수 없습니다.

그것은 하나의 예이지만, 구텐베르크가 패리티를 넘어 설 때까지 메타 박스의 경험을 저하시키는 것은 수용 가능한 해결책이 아닙니다. WP 5.0에서는 발생하지 않습니다.

다음은 실제로 작동하는 Gutenberg의 "통합 관리자"계획에 대한 로드맵입니다.

• 초기 릴리스를 현재 wp_editor로 채워진 영역으로 제한하지만 해당 공간 내에서 전체 블록 UI를 제공합니다.
• 블록 UI가 허용하는 유연성과 기능을 촉진하고 확장하여 해당 공간에서 설계하는 것이 사소한 필드 API를 제공합니다.
• 인기가 높아짐에 따라 ui의 다른 부분을 유사한 샌드 박스 Gutenberg 인스턴스로 교체하십시오. 메뉴, 위젯, 커 스터 마이저 및 미디어 라이브러리는 모두 개발자에게 상대적으로 정체 된 인터페이스이며 공통 UI 구조의 이점을 누릴 수 있습니다.
• 공통 UI가 더 유연하고 강력 해짐에 따라 사람들은 공통 도구 세트와 더 많은 옵션을 제공하기 때문에 메타 박스 대신 사용하도록 선택할 것입니다.
• 그 공간의 개발이 정체됨에 따라 고립 된 구텐베르크 개체 사이의 구멍을 점차적으로 병합합니다.

이렇게하면 개발자는 현재 보유하고있는 기능을 잃지 않고 프로덕션 도구에서 Gutenberg를 활용할 수 있습니다. Gutenberg는 이러한 개발자를 위해 개발 된 모든 엣지 사용 사례의 이점을 활용하여 현재 메타 박스를 사용하는 사람들의 요구를 실제로 충족 할 수있는 유연한 솔루션을 만들 것입니다.

메타 박스가 더 이상 사용되지 않을 때까지 플러그인 작성자는 구텐베르크의 이점을 익히고 사용할 수있는 충분한 시간을 갖게되었으며 이는 분명한 선택이 될 것입니다.

구텐베르크는 컨셉 카와 같습니다. 지금 다시 축소하고 편집기 페이지가 아닌 편집기에 반복적 인 개선 사항을 제공합니다. 그런 다음 1 ~ 2 년 동안 프로젝트를 100 % 관리 범위로 진행할 수 있습니다.

나는 WordPress의 이전 버전과의 호환성에 대한 보컬 약속을 참조하여 웹 사이트를 손상시키는 업데이트에 대한 클라이언트의 우려를 완화 한 클라이언트 서비스 공급자의 관점에서 시작하고 싶습니다. 이를 통해 WordPress 사용이 편집 화면에 대한 내 인식을 왜곡 / 편향했을 가능성이 있음을 알고 있습니다.

현재까지이 문제는 사용자 지정 게시물 유형이 널리 사용 가능하게 된 이후로 내 세계에서 메타 상자가 WordPress의 _major_ 판매 포인트가되었을 때 punted / dismissed / downplayed 된 것처럼 느껴집니다. 이 토론이 일어나서 기쁩니다.

구텐베르크는 인상적인 프로젝트입니다.하지만 제가 일한 고객들은 제공받은 메타 박스 기반 솔루션에 정말 만족합니다. Gutenberg를 비활성화하는 옵션이있는 것은 좋지만 플러그인을 통해 옵트 아웃되는 것이 걱정됩니다. 고객을지도하기위한 최선의 노력에도 불구하고, 그들이 스스로 새로운 플러그인을 설치할 의향이 있거나 업그레이드 환영 화면에 노골적으로 등장하더라도 Gutenberg가 무엇인지 알지 못할 것입니다.

클라이언트 사이트에서 사용한 메타 박스 플러그인이 "Gutenberg 호환"으로 업데이트 될 수 있지만 (아마도) 전체 워크 플로가 해당 클라이언트에 대해 하룻밤 사이에 변경 될 수 있습니다. 사이트가 오래 전에 제공 되었기 때문에 기존 워크 플로가 잘 수행되었는지 많은 고객에게 묻는 것처럼 느껴집니다.

저는 구텐베르크가 사용자 경험을 개선한다는 목표를 전적으로지지하고 있지만 제 생각에는 콘텐츠 편집에 메타 상자를 사용하기 위해 (의도적이든 아니든) 자리 잡은 선례를 피할 수 없습니다. Yoast의 접근 방식은 훌륭하다고 생각합니다.이 문제에 대한 다양한 잠재적 솔루션에 대한 여러 확인란을 선택하는 것입니다.

여기에서 결과를 관찰하기를 고대하고 있습니다.

Gutenberg와 함께 작동하는 플러그인의 수는 테스트에서와 같이 80 %, 90 % 또는 0 % 일 수 있습니다. 피해야 할 것은 수천, 수천 명의 사이트 소유자가 자신의 구성이 작동 할 것인지 작동하지 않을 것인지 스스로 알아 내야한다는 것입니다. 구텐베르크와 함께. 그것은 엄청난 시간 낭비 (= 돈)이고, 많은 혼란을 야기하고 많은 신뢰를 죽일 것입니다.

플러그인 / 테마가 Gutenberg와 호환 / 비 호환 (또는 '관련 없음')으로 표시된 것을보고 싶습니다. 그러면 사이트 소유자가 사이트에서 활성화되기 전에 잠재적 인 문제에 대해 알리고 그에 따라 조치를 취할 수 있습니다. 데이터는 플러그인 소유자뿐만 아니라 베타 테스트 기간 (실제 베타 ... 및 해당 기간이 몇 주가 아닌 길어야 함) 및 그 이후의 커뮤니티 테스트에서도 가져올 수 있습니다.

나는 이것이 완전하거나 100 % 정확하지 않을 것이라는 것을 알고 있지만, 가장 눈에 띄는 플러그인에 대해서는 가능해야합니다.

추신.
내 프로젝트 (직원 30.000 명을 초과하는 고객을위한 인트라넷 마이크로 사이트 플랫폼, 소규모 비즈니스 / 비영리 사이트)를 위해 우리는 구텐베르크가 야생에서 성공적으로 1 년 이상 될 때까지 비활성화하기로 결정했습니다.

백분율은 어쨌든 전체 이야기를 말하지 않습니다. 구텐베르크의 영향에 대한 모든 논의는 영향을받는 플러그인 수보다는 메타 박스 구현에 의해 영향을받는 웹 사이트 수를 고려해야합니다. 가장 널리 사용되는 플러그인 중 일부는 메타 박스와 사용자 정의 필드에 의존하기 때문에 구텐베르크는 소수의 플러그인에만 영향을 미칠 수 있지만 여전히 수백만 명의 사용자에게 영향을 미칠 수 있습니다.

나는 멀리서도 구텐베르크의 개발을 수개월 동안 지켜 왔고 메타 박스 문제가 오랫동안 존재 해 왔다는 것을 _ 알고 있습니다. 저는 구텐베르크의 철학을지지하며 결국 구텐베르크는 워드 프레스 코어의 매우 강력한 부분이되어 워드 프레스가 향후 수년 동안 실행 가능하고 경쟁력있는 소프트웨어가 될 수 있도록 할 것입니다. 나는 구텐베르크의 전체 개념과 그 목적을 이해하고 있습니다.

내가 이해하지 못하는 것은 한 번에 0에서 100까지 도달하려는 욕망입니다. 반복 릴리스가 여기서 수행되는 경로가 아닌 이유는 무엇입니까? 두 가지 옵션이 '아무것도 해제'또는 '모든 것을 해제'하는 이유는 무엇입니까?

메타 박스는 워드 프레스가 강력한 이유입니다. 그 목적은 편집 화면을 확장하는 것입니다.

구텐베르크가 전체 화면을 점검하고 싶어한다는 것은 대단하다고 생각하지만, 특히 워드 프레스의 가장 중요한 구성 요소 중 하나를 처리하는 것을 의미한다면 한 번에하는 것이 현실적이지 않다고 생각합니다. 워드 프레스 성공의 큰 부분입니다.)

2- 구텐베르크가 콘텐츠 영역 만 대체 : 플러그인의 90 %가 작동하고 UX가 어려움

UX는 고통을받지 않습니다. 사용자는 개정되는 편집기 섹션으로 볼 수 있습니다. 콘텐츠를 만드는 새로운 방법을 제공 할 것입니다. 대부분의 사용자가 조정 후 힘을 얻을 수있는 방법을 제공하고 기존 워크 플로를 깨뜨 리거나 이전에 수행 한 작업을 수행하는 방법을 궁금해하게 만들지 않습니다. 편집자.

4- 호환 가능한 플러그인이있는 구텐베르크 : 최상의 UX

이것은 훌륭한 목표이지만 장기적인 목표입니다. 결국 그렇습니다. 절대적으로 Guteneberg 경험과 함께 또는 내부에서 작동하는 플러그인이있는 Gutenberg 여야합니다.

또한 우리의 목표는 필요한 경우 두 번째 및 세 번째 옵션을 달성하기 위해 조각을 재사용 할 수있는 방식으로 구텐베르크를 만드는 것입니다.

이것이 무엇을 의미하는지 잘 모르겠습니다. 플러그인이 모두 작동한다는 가정하에 Gutenberg를 빌드하고 해당 솔루션을 사용하여 옵션 2와 3으로 돌아가고 싶습니까? 2를 향해 먼저 빌드 한 다음 3으로 반복하면 4에 도달하게되지 않습니까?

맞춤형 WordPress 웹 사이트를 구축하는 개발자로서 @gschoppe가 제안한 로드맵이 마음에

iframe에 대한 Kevin의 우려와 함께 몇 가지 접근성 문제를 지적하고 싶습니다. 첫째, 사이트를 시각적으로 경험하는 사용자는 페이지의 나머지 부분과 함께 프레임 셋 및 iframe을 응집력있는 전체로 경험하지만 스크린 리더 사용자는 그렇지 않습니다. 웹 페이지는 선형 방식으로 경험되기 때문에 스크린 리더 사용자는 프레임 세트 내에서 각 프레임을 경험하고 각 iframe은 페이지의 나머지 부분과 별개로 별개의 부분으로 경험합니다. 일부 화면 판독기 (특히 WEBAIM의 연간 화면 판독기 사용 조사에 따르면 시장 점유율이 가장 높은 Windows 용 Jaws)에는 일부 화면에 너무 불편할 수 있기 때문에 인라인 프레임을 포함하여 프레임을 무시하는 구성 설정이 있습니다. 독자 사용자. 프레임 무시 설정을 호출하면 프레임 및 iframe 내의 내용이 사라집니다. 구텐베르크가 iframe과 관련하여 모든 접근성 모범 사례를 따르더라도 콘텐츠를 완전히 편집 할 수 있도록 사용자에게이 설정을 비활성화하도록 요청하면 인터넷상의 모든 단일 iframe 인스턴스 및 프레임 최악의 사례에 노출됩니다. 이러한 사용자를위한 유일한 대안은 구텐베르크를 사용하기 위해 별도의 프로필을 생성하도록 요청하는 것입니다. 이는 간단한 프로세스가 아닙니다. 이는 모든 단일 브라우저 설정과 음성 설정을 다시 구성해야하기 때문입니다. 또한 최소한 두 개의 개별 브라우저 프로필을 따라야한다는 의미이기도합니다. 저는 Windows 사용자 용 Jaws에게 이유 때문에 NVDA로 풀 타임으로 마이그레이션하라고 말하는 첫 번째 사람이 될 것입니다. 메타 박스 지원을 위해 iframe을 사용하는 Gutenberg는 그러한 이유 중 하나가 아닙니다.

.. 워드 프레스 전체 (코어 및 커뮤니티)를위한 최선의 방법을 생각하며 1 년을 보낸 단순한 개발자로서의 저의 인내심은 거의 한계에 가깝습니다.

나는 무례한 것이 싫지만 그 경우에는 더 두꺼운 피부를 가져야 할 수도 있습니다. 당신은 이것에 대해 생각한 "전체 1 년"을 앞두고 응답에 좌절하고 그렇게 해주셔서 감사합니다. 그러나 이것은 다른 사람들이 수행 한 여러 해 동안 의 작업에 영향을 미칠 결정입니다.

제 경우에는 제가 읽고있는 내용에서 지난 3 년 동안 구축 한 거의 모든 웹 사이트가 즉시 중단 될 수 있습니다. 나는 더 이상 이러한 사이트에 대한 책임이 없지만 수십 명의 고객이 한 번에 깨진 사이트로 전화를 걸었을 때 내가 일했던 에이전시에서 무슨 일이 벌어 질지 모릅니다. 그것이 그 작은 에이전시, 일상 업무, 수익에 어떤 영향을 미칠까요? 고객에게 어떤 영향을 미칠까요? 이것이 저의 관심사이며 저는 상대적으로 큰 생태계에서 작은 (비상 적으로) 한 명의 개발자 일뿐입니다.

나는 때때로 우리 (적어도 나는)가 내 의견을 무시할 수 있음을 인정하고 이에 대해 사과합니다.

사람들은 걱정하고 좌절하고 있습니다. 구텐베르크에서 일하는 팀은 메타 박스가 어떻게 사용되는지에 대한 이해가 거의없고 영향이 무엇인지에 대한 관심이 거의 없다는 인식 이 있기 때문에 그들이 그렇게 할 수있는 모든 권리가있는 것 같습니다. 어떤 일이 있어도 그들의 비전을 가지고 앞으로 나아갈 것입니다.

이 글을 쓰는 것은 저를 슬프게하지만, 지금 당장 워드 프레스로 주요 프로젝트를 시작하는 사람은 백만 년 안에 제안하지 않을 것입니다.

2- 구텐베르크가 콘텐츠 영역 만 대체 : 플러그인의 90 %가 작동하고 UX가 어려움

@youknowriad , Gutenberg 대 TinyMCE에서 UX가 어떻게 고통받지 않는다고 말할 수 있습니까? 나는 진심으로 그 질문을하고 있습니다. TinyMCE 및 메타 박스에 비해 구텐베르크에서 UX가 실제로 크게 어려움을 겪고 있다고 말할 수 있습니다. 나는 당신이 이것을 스스로 찾아내는 것을 권장합니다 :

(1) 마우스 플러그를 뽑습니다.
(2) Mack를 사용하는 경우 command + f5를 누르고 VoiceOver를 사용하여 생산적인 작업을 수행합니다.
(3) PC를 ​​사용하는 경우 NVDA를 다운로드하여 설치하고 마우스를 분리 한 다음 동일한 테스트를 수행하십시오. 이러한 상황에서 구텐베르크와 함께 생산적인 작업을 수행하십시오.

이 시점에서 UX가 절대적인 악몽이라는 것을 알게 될 것입니다. 그것은 더 나은쪽으로 바뀔 수 없다는 것을 말하는 것이 아닙니다. 구텐베르크는 WordPress가 접근성과 관련하여 많은 기술적 부채를 해결할 수있는 기회를 제공하며, 이것이 신중하고 올바르게 수행된다면 엄청난 성과를 거둘 수 있습니다. 그러나 이것이 잘못되거나 부주의하게 수행된다면, 워드 프레스 접근성 팀과 다른 핵심 기여자들이 2012 년 이후로 한 많은 작업을 다시 시작해야 할 것입니다. 워드 프레스는 처음부터 웹 접근성을 고려하지 않는 프로젝트로보고 싶습니다 : 처음부터 웹 접근성을 고려하지 않았습니다. 즉, 접근성 팀과 다른 관련 기여자들이 사실 이후 접근성에 대한 책임을지고 있다는 것을 의미합니다. 워드 프레스는 정체 된 코드베이스가 아니기 때문에 절대 따라 잡을 수 없습니다.

나는 너희들이 구텐베르크에서 1 년 동안 일하고 있다는 것을 알고있다. 나는 또한 이것에 대한 작업 자체가 힘들고 부정적인 피드백이 그 상황에 도움이되지 않는다고 생각합니다. 마지막으로, 우리만큼 비판적인 사람들은 아기를 못 생겼다거나 단순히 변화에 대한 두려움에 반응하는 것처럼 보일 수 있으며, 창조자로서 그것은 기껏해야 실망스럽고 최악의 경우 상처를 입힐 수 있습니다. . 그러나 나 자신을 위해 말하면 아기는 못 생기지 않습니다. 그것은 블록에서 가장 멋진 아이이거나 모든 사람의 삶을 비참하게 만드는 작은 바보가 될 수있는 실현되지 않은 많은 잠재력을 가지고 있습니다. 나는 그것이 후자가 아니라 전자 인 것을보고 싶다. 특히 메타 박스와 관련하여, 그들은 워드 프레스 사용자 정의 개발의 문자 그대로 스테이플이며 아마도 단축 코드 또는 TinyMCE 버튼 일 것입니다. 그것들을 제거하는 방법을 알아낼 수있을 때까지 가볍게 털어 내거나 iframe에 밀어 넣어서는 안됩니다.

WordPress에 대한 저의 간단한 이야기는 10 년 이상 개인, 중소기업 및 기업 고객을위한 웹 사이트를 만들기 위해 선택한 웹 사이트 엔진이었습니다. 그 당시 WordPress를 선택한 도구로 만든 세 가지가있었습니다.

1. 오픈 소스. 나는이 청중이 이것이 얼마나 강력하고 유리한지 동의 할 것이라고 생각한다.
2. 사용의 용이성. WordPress를 사용하면 개발자가 아닌 사람이 콘텐츠를 만들고 업데이트하는 것이 놀랍도록 쉬워졌습니다. 이것은 개인과 기업을위한 웹 사이트를 만든 초기 시절에 엄청났습니다.
3. 콘텐츠 정의. 사용자 지정 게시물 유형, 사용자 지정 분류 및 사용자 지정 메타 상자. 이것으로 이어지는 모든 것이 특이점에 도달했을 때, WordPress가 단순히 블로그 소프트웨어 이상으로 비즈니스 커뮤니티에 "판매 가능"했던 때라고 말했을 때 도달하지 못했다고 생각합니다. (WordCamp Phoenix 2012-CMB. Justin Tadlock의 게시물 유형, 분류 및 메타 상자 정의에 대한 훌륭한 글.)

사용자 지정 메타 박스에 대해 말씀 드리고자합니다. 사용자 지정 관리 인터페이스를 생성하여 사람들에게 훌륭한 사용자 경험을 제공하는 능력은 엄청납니다. 그것을 깨면 WordPress를 깨고 있습니다.

콘텐츠 편집기 경험을 더욱 강력하게 만드는 Gutenberg의 아이디어는 훌륭한 아이디어입니다. 할만한 가치가 있지만 서두르지 말고 조심스럽게 올바르게해야합니다. 지금은 매우 서두르고 준비가 거의되어 있지 않습니다.

@jchristopher 는 그것을 아주 잘 말합니다.

저는 구텐베르크가 사용자 경험을 개선한다는 목표를 전적으로지지하고 있지만 제 생각에는 콘텐츠 편집에 메타 상자를 사용하기 위해 (의도적이든 아니든) 자리 잡은 선례를 피할 수 없습니다. Yoast의 접근 방식은 훌륭하다고 생각합니다.이 문제에 대한 다양한 잠재적 솔루션에 대한 여러 확인란을 선택하는 것입니다.

@jnicol 과 @aurooba 는 좋은 지적을하고 좋은 질문을합니다. 반복적 인 로드맵이 아닌 전부 또는 아무것도 아닌 것처럼 보이는 이유는 무엇입니까? Yoast의 대안은 지금까지 본 것보다 훨씬 합리적이며“iframe 실험”이 그 점을 증명한다고 생각합니다. 접근성 문제를 불러 주신 @amandarush님께 감사드립니다. 나는 모든 사람들에게 그녀가 설명하는 방식으로 구텐베르크와 함께 일하도록 도전합니다. 일부 관점을 바꿀 수 있습니다.

@aaronjorbin 은 이전에 누군가 WordPress를 채택 할 때 WordPress (버전 번호-여기)를 채택하지 않고 WordPress를 전체적으로 채택하고 있다고 말했습니다.

클라이언트 서비스의 모든 사람이 자주 듣게 될 또 다른 버전이 있습니다. 누군가가 여러분에게 와서 새 웹 사이트가 필요하다고 말하면 (블로그에 대해 이야기하는 것이 아닙니다) 일반적으로 "새 Wordpress 웹 사이트가 필요합니다."또는 "새 Drupal 사이트를 원합니다"등을 말하지 않습니다. 그들은 단지 작동하고 잘 작동하는 새로운 사이트를 원합니다.

WordPress는 수백만 개의 웹 사이트를위한 최고의 솔루션이었습니다. 사용 편의성과 오픈 소스가 핵심입니다. 새로운 편집기 인터페이스의 서둘러 구현으로 사용자 지정 메타 상자를 깨 뜨리면 (플러그인 번호는 잊어 버리고, 사용자 지정 관리 UI가있는 모든 기존 웹 사이트는 어떻습니까?) 사용 편의성이 손상됩니다.

워드 프레스 전체 (코어 및 커뮤니티)를위한 최선의 방법을 생각하며 1 년을 보낸 단순한 개발자로서의 저의 인내심은 거의 한계에 가깝습니다.

나는 여기서 무뚝뚝해질 것입니다.

이것과 이와 같은 몇 가지 다른 의견은 여러분 중 일부가이 프로젝트에서 의사 결정 역할에서 물러나야한다고 생각하게합니다. 제품에 대해 정직하고 신중하게 생각하지만 비판적인 피드백을받을 수 없다면 솔직히 제품 팀에서 의사 결정 역할을해서는 안됩니다. 나는 당신의 입장에서 여러 번, 일반적으로 대면 회의에 참석했으며 성공적인 경우 회의실의 모든 사람들은 논쟁이 아무리 뜨거워도 고객에게 가능한 최고의 제품을 제공하는 것임을 깨달았습니다. 제품 아이디어와 방향에 대한 비판을받는 것은 제품 팀의 의사 결정권자의 일부이며, 누구도 최선의 방법을 생각할 수 없기 때문에 더 나은 제품으로 이어져야합니다. 팀도 마찬가지입니다.

핵심 팀의 모든 사람들이 멋진 WordPress 개정판을 제공하기를 원하지만 필연적으로 프로젝트에 가까워 질 수 있습니다. 토론, 고려, 거부 등이 무엇인지 알고 있으며 외부 관점에서 무언가를 끌어 내고 보는 것은 어렵습니다. 그러나 당신은 WP 커뮤니티의 전체가 아닙니다. 당신은 될 수 없습니다. 당신이 듣는 것은 제품 방향에 대한 유효한 우려입니다. 기내에서 그것을 받아 들일 수 없다면, 무슨 말을하는지, 왜 그렇게 말했는지 생각해보십시오. 구텐베르크의 방향에 대한 결정을 내리지 마십시오.

또는 (그리고 이것은 훨씬 더 좋을 것입니다), 이러한 생각을하십시오. 사람들이 말하는 것을 진정으로 고려하십시오. WordPress를 사용하는 비즈니스를 운영하는 사람들로서 우리의 관심사를 이해하고 우리 자신뿐만 아니라 고객에게도 관심이 있다는 것을 이해하십시오.

저는 2008 년 초부터 WP를 사용해 왔으며 현재의 형태로 구텐베르크의 도입만큼 많은 부문을 창출 한 새로운 기능이나 결정을 생각할 수 없습니다.

WordPress는 사용자를 대상으로하지만 도구 일 뿐이며 목표 달성을 도울 WP 전문가가없는 경우 사용자는 해당 도구를 사용할 수 없습니다.

새로 설치 한 사용자를 수용하고 싶다는 언급을보고 있지만 (무엇입니까? 연간 웹 증가의 1 % 정도?) 기존 사용자 기반 (~ 28 %)의 대가를 치르는 것 같습니다. 대부분은 메타 상자가 하나 이상있는 플러그인을 실행하고있을 가능성이 높습니다. 규모에 관계없이 비즈니스 감각이 좋지 않은 것 같습니다.

나는 이데올로기를 얻습니다. 최고의 편집기를 만든 다음 어댑터 패턴을 사용하여 이전과 새 것으로 이야기하십시오. 문제는 PHP와 JS가 서로 다른 기술이며, 이전에 제공된 모든 이유로 인해 해당 문제를 HTML iframe의 영역으로 전달하는 것은 불가능하다는 것입니다.

첫 번째 통과 였고 실험 이었지만이 노력은 성공하지 못했습니다. 더 빨리 확인 될수록 다음 제안으로 더 빨리 이동할 수 있습니다.

하지만 모든 당사자를 만족시키는 메타 박스의 경우 적절한 솔루션을 찾는 사람은 아무도 없습니다.

즉, 한 당사자는 참을성이 필요합니다. 10-50 명의 친 구텐베르크 개발자 든, 아니면 _ 무서워하는 개발자 수백 / 천명이든, 사용자는 물론 변경 사항이 그들에게 미칠 영향이든 우리는 알게 될 것입니다.

모든 대안 제안이 소진되면 전체 페이지를 재정의하는 것이 모든 당사자에게 적합하지 않다는 양보가있을 수 있습니다. 적어도 현재 시도중인 단일 히트에는 없습니다.

원래 질문으로 돌아가려면 iframe이 메타 박스의 장기적인 솔루션입니까? 여러 개발자 (그것도 사용자라는 사실을 잊지 마세요)가 대답이 '아니요'인 이유를 설명했습니다.

우리는 여기서 크게 건설적인 논의를하고 있습니다. 생각해 내다:

우리는 그 뒤에있는 인간이 아니라 아이디어, 코드, 픽셀을 비판합니다. 최선의 방법에 대해 의견이 다를 수 있지만 자격 증명에 의문을 제기하지는 않습니다. 우리가 개인에게 말을 걸 때, 그들을 들어 올려 잘한 일에 대해 공로를 인정하는 것입니다. 세상에서 너무 많은 일이 일어나고 있기 때문에 우리는 서로를 돌봐야합니다. 이것은 기념비적 인 도전이지만 우리는 함께 할 것입니다.

구텐베르크의 메타 박스가 @ BE-Webdesign이 한 단계 더 나아가이 작업을 수행 한 결과, 거의 도움없이 다른 사람들과 독립적으로 갑자기 나타난 결과임을 모두에게 상기시켜 드리겠습니다. @ BE-Webdesign이 아니었다면 Gutenberg에 메타 박스가 없을 것입니다. 여기에 남겨진 47 개의 댓글 중 2 명만이 리뷰 및 UX 목적으로 메타 박스 코드를 실제로 만졌습니다.

하지만 여기서 근본적인 문제는 안전하지 않은 코드를 작성하지 않고 1 급 시민으로서 메타 박스를 페이지에 안전하게 가져 오는 방법입니다.

• 첫 번째 반복에는 WP가 edit.php 페이지에있는 것처럼 가장하여 메타 박스를 생성하는 문제가 포함되었습니다. 초기 보고서에 따르면 호환성 문제가 있으며 실행 가능한 솔루션이 아니라 매우 해킹당했습니다. 이는 많은 플러그인이 특정 상황이 충족되는 경우에만 메타 박스를 등록하고 WP를 렌더링 할시기를 알지 못하기 때문입니다.
• 병합 된 두 번째 반복은 iframe을 사용하므로 메타 박스를 제외한 모든 항목이 제거되었지만 메타 박스가 클래식 편집기에 표시됩니다. 이것은 약간 복잡하지만 문제가 있지만 메타 박스가 작동합니다.
• HTML 코드를 가져온 다음 구성 요소에 전체적으로 삽입하는 솔루션도 있습니다. 이는 매우 명백한 솔루션 임에도 불구하고 보안 재앙이 될 것입니다. 따라서 왜 이런 식으로 수행되지 않았습니다.

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

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

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

• 우리는 iframe 말도 안되는 것을 피합니다
• 메타 박스는 등록에 관한 한 항상 그랬던 것처럼 작동합니다.
• 기존 JS는 예상대로 작동하며 PHP 끝에서 작업을 수행하는 데 해킹이 필요하지 않습니다.

또한 yoast 디자인은 예쁘지 만 블록 메타는 어디로 갈까요?

불행히도 저는 Gutenberg에 실제 코드를 제공하는 데 필요한 수준의 js에 대한 경험이 거의 없습니다. 나는 WordPress를 개발하는 것보다 개발하는 세계에 발을 담그기 시작했습니다. 그래서 제가 할 수있는 최선은 피드백을 제공하고 편집자를 테스트하고 (저는 개인 블로그에서 구텐베르크를 적극적으로 사용합니다) 제안 / 생각을 제공하는 것입니다. 내가 코드를 제공 할 수 있다면 절대 그렇게 할 것입니다. 제가 도울 수있는 다른 방법이 있다면 알고 싶습니다. 나는 이것에 대해 많이 신경을 쓰거든요. :)

기여는 다양한 형태로 제공됩니다. 이 시도를 개발하는 데 소요 된 시간과 노력은 높이 평가되지만 향후 매몰 비용을 방지하는 테스트와 논의도 그만큼 가치가있을 수 있습니다. 예를 들어 iframe 구현과 관련하여 새로 열린 문제가 많이 있습니다. 우리는 이러한 문제를 해결하는 데 더 많은 시간을 할애하거나이 스레드의 테스트와 근거를 사용하여 다른 방향이 필요한지 결정할 수 있습니다. 그것이 우리가 그룹으로 도달 한 실현 이었으면합니다.

구텐베르크의 메타 박스가 @ BE-Webdesign이 한 단계 더 나아가이 작업을 수행 한 결과, 거의 도움없이 다른 사람들과 독립적으로 갑자기 나타난 결과임을 모두에게 상기시켜 드리겠습니다. @ BE-Webdesign이 아니었다면 Gutenberg에 메타 박스가 없을 것입니다.

칭찬과 숭배는 멋지지만 😄, 확실히 도움을 받았으며 대부분 많은 사람들의 팀 노력입니다.

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

설정 페이지에서 Gutenberg를로드하는 대신 기본 클래식 편집기 페이지에로드하고> 메타 박스를 기본 환경에로드 한 다음 JS를 통해 컨테이너 DOM 노드를 컴포넌트로 끌어 올립니다.

예, 이것이 다음 반복 일 가능성이 높으며 건설적인 아이디어 일뿐만 아니라 훌륭한 제안이라고 생각합니다. 이 작업을 깨끗하게 수행하는 방법을 아직 100 % 확신하지는 못하지만 iframe을 사용하지 않고 Gutenberg가 이미 제공하는 것과 동일한 향상된 UX를 갖는 것은 전적으로 가능합니다. 메타 박스 환경을 개선하기위한 업데이트가있을 예정이며, 이는 iframe 제거를 포함 할 것입니다. iframe 방법은 메타 박스 지원이 어떻게 구현 될 수 있는지 확인하는 방법으로 사용되었으며 이제 더 나은 개선이 이루어집니다. 몇 달 전 (새로운 주제가 아님) 메타 박스로 처음 탐색되었을 때, 당시 구텐베르크의 상태로 인해 iframe 접근 방식으로 진행하는 것이 합리적이었습니다. 기술적 인 관점에서 보면 iframe을 더 이상 사용할 필요가 없습니다. 더 많은 작업이 필요합니다.

@ BE-Webdesign 여기에 귀하의 노력과 의견에 감사드립니다. 이 접근 방식을 논의 할 준비가되면이 문제를 해결하고 새로운 문제를 시작하겠습니다.

잠시 중단하고 나중에 다시 평가하십시오.

모든 사람이 프로젝트 설계에 대한이 접근 방식에 익숙한 것은 아니지만 이것은 거의 모든 것을 매일 지속적으로 재평가하는 프로젝트입니다. 원본 모형을 현재 편집기와 비교합니다. 모든것은 변한다. 대부분의 조각은 돌로 설정되지 않습니다. 어떤 것이 효과가 있는지를 진정으로 평가하는 유일한 방법은 실제로 실행하는 것입니다. 모든 사람이 제품 디자인에 똑같은 방식으로 접근하는 것은 아니지만 Gutenberg의 빠른 반복은 미리 알려지지 않은 것을 해시하려고 시도하는 것보다 잘 제공하고 있다고 생각합니다.

토론 해주신 모든 분들께 감사드립니다. 대화가 주제의 문제로 다시 집중되어 기쁩니다. _iframe의 메타 박스에 대한 현재 접근 방식이 실행 가능합니까? 대답은 아니오입니다. iframe은 상대적으로 쉽게 삭제할 수 있다고 생각하는 구현 세부 사항입니다. 그래서 그것에 집중합시다.

결론적으로, 편집 화면에 대해 아무것도 변경하지 않는 것이 우리가 할 수있는 가장 간단한 경로라고 덧붙이고 싶습니다. 또한 프로젝트의 목표와 WordPress의 장기 사용자에게도 불공평합니다. 일부 사람들이 실용적인 접근 방식이라고 부르는 것은이 프로젝트가 처음부터 가져 왔던 디자인 방향 (전체 사이트 사용자 지정을 향한) 및 지금까지 우리의 결정을 지시 한 것과 수반되지 않습니다. 여기에 최종 솔루션이 될 필요는 없습니다. 우리는 설계 전제 내에서 가능한 것을 탐구하고 테스트를 위해 거기에 배치하고 있습니다. 이것은 우리 혼자서 만들 수 없으며 극복해야 할 길에 몇 가지 어려운 문제가 묻혀 있기 때문에 여러분 모두로부터 얻을 수있는 모든 도움을 진심으로 환영합니다.

WordPress는 항상 사용자와 함께 이동하며 기존 코드를 쉽게 전환 할 수 있도록 개발 경로를 파악해야합니다. 프로젝트로서, 우리는 WordPress에서 메타 박스에 대한 지원을 중단하지 않고, 클래식 편집기를로드 할 수있는 가능성을 포함하여 새로운 패러다임 내에서 어떤 인터페이스 결정을 내려야하는지 탐색해야한다고 말했습니다. 우리가 처리 할 수없는 메타 박스 또는 콘텐츠가 무엇이고 메타 데이터가 무엇인지를보다 명확하게 설명하려는 편집자와 직접 충돌하는 메타 박스를 감지합니다. 지금 당장 기본 구텐베르크 경험의 혜택을받을 수있는 사람들이 있습니다. 개발자로서 우리는 솔루션을 제조 할 수있는 특권을 누릴 수있을뿐만 아니라, 그렇지 않으면 어려움을 겪을 사람들이 오픈 웹에 존재하도록 허용하기 위해 변경해야하는 변경 사항을 피하지 않을 책임도 있습니다.

@mtias 특히 "WordPress는 항상 사용자와 함께 움직입니다"에 대한 귀하의 현명한 의견에 진심으로 감사드립니다.

안타깝게도 @youknowriad 가이 스레드에서

안타깝게도 기존 메타 박스와 호환되는 동시에 구텐베르크의 모든 유연성을 제공하는 Yoast 스케치를 언급하지 않았습니다. 왜 당신이이 접근법을 고려하지 않는지 누군가가 인정할 수 없습니까?

불행히도 이것은 @youknowriad 가이 스레드에서 통신 한 것과 완전히 상충됩니다.

제가 말한 내용을 오해하신 것 같습니다. 사실을 열거하는 중이고 @mtias 생각을 100 % 공유합니다.

@mtias

일부 사람들이 실용적인 접근 방식이라고 부르는 것은이 프로젝트가 처음부터 가졌던 디자인 방향과 수반되지 않습니다.

나는이 견해에 정말로 동의하지 않는다. 편집기 자체에 제한되어 있지만 메타 박스를 대체 할 수있는 힘이있는 반복적 인 향상을 만들고 필드 API를 릴리스하고 승격하는 것은 단순히 사용 편의성만으로 플러그인의 대량을 블록 패러다임으로 전환하는 부드러운 방법이 될 것입니다. , 우리가 지금 가지고있는 부서진 풍경과 비교하면.

매끄럽게 중간 전환을 수행하면 post_edit 화면에서 직접 DOM 생성 / 조작을 더 이상 사용하지 않도록 훨씬 쉽게 만들 수 있습니다. 그때까지는 표준 실제 솔루션이 더 이상 그러한 조작을 포함하지 않기 때문입니다. 나는 누구도 "직접 DOM 조작이 영원히 기본 경험이되어야한다"고 말하지 않는다. 그들은 "이제 기본 솔루션"이라고 말합니다.

전체 화면 솔루션으로 dom 조작의 완전한 유연성을 유지할 수 있다면 시도해보십시오 ...하지만 그것은 매우 높은 목표 인 것 같습니다. 그리고 클래식 편집 화면의 어떤 형태 든 호이 스팅이 실제로 제공 할 수 있을지 의심 스럽습니다. 합리적인 수준의 호환성. 내가 틀렸을 수도 있지만, 반복적 인 접근 방식이 동일한 작업을 수행 할 수있는 경우 사용자 전환을 시도하는 것은 엄청나게 복잡한 해킹처럼 보입니다.

현재 패러다임의 우선권을 유지하면서 새로운 패러다임을 공개함으로써 다른 사람의 현재 경험을 해치지 않고 채택을 장려 할 수 있습니다. 그런 다음 대부분의 워크 플로가 블록 패러다임으로 전환되면 직접 DOM 제어를 사용하지 않고 전체 화면 솔루션을 사용할 수 있습니다.

프로젝트의 목표를 배신하는 것이 아니라 단순히 릴리스 일정을 해결하여 수천 개의 대행사와 개발자가 변경 사항을보다 쉽게 ​​관리 할 수 ​​있도록합니다.

@youknowriad 내가 말하는 것을 뒷받침하기 위해 작성한 내용의 몇 가지 스 니펫을 게시하겠습니다.

REST API, 클라이언트 측 UI를 활용하고 핵심 개념 : 위젯, 단축 코드, 블록, 콘텐츠 메타 박스를 고유 한 개념 "A Block"아래 통합

아무도 "콘텐츠 메타 박스"를 블록으로 바꾸라고 요청하지 않았으며 구텐베르크가 초기 버전을 출시 할 때까지 통신되지 않았습니다. 사실, 이것이 논쟁의 핵심입니다. 메타 박스가 페이지 콘텐츠가 아닌 경우가 많기

여기저기서 읽는 것과 달리 초점은 항상 전체 페이지를 재 설계하는 것이 었습니다. 구텐베르크 편집자 페이지의 첫 번째 모형은 매주 두 번째 또는 세 번째 구텐베르크 회의에서 표시되었습니다. 우리는 아직 프로토 타이핑 단계에있었습니다.

구텐베르크 팀은 스케치가 최종 디자인이 아닌 쇼용이라고 계속 말했습니다. 게다가 스케치는 전체 편집 화면이 React로 변환되었는지 아니면 그냥 다르게 스타일이 지정되었는지 보여줄 수 없습니다. 전체 페이지가 다시 디자인 될 것이라는 사실은 내가 말한 모든 사람들에게 큰 놀라움으로 다가 왔습니다.

Shortcodes, TinyMCE Buttons 및 Metaboxes의 차이점은 무엇입니까?
가장 큰 차이점은“Metaboxes”에는“목적”이 없다는 것입니다. Shortcodes 및 TinyMCE 버튼에는 일관성없이 편집기 페이지를 확장하는 방법 일뿐입니다.

이것은 Automattic에서 눈썹을 올려야하는 거대한 오해입니다. (그리고 @mtias 와 @m 이 듣고 있기를 바랍니다). 이는 사실이 아니며이 진술에 따른 귀하의 판단에 의문을 제기합니다.

WordPress의 장기적인 관점에서 Metaboxes가 (구텐베르크에 관계없이) 진화를 잠그고 있다고 결론을 내릴 수 있습니까?
네, 그렇습니다.

여기에서는 거의 아무도 동의하지 않는다고 말하고 싶습니다. Automattic은 제품 방향을 결정하기 위해 이것을 투표에 넣어야한다고 생각합니다.

나는 또한 기여해야하는 사람들과 같은 말을하는 @mtias 에게 질문한다. Automattic과 관련된 Gutenberg 팀이 한 치도 싹 트지 않고 모든 비판을 회피하고 있다는 것은 분명합니다.

나는 구텐베르크를 편집 구성 요소로 줄이기 위해 PR을 만들면 Automattic 내에서 몇 명의 개인이 작성한 진술로 인해 구텐베르크 팀에서 고려할 것이라는 믿음이 없습니다.

@mtias ,

결론적으로, 편집 화면에 대해 아무것도 변경하지 않는 것이 우리가 할 수있는 가장 간단한 경로라고 덧붙이고 싶습니다. 또한 프로젝트의 목표와 WordPress의 장기 사용자에게도 불공평합니다.

한 번에 한 걸음 씩 나아가는 것은 어떤 식 으로든 프로젝트의 목표를 손상시키지 않습니다 . 그것이 목표라면 풀 사이즈 커스터마이징으로 갈 수 있지만, 단계적으로 수행하면 나머지 개발자 커뮤니티도 함께 가져올 수 있습니다.

Customizer가 이에 대한 대표적인 예입니다. 예, 비판이 있지만 최종 개념은 시간이 지남에 따라 특정 사용자 그룹이 WP를 사이트 관리 도구로 효율적으로 활용할 수 있도록하는 기능이 될 것입니다.

지금 당장 기본 구텐베르크 경험의 혜택을받을 수있는 사람들이 있습니다.

물론. 그러나 현재 기본 구텐베르크에 해로운 경험을 할 사람이 훨씬 더 많습니다.

나는 우리 모두가 우리의 응답에서 존경심을 가지고 나아가 제품에서 사람들을 분리 할 수 ​​있기를 바랍니다. 열정은 훌륭하지만 우리가 이와 같은 스레드에서 상호 작용하는 인간에 대해 생각하는 것이 중요합니다. 이 프로젝트에 참여한 모든 사람은 관심을 갖고 있으며, 그렇지 않으면 이러한 스레드에오고 상호 작용하지 않을 것입니다. 이제 숨을들이 마시고 우리 모두가 WordPress에 얼마나 관심을 갖고 있는지 기억하고 댓글의 중심에이 커뮤니티를 모든 사람을 위해 안전하고 생산적으로 유지하기를 원합니다.

@khromov ,이 프로젝트의 디자인 리더 인 Matias가 기술 리더 인 것처럼 저는 @youknowriad에 100 % 뒤처져 있습니다. 나는 당신이 열정적이지만 존중하지 않는다는 것을 이해합니다. 한 사람을 불러서 접근 방식을 조정하십시오. 개인적인 행동을 그만합시다.

구텐베르크에서 일하는 많은 사람들이 이전에 WordPress 커뮤니티의 회원이었고 이전에는 여전히 핵심 기여자 였음을 기억하는 것이 중요합니다. 네, 저도 포함됩니다. 저는 여기서 매우 개인적으로 말할 것입니다. 일단 PR을하면 저에게 알려 주시면 어디에서 왔는지에 상관없이 모든 리뷰가 동일한 존중을 받는지 살펴 보겠습니다. 제발,이 프로젝트를 '우리 대 그들'로 보는 것에서 넘어 갑시다. 여기에 Automattic이 아닌 놀라운 기여자가 있습니다. 그 진술은 그들에게 해를 끼칩니다.

헉

나는 일반적으로 구텐베르크를 비방하는 사람으로 여겨진다. 내 게시물과 댓글은 내가 접근 및 구현에 대해 보는 문제를 강조하지만, 구텐베르크의 목표와 진행 상황은 때때로 오해 또는 이해 부족으로 인해 댓글에서 오해된다고 생각합니다. 프로젝트의 중요한 목표입니다.

블록은 게시물 콘텐츠를 표현하고 편집하는 시각적 인 방법이 아니며 콘텐츠 선택기 메뉴의 일부이거나 끌어서 놓을 수있을 필요도 없습니다. 물론 그것들은 그러한 것들에 사용될 수 있으며, 이것이 구텐베르크의 눈에 보이는 부분들 중 많은 부분이 강조한 워크 플로우입니다. 그러나 그 패러다임에 대해 알고있는 것을 잠시 무시하고 대신 다음과 같이 살펴보십시오.

블록은 인터페이스 나 스토리지에 관계없이 사이트의 기본 제어 구조를 의미합니다.

• 위젯은 블록이 될 예정입니다. 그렇다고 에디터에 존재하고 post_content에 저장된다는 의미는 아닙니다. 이는 단순히 하나의 공통 API를 사용하여 JavaScript 프레임 워크에 구축 된 시스템으로 제어된다는 것을 의미합니다.
• Customizer는 블록으로 대체 될 예정입니다. 인터페이스는 (대략) 동일하게 유지되지만 Customizer의 섹션은 동일한 API에 의해 제어됩니다.
• 플러그인 페이지, 테마 편집기, 대시 보드 자체는 모두 결국 블록이 될 예정입니다. 이 섹션의 아이디어를 그대로있는 그대로 일반 API로 재현하는 것이 불가능하다면 WordPress 용어로 블록이 무엇인지에 대한 오해가있을 수 있습니다.

문제는 메타 박스가 블록 패러다임 내에서 다시 생성 될 수 없다는 것이 아닙니다. 사실 포스트 유형에 프로그래밍 방식으로 추가되고 제자리에 고정되고 post_content 대신 포스트 메타에 저장되는 비 프런트 엔드 블록이 예정되어 있습니다. WordPress 5.0 릴리스 (내가 틀렸다면 수정).

본질적으로 텍스트 상자 및 선택과 같은 사소한 메타 필드에 대한 모든 요구 사항을 다룹니다. 원하는 경우 해당 인터페이스를 블록으로 정확하게 복제하거나 블록이 제공하는 새로운 시각적 언어를 기반으로 일부를 간소화 할 수 있습니다.

문제는 메타 박스가 블록이 될 수 없다는 것이 아닙니다. 문제는 현재 블록에서 아직 지원되지 않는 메타 박스로 만들어진 인터페이스 (워드 프레스 또는 타사)가 있으며 해당 작업을 다시 구현하는 것은 특히 이러한 도구가 빌드되지 않았기 때문에 개발자에게 어려운 작업이라는 것입니다. 제안 된 Fields API와 같은 공통 API에서 가져 왔지만, 페이지의 DOM을 직접 수정하고 관리되지 않는 임시 방식으로 리소스를 대기열에 추가하는 호지-포지 방식입니다.

이 현재 상태는 개발자에게도 문제를 일으 킵니다. 예를 들어 필드에 대한 Piklist와 함께 Visual Composer를 사용하는 경우 Piklist는 많은 관리 스타일을 재정 의하여 VC를 탐색하기 매우 어렵게 만듭니다.

또는 새 버전의 Select2 라이브러리를 대기열에 추가하는 플러그인과 함께 WooCommerce를 사용하는 경우 하나 또는 다른 하나가 중요한 JS 오류와 함께 관리자 인터페이스를 손상시킵니다.

두 개의 다른 플러그인이 서로 다른 버전의 CMB2 프레임 워크에 의존하는 경우에도 동일한 일이 발생할 수 있습니다.

블록은 다양한 페이지 추가에 대한 공통 프레임 워크를 도입하여 이러한 문제를 해결하려고합니다. 이 프레임 워크 중 일부는 위즈 뱅 드래그 앤 드롭 시각적 요소를 편집기에 제공하는 데 초점을 맞출 것이지만 대부분은 실제로 그것에 묶여 있지 않습니다. 관리자에 표시되는 항목이 일반적인 방식으로 관리되는지 확인하는 것입니다.

이제 WordPress가 Wild West 개발 태도에서 번성했으며이 공통 프레임 워크가 반응을 모르는 개발자를위한 진입 장벽을 높인다는 유효한 주장이 있습니다. 그리고 Block 인터페이스가 출시 전에 널리 퍼진 개발자 채택에 가까운 어떤 것도 도달하지 않을 것이라는 유효한 주장이 있습니다. 현재 블록 API가 약간 순진하고 많은 일반적인 워크 플로를 고려하지 않기 때문에 해당 기능을 만들고 문서화 할 때까지 플러그인을 적용 할 수 없다는 유효한 주장도 있습니다.

그러나 Metabox가 모든 사람을위한 자유롭고 모든 것이 모든 것을위한 해결책이며 영원히 보존되어야한다고 주장하는 것은 누구에게나 큰 진로를 제공하지 않습니다. WordPress가 모든 사용자 (개발자 포함)에게 더 나은 옵션을 제공 할 수 있으려면 일종의 공통 시스템이 있어야합니다.

이 시스템이 몇 년 전에 일반적인 Fields API 였다면 좋았을 것입니다. 따라서 이러한 모든 변경 사항은 대부분 해당 API의 렌더링 단계를 대체하는 것이지만 현재로서는 앞으로 나아갈 경로를 찾아야합니다.

즉, 최종 공통 UI로 이동하는 가장 좋은 실제 방법 인 Yoast의 제안 된 임시 솔루션을 여전히 강력하게 찬성합니다. 나는 물론 비판적이지만 우리가 사실에 대해 비판적이며 오해가 아닌지 확인하고 싶습니다.

안타깝게도 @youknowriad 가이 스레드에서

여기에서는 거의 아무도 동의하지 않는다고 말하고 싶습니다. Automattic은 제품 방향을 결정하기 위해 이것을 투표에 넣어야한다고 생각합니다.

Automattic과 관련된 Gutenberg 팀이 한 치도 싹 트지 않고 모든 비판을 회피하고 있다는 것은 분명합니다.

나는 구텐베르크를 편집 구성 요소로 줄이기 위해 PR을 만들면 Automattic 내에서 몇 명의 개인이 작성한 진술로 인해 구텐베르크 팀에서 고려할 것이라는 믿음이 없습니다.

나는 명백한 것을 말하고 싶지만 Gutenberg는 Automattic 제품이 아니라 WordPress 커뮤니티 프로젝트 입니다. 제가 Automattician이 될 수도 있지만, 어떤 사람들이 제안한 것과는 달리 프리랜서, 에이전시 CEO 또는 회사의 5 % 약속을 이행하는 전담 개발자 등 다른 누구보다이 프로젝트에 대한 더 많은 권한을 부여하지 않습니다. 마찬가지로 WordPress 자체는 Automattic 프로젝트가 아닌 커뮤니티 프로젝트입니다.

Automattic은 WordPress를 "출시"하거나 "구축" 하지 않으며 Gutenberg는 Automattic 제품이 아닙니다.

더욱이이 대화가 더욱 감정적이되어 사람들이 나무의 숲을 잃어 버리기 전에 구텐베르크 팀이 할당 한 작업의 어려움과 그들이 얼마나 잘 처리하고 있는지 시간을내어 감사하고 싶습니다. 일반적으로. 그들은 인터페이스의 작은 한 구석에서만 효과를 보여줄 수있는 제약 내에서 WordPress의 전체 관리자 경험의 기반이 될 패러다임을 만드는 임무를 맡았습니다.

"편집자가 인수한다"는 생각으로 인한 오해의 양은 엄청나고 관리하기가 매우 어려울 것입니다. 그들의 목적은 워드 프레스 관리자를위한 공통 빌딩 블록을 만들고 편집기를 다시 빌드하여 테스트하는 것입니다. 나는이 작업이 wp_editor() 인터페이스를 재 구축하고 거기에서 확장한다면 대중에게 훨씬 더 맛있고 유연 할 것이라고 생각하지만, '편집 경험'의 모든 연결된 구성 요소가 제안 된 새로운 패러다임에 대한보다 완전한 시험.

나는 이해하고이 작업에 들어간 노력의 해에 감사합니다. 나는 여전히 내린 결정 중 일부에 대해 비판적이며 초기 채택을 크게 향상시킬 몇 가지 수정을 할 시간이 있다고 믿지만 궁극적으로 WordPress 관리자 경험을 위해 더 구조화 된 프레임 워크를 제공한다는 중요한 목표에 완전히 동의합니다. , 개발자와 사용자 모두에게.

뿡 빵뀨

@youknowriad를 언급 한 이유는 그가 토론에 참여한 유일한 사람

그럼에도 불구하고 저는 @youknowriad 와 비공개 채팅을

@tomjn

나는 정중하게 동의하지 않습니다. 중요한 결정은 Automatticians가 내리고 @youknowriad 와 대화 한 후 제품 방향이 이미 오랫동안 설정되어 있다는 것을 이해했습니다. 따라서 정기적 인 기여자는 버그 수정과 약간의 시각적 인 문제 외에는 할 일이 없습니다. 조정.

@gschoppe 이 "패러다임 전환"이 공개적으로 논의되고 개발자 커뮤니티와 협력하여 이루어 졌으면합니다. 그게 의도 일 수도 있지만이 경우 통신 측면이 잘 작동하지 않습니다.

왜 당신이이 접근법을 고려하지 않는지 누군가가 인정할 수 없습니까?

@khromov 우리는 이미 가지고 있었고 에디터 채팅의 다른 곳에서 등등.이 문제는 특히 iframe 구현에 관한 것이 었습니다.

나는 구텐베르크를 편집 구성 요소로 줄이기 위해 PR을 만들면 Automattic 내에서 몇 명의 개인이 작성한 진술로 인해 구텐베르크 팀에서 고려할 것이라는 믿음이 없습니다.

전혀. 우리는 너무 제한적이고 우리가 가진 비전을 추진하기에 적절하지 않다는 것을 아주 일찍부터 스스로 고려했습니다. 여전히 많은 사람들에게 합리적인 타협 일 수 있으며 탐색하기에 좋은 플러그인이 될 수 있습니다. 하지만이 작업을 수행하는 데 필요한 작업은 일반적으로 구텐베르크를 재사용 가능하게 만들어 전반적으로 개선 할 것이므로 작업하는 사람들을 반대하지 않을 것입니다. 누군가가 그러한 PR에 대해 작업했다면, 기본으로 설정하는 대신 동작을 토글하기 위해 쓰기 섹션에 설정을 추가하는 것이 좋습니다.

우리는 중첩 된 블록, 전역 블록, 선언 블록 템플릿, 열 등을 중심으로 중요한 기능을 제공합니다.이 기능은 콘텐츠 시트가 전체 페이지 인 경우 실제로 이익을 얻고 그렇지 않으면 개발자가 할 수있는 작업과 사용자가 경험할 수있는 것을 제한합니다. 또한 TinyMCE의 단순한 대체로 고안된 전체 화면 편집기에서 실시간으로 원활하게 통합되는 문서 개요와 같은 멋진 도구도 있습니다.

한 번에 한 걸음 씩 나아가는 것은 어떤 식 으로든 프로젝트의 목표를 손상시키지 않습니다.

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

물론. 그러나 현재 기본 구텐베르크에 해로운 경험을 할 사람이 훨씬 더 많습니다.

물론, 이것이 바로 현재 환경으로 마음대로 돌아가는 플러그인이있는 이유이며, 비 호환성을 처리하는 메커니즘이있어 더 많은 항목을 옵트 인 할 수 있습니다 (예 : 메타 박스에 익숙한 경우). 구텐베르크에서 지원을 선언하거나 그 반대).

@gschoppe 나는 우리가 과거에 우리의 공정한 의견 차이를

Automattic의 당신은 우리가 당신의 작업을 존중할 수 없으며 우리가 당신을 많이 밀고 있다고 불평해서는 안됩니다.
7000-10.000 € 프로 월 급여가 아닙니다. 바보. 사람들이 개발자 자원 봉사자에게 WP Trac에 대해 불평하는 것과는 다릅니다.
구텐베르크가 두통을 주면 상사와 이야기하십시오. 그는 당신에게 불가능한 일을주었습니다.

둘째, 당신은 여기에 댓글을 달 았던 대다수의 사람들보다 훨씬 더 나은 코더입니다. 왜 "Iframes"솔루션을 전달하려고 했습니까?
내가 말 했잖아요, 당신은 사람들을 아이들처럼 대합니다. iframe을 사용해보고 사람들이 크게 비명을 지르고 감정을 많이 느끼는지 살펴 보겠습니다. 노이즈가 많으면 iframe에서 멀어집니다.

왜 "Iframes"솔루션을 전달하려고 했습니까?
내가 말 했잖아요, 당신은 사람들을 아이들처럼 대합니다. iframe을 사용해보고 사람들이 크게 비명을 지르고 감정을 많이 느끼는지 살펴 보겠습니다. 노이즈가 많으면 iframe에서 멀어집니다.

메타 박스 지원이 처음 구현되었을 때 새 편집기는 post.php가 아닌 완전히 새로운 관리자 페이지에 존재했고 편집기는 다르게로드되었으며 일반적으로 많은 제약이있었습니다. iframe을 사용하여 메타 박스 문제를 해결하는 일부 더 이상 존재하지 않는 제약 조건과 그 결과 메타 상자는 더 이상 iframe을 사용할 필요가 없습니다.

이 프로젝트는 단일 릴리스의 완벽보다 릴리스 전반에 걸쳐 점진적인 개선을 선호합니다. 아무도 사람들이 비명을 지르는 지 확인하려고하지 않습니다. 현실은 사람들이 이것을 만들었음에도 불구하고 iframe 접근 방식이 대부분의 메타 박스에서 잘 작동했습니다. 이제 더 개선 될 것이며, 점점 더 적어 질 것입니다 😱 🙀.

@StaggerLeee는 어디서 일하든이 프로젝트의 모든 사람을 존중 해주십시오. 누군가가 당신을 잘 대하기를 바라는 것처럼, 다른 사람들에게도 똑같이하십시오.

나는이 프로젝트의 디자인 리더로서 당신이 누구에게도 말한 개인 진술을 보지 않을 것입니다. 나는 누군가가 일하는 곳이나 그들의 배경에 상관하지 않습니다. 그것은 당신이 부를 권리가없는 개인 정보입니다. 개인을 버리고 제품에 집중하십시오.

이제 우리가 할 수있는 최고의 제품을 만드는 데 집중 해 보겠습니다. 나는 당신의 포인트가 종종 열정의 장소에서 비롯된다는 것을 절대적으로 이해합니다. 당신은 존경심과 열정을 가질 수 있습니다.

Automattic의 당신은 우리가 당신의 작업을 존중할 수 없으며 우리가 당신을 많이 밀고 있다고 불평해서는 안됩니다.
7000-10.000 € 프로 월 급여가 아닙니다. 바보. 사람들이 개발자 자원 봉사자에게 WP Trac에 대해 불평하는 것과는 다릅니다.
구텐베르크가 두통을 주면 상사와 이야기하십시오. 그는 당신에게 불가능한 일을주었습니다.

@StaggerLeee 나는 그 정도의 힌트 힌트를 받았으면 좋겠지 만 Automattic은 Google이 아니고 WP 세계의 다른 곳에서 더 많은 수익을 올릴 수 있습니다. 여기에있는 내 존재는 순전히 내 자신에서 벗어난 것이며, 여기에있을 수있는 대가를 받지도 않았고,이 작업을하는 다른 많은 사람들도 마찬가지입니다. 저는 실제로 코드 검토를 수행하고 엔터프라이즈 클라이언트를 시작하는 데 도움을주는 대가를 받았습니다!

따라서 메시지가 수신되었다고 믿으십시오. 증거는 상단의 Pull Requests 탭에 있습니다. 이것은 Automattic 음모가 아니므로 클라이언트에서 코드와 p ** s를 깰 수 있습니다 (_ 잊지 마세요. Automattic은 메타 박스도 사용 _)

여전히 iframe에 관심이있는 사람들을 위해 iframe을 실행 취소하고 이전에 제안한 제안을 구현하려는이 Pull 요청 (https://github.com/WordPress/gutenberg/pull/3345)을 살펴 보는 것이 좋습니다.

메타 박스 구현의 다음 반복에서 호환성 문제를 테스트하고 식별하는 것이 좋을 것입니다. A8C에 대한 썩은 열매를 던지는 것은 기분이 좋을 수도 있지만 도움이되지는 않습니다.