바텐더에게 질문: 마크업 변경을 차단하면 어떻게 됩니까?

저는 최근에 Gutenberg와 함께 개발을 시작한 개발자입니다. 놀라운 이점과 기능이 많이 있지만 단점, 불일치 및 절대적으로 끔찍하고 오래된 문서도 있습니다.

개발자 관점에서 Gutenberg의 최악의 측면 중 하나는 블록 유효성 검사였습니다. 다음 시나리오를 고려하십시오. 사용자 지정(비동적) JavaScript 기반 블록을 만들고 CMS 편집기가 블록을 수천 페이지에 추가합니다. 블록의 마크업을 업데이트해야 하는 경우 또는 필요한 경우 어떻게 됩니까?

기본적으로 모든 블록은 무효화 상태가 되며 사이트의 프런트 엔드에 반영되지 않습니다. CMS 편집기는 수천 페이지로 이동하여 블록을 복구할 수 있는 버튼을 수동으로 클릭해야 합니다.

이 문제를 해결하기 위한 방법으로 블록 지원 중단이 제안되었지만 API는 문서화되지 않고 혼란스럽고 몇 가지 지원 중단으로 장기적으로 유지 관리할 수 없게 될 것 같습니다.

블록 개발자가 검증 프로세스를 거부할 수 있는 방법이나 블록을 복구하는 글로벌 방법이 있어야 하지 않습니까?

PJ

당신은 확실히 아무것도 억제하지 않습니다, PJ. 이 중 많은 부분이 내가 일반적으로 여기 선술집에서 다루고자 하는 것보다 약간 더 기술적인 것이지만, 상황에 대한 더 많은 통찰력을 얻기 위해 수석 Gutenberg 개발자 중 한 명인 Riad Benguella에게 연락하기로 결정했습니다.

그의 답변에 대해 알아보기 전에 귀하의 질문에 대한 한 가지 측면을 생각해 봤습니다. 개발자가 이전 마크업을 더 이상 사용하지 않고 새로운 것으로 옮겨야 하는 경우가 있습니다. 그러나 이것은 자주 발생해서는 안됩니다. 일반적으로 HTML을 정기적으로 점검해야 하는 경우 아키텍처가 좋지 않다는 신호입니다. 이것은 또한 제3자가 스타일 변경을 유지할 수 없는 것과 같은 다른 문제로 이어집니다.

프론트엔드 코드를 출력하는 블록이나 모든 유형의 애플리케이션을 개발할 때 현재와 10년 후의 모습에 대해 생각해야 합니다. 사용자가 블록의 스타일을 지정하기 위해 일부 사용자 정의 CSS를 추가하고 블록의 HTML 구조가 변경된 경우 어떻게 됩니까? 그들의 관점에서 귀하의 차단 업데이트로 인해 사이트가 손상되었습니다. 어떤 식으로든 플러그인을 확장하는 다른 플러그인에 대해서도 마찬가지입니다.

Gutenberg/WordPress가 블록 출력을 변경할 때마다 테마 작성자에게 얼마나 답답한지 물어보십시오. 지난 몇 년 동안 개선되었지만 에디터와 프론트엔드의 스타일링 블록은 종종 유지 관리의 악몽이었습니다.

개발자로서 저는 항상 사용자의 관점에서 이러한 변경의 실제 결과를 생각하려고 노력했습니다. 이는 프로젝트를 출시한 후가 아니라 1일 차부터 이루어져야 합니다.

이렇게 하면 초기 프로젝트에 시간을 추가하고 사용자의 손에 전달하려고 할 때 시간이 추가됩니다. 여기에서 출시 전 단계로 물러나는 것이 도움이 됩니다. 컴퓨터에서 멀리 떨어지십시오. 산책을 하세요. 프로젝트의 아키텍처와 그것이 장기적으로 이상적인지 생각해 보십시오.

Benguella는 "블록 버전 관리/업데이트의 경우 실제로 구조적 절충안이 필요한 구텐베르그 API 영역 중 하나이며 개발자보다 사용자 경험을 선호하기로 결정했습니다."라고 말했습니다.

개발 방법에 관계없이 사용자 우선 경험에 대한 프로젝트의 접근 방식을 따르면 장기적으로 도움이 될 것입니다.

"문제를 제대로 이해하려면 블록이 어떻게 작동하고 편집되는지 이해해야 합니다."라고 Benguella는 말했습니다. “블록 인스턴스는 JSON 개체이고 편집기 UI는 해당 JSON을 조작하지만 이전 버전과의 호환성을 유지하고 사용자 콘텐츠를 가장 읽기 쉬운 형식으로 보존하고 웹 표준을 최대한 수용하기 위해 블록 편집기 JSON 객체를 저장하지 않고 post_content 에 HTML 직렬화를 저장합니다.”

해당 직렬화는 편집자가 다시 편집할 콘텐츠를 다시 로드할 때 구문 분석되고 JSON으로 변환됩니다. 구문 분석의 마지막 단계에서 객체를 저장하고 구문 분석하는 방법을 결정하는 것은 블록 작성자에게 달려 있습니다.

Benguella는 "이제 사용자가 저장된 HTML(직렬화)을 변경하고 임의의 콘텐츠를 거기에 넣는 경우를 상상해 보세요. "블록은 HTML이 예상과 일치하지 않기 때문에 HTML을 제대로 구문 분석하지 못할 수 있습니다(블록 작성자가 정의한 것). 즉, 이 시점에서 조작하기 위해 JSON 객체를 다시 생성하는 것은 불가능합니다. .”

이 경우 블록 편집기는 사용자에게 정보에 입각한 결정을 내릴 수 있는 인터페이스를 제공합니다. 그들은 블록 JSON을 "강제 구문 분석"하거나 HTML 또는 클래식 블록으로 변환하려고 시도할 수 있습니다.

플러그인 개발자가 블록을 업데이트할 때 이와 동일한 유형의 무효화가 발생할 수 있습니다. 그러나 저장된 HTML이 변경되는 대신 개발자가 블록의 "기대"를 변경하여 저장 및 구문 분석 방법을 변경했습니다.

Benguella는 "이것이 우리가 블록 개발자에게 동일한 블록의 이전 마크업을 나타내는 블록 사용 중단을 제공하도록 요청하는 이유입니다."라고 말했습니다. “사용 중단은 동일한 블록에 대한 유효한 대체 소스로 생각할 수도 있습니다. 이를 통해 편집기는 로드될 때 이전 마크업을 구문 분석하고 블록이 업데이트되면 새 마크업을 다시 저장할 수 있습니다.”

WordPress에는 블록 사용 중단 문서가 있습니다. 그러나 철저하지는 않습니다. 실제 사용 중단을 볼 수 있는 가장 좋은 소스는 Gutenberg의 블록 라이브러리를 살펴보는 것입니다. 더 이상 사용되지 않는 블록에는 deprecated.js 파일이 있습니다.

Benguella는 이 시스템이 블록 작성자에게 좌절감을 줄 수 있다고 말했습니다. 이것은 변경을 수행할 때 개발 환경에서 특히 분명합니다. 이로 인해 개발자는 유효성 검사 알고리즘을 비활성화하는 방법을 요청하게 되었습니다.

"위에서 설명한 것처럼 다른 이유로(외부 편집, 다른 편집자 등) 마크업이 변경될 때 유효성 검사도 중요하기 때문에 현재로서는 제공하고 싶지 않은 것입니다."라고 그는 말했습니다. “그래서 사용자가 알지 못하는 사이에 콘텐츠 손실이 발생할 수 있습니다. 지금은 사용자 인지도가 우선입니다.”

팀은 시간이 지남에 따라 유효성 검사 시스템을 개선하여 블록 상태를 손상시키지 않는 작은 변경 사항을 허용합니다. 향후 개선을 위한 공개 티켓도 있습니다.