클라이언트도 안전한 사이트 편집기: theme.json 플레이북

요약

클라이언트가 처음으로 WordPress 사이트 편집기를 열면 모든 블록, 색상 및 레이아웃을 편집할 수 있는 기능이 그들에게는 기능처럼 느껴질 수 있고, 당신에게는 위협처럼 느껴질 수 있습니다. 이 기사에서는 theme.json을 사용하여 콘텐츠 편집과 디자인 제어 사이에 명확한 경계를 그리는 방법을 설명합니다. 사이트 편집기와 싸우는 대신 사전 설정, 기본값 및 경계를 설정하여 비기술적인 클라이언트가 자신의 사이트를 안전하게 업데이트할 수 있도록 합니다. 무엇을 잠글지, 무엇을 열어 둘지, 그리고 왜 과도하게 잠그는 것이 실제 위험인지 살펴보겠습니다. 이 접근 방식은 디자인 토큰과 템플릿 수준 제약을 기반으로 하므로 유지 관리하는 모든 클라이언트 사이트에서 일관되게 작동합니다. 결국에는 디자인 시스템의 열쇠를 넘겨주지 않고 사이트 편집기를 넘겨줄 수 있는 반복 가능한 워크플로우를 갖게 될 것입니다.

클라이언트가 이메일로 "방금 제목을 업데이트하려고 했는데" 사이트 전체의 간격이 무너졌다고 말하면 가장 먼저 무엇을 하시나요?

WordPress 사이트를 두 개 이상 유지 관리한다면 어떤 형태로든 그 메시지를 받아본 적이 있을 것입니다. 사이트 편집기는 클라이언트에게 브레이크가 없는 5단 기어 변속 자동차의 열쇠를 준 것입니다. 그들은 단순한 텍스트 변경을 하고 있다고 생각하지만, 갑자기 전역 타이포그래피가 어긋나고, 홈페이지 히어로에 당신이 고르지 않은 네온 색상이 나타나며, 두 블록이 나란히 배치되는 대신 세로로 쌓입니다.

그 사이 당신은 지원하는 다른 여섯 개의 클라이언트 사이트를 생각하고 있습니다. 그리고 당신에게 가장 필요한 것은 모든 "도움이 되는" 클라이언트 편집이 백업에서 복원을 필요로 하는 유지 관리 함정입니다.

정답은 사이트 편집기를 빼앗는 것이 아닙니다. theme.json을 사용하여 그 내부에 경계를 설정하는 것입니다. WordPress 개발자 리소스에 따르면 theme.json은 블록 편집기 설정 및 스타일의 중심 진실의 원천입니다. 즉, 클라이언트에게 표시되는 색상 팔레트, 타이포그래피 및 레이아웃 옵션을 정의합니다. 이는 디자인을 제어하는 동일한 파일이 클라이언트가 편집할 수 있는 것과 없는 것도 제어할 수 있음을 의미합니다.

대부분의 튜토리얼이 theme.json이 개발자를 위해 무엇을 할 수 있는지에 초점을 맞추기 때문에 이것에 대해 어떻게 생각해야 하는지 살펴보겠습니다. 에이전시에게 질문은 다릅니다. 클라이언트가 갇혀 있다고 느끼지 않게 하면서 어떻게 안전하게 만들 수 있을까요?

왜 사이트 편집기가 그렇게 위험하게 느껴질까요?

클라이언트는 사이트를 망가뜨리려는 것이 아닙니다. 그들은 이전 편집기에서 수년간 훈련받은 일을 하려는 것입니다: 제목을 바꾸고, 이미지를 교체하고, 문단을 추가하는 것. 위험은 그들의 의도가 아니라 사이트 편집기가 콘텐츠 컨트롤과 같은 위치에 전역 컨트롤을 표시한다는 것입니다.

일반적인 시나리오가 있습니다. 클라이언트가 사이트 편집기에서 템플릿을 열고 제목 블록을 봅니다. 그들은 새 브랜드 스와치에 맞게 색상을 변경합니다. 그러나 그 제목이 템플릿에 있기 때문에 변경 사항은 해당 템플릿이 사용되는 모든 곳에 적용됩니다. 클라이언트에게는 한 번의 편집처럼 보였습니다. 사이트에게는 전역 변경이었습니다.

일반 원칙: 누군가에게 페이지 빌더를 넘겨주면 그들은 결국 "안전장치가 있는 설정"을 찾아 꺼버릴 것입니다. 그러나 theme.json을 사용하면 안전장치 자체를 숨길 수 있습니다. 클라이언트에게 "전역 스타일을 건드리지 마세요"라고 말하는 대신 나쁜 결과를 만들 수 있는 색상 팔레트를 표시하지 않으면 됩니다. 승인된 색상 팔레트, 글꼴 크기 척도 및 간격 사전 설정을 정의하고 클라이언트는 전체 CSS 스펙트럼이 아닌 그 중에서 선택합니다.

이것이 첫 번째 전환입니다: 규칙에 대해 생각하는 것을 멈추고 공장에 대해 생각하기 시작하세요. theme.json은 생산 라인입니다. 클라이언트가 보는 옵션을 구성하고 제약 조건은 인계 문서의 지침 세트가 아니라 인터페이스 자체에 의해 시행됩니다.

실제로 무엇을 잠가야 할까요?

모든 것을 잠글 필요는 없습니다. 콘텐츠 영역을 너무 강하게 잠그면 클라이언트는 문단을 추가해야 할 때마다 전화를 하거나, 일회성 플러그인을 추가하거나 이전 사이트에서 HTML을 복사하는 등 당신을 우회할 방법을 찾을 것입니다.

다음은 무엇을 잠그고, 무엇을 열어 두고, 왜 그런지에 대한 실용적인 표입니다.

편집 표면	잠글까요?	이유
템플릿 구조 및 블록 레이아웃	잠금	핵심 레이아웃 블록의 실수로 인한 제거 또는 재정렬 방지
전역 스타일(색상, 글꼴, 간격 사전 설정)	사전 설정으로 잠금	클라이언트는 임의의 값이 아닌 승인된 세트에서 선택
콘텐츠 텍스트 및 이미지	열어 둠	이것이 그들의 작업입니다. 허락 없이 할 수 있게 하세요
블록 간 간격	부분 잠금	정렬을 깨지 않고 리듬을 조정할 수 있도록 간격 사전 설정 제공
선별된 블록 패턴	검증한 경우 열어 둠	클라이언트가 처음부터 만들지 않고 새 섹션을 추가할 수 있는 안전한 방법

중요한 미묘한 차이는 "잠그기"가 아니라 "사전 설정으로 잠그기"입니다. 전역 스타일의 경우 설정 패널을 숨기는 것이 아니라 선택 항목을 선별된 세트로 줄이는 것입니다. 템플릿 구조의 경우 특정 블록을 제거할 수 없도록 잠글 수 있지만 클라이언트가 그 안의 텍스트를 편집하는 것은 여전히 허용할 수 있습니다.

한 가지 주의할 점: 템플릿에서 블록을 잠그는 것은 특정 페이지에서 잠그는 것과 다릅니다. 템플릿 잠금은 템플릿을 사용하는 모든 콘텐츠에 영향을 미칩니다. 페이지마다 다른 잠금 수준이 필요하다면 편집기 내부의 블록 수준에서 작업해야 하며 이는 더 취약합니다. 반복 가능한 에이전시 작업을 위해 잠긴 영역이 일관되도록 템플릿을 설계하세요.

편집기가 덫처럼 느껴지지 않게 하면서 경계를 설정하려면 어떻게 해야 할까요?

기법은 theme.json에서 디자인 토큰을 정의한 다음 CSS에서 다른 작업을 하지 않는 것입니다.

예를 들어 클라이언트가 버튼에 임의의 색상을 설정하도록 두는 대신 팔레트의 특정 색상을 사용하는 버튼 스타일을 theme.json에서 정의합니다. 클라이언트는 버튼을 선택하고 텍스트를 변경할 수 있지만 색상 선택기에는 승인된 스와치만 표시됩니다. 글꼴 크기, 줄 높이 및 간격도 마찬가지입니다.

동일한 원칙이 템플릿에도 적용됩니다. 템플릿 내 특정 블록에 "잠금" 기능을 사용할 수 있습니다. 예를 들어 추천사 블록의 열 구조를 잠그면 클라이언트가 인용문 텍스트는 변경할 수 있지만 3열을 2열로 바꿀 수는 없습니다. 아직 블록 잠금을 사용해 보지 않았다면 편집기 도구 모음에서 사용할 수 있습니다. 블록을 잠글 때 클라이언트가 콘텐츠를 편집할 수 있는지, 이동할 수 있는지 또는 둘 다 할 수 있는지 선택할 수 있습니다. 블록 수준 기본값을 위해 theme.json에서도 이 기능을 적용할 수 있습니다.

당신이 목표로 하는 것은 클라이언트가 디자인을 망가뜨릴 수 있는 컨트롤을 결코 보지 못하는 편집기입니다. 그들이 아무 것도 잘못할 수 없다는 뜻은 아닙니다. 그들이 할 수 있는 최악의 실수는 전체 사이트의 모양이 아니라 제목의 문구를 바꾸는 것이라는 뜻입니다.

사용자 정의 게시물 유형을 사용하는 경우 동일한 원칙이 기본 템플릿 너머에도 적용됩니다. theme.json을 사용자 정의 게시물 유형 및 플러그인 출력으로 확장에 대한 가이드를 참조하세요.

너무 많이 잠그면 어떻게 될까요?

여기 역설적인 점이 있습니다: 과도한 잠금은 부족한 잠금만큼 해롭습니다. 제목 크기를 조정하거나 섹션 사이에 간격을 추가할 수 없는 클라이언트는 결국 "그냥 제대로 보이게 해달라"고 요청할 것이며, 그러면 다시 무료로 작은 편집을 하게 됩니다. 더 나쁜 경우, 사이트 편집기가 쓸모없다고 판단하고 다시 제3자 페이지 빌더로 돌아가서 다시 너무 많은 제어권을 갖게 될 수 있습니다.

절충점은 분명합니다. 잠긴 편집기는 긴급 전화를 줄이지만 "이 버튼을 5픽셀만 위로 옮길 수 있나요?"와 같은 요청을 더 많이 만듭니다. 열린 편집기는 그 반대입니다. 당신의 임무는 하나의 구성을 모든 곳에 적용하는 것이 아니라 각 클라이언트에 맞는 균형점을 찾는 것입니다.

좋은 시작 휴리스틱은 다음과 같습니다: 어떤 것의 모든 인스턴스에 영향을 미치는 것은 모두 잠그고(전역 스타일, 템플릿 구조), 하나의 인스턴스에만 영향을 미치는 것은 모두 열어 두세요(단일 페이지의 텍스트 및 이미지). 클라이언트가 단일 페이지를 망가뜨리면 5분이면 고칠 수 있습니다. 전역 스타일을 망가뜨리면 20분이 걸리고 보안 문제가 됩니다.

이 작업을 여러 클라이언트에 걸쳐 반복 가능하게 만들려면 어떻게 해야 할까요?

이것이 에이전시 워크플로우가 필요한 부분입니다. 디자인 토큰(색상 팔레트, 타이포그래피 규모, 간격 사전 설정)을 정의하는 기본 theme.json이 있어야 하며, 특정 값을 확장하거나 변경하는 클라이언트별 재정의 파일이 있어야 합니다.

"스타터" 블록 테마를 만드는 것부터 시작하세요. theme.json으로 사용자 정의 블록 테마를 만드는 방법은 여기에서 확인하세요. 개발하고 문서화한 후에는 브랜드 색상과 글꼴을 바꾸는 것만으로 새 클라이언트에 복사할 수 있습니다. 바퀴를 다시 발명하는 것이 아니라 토큰을 교체하는 것입니다. 이것은 정확히 모든 WordPress 사이트를 다시 구축하지 말기 사고방식이지만 백엔드가 아니라 편집기에 적용된 것입니다.

theme.json은 단일 파일이므로 여러 환경에서 버전 제어 및 배포가 쉽습니다. 변경 사항을 검토하고 클라이언트가 전역 스타일에서 수정한 내용을 확인하며 기본 파일과 diff할 수 있습니다. 이를 통해 지원 요청에 대한 강력한 감사 추적이 가능합니다.

여러 사이트를 유지 관리하고 있고 아직 기본 테마를 설정하지 않았다면 지금이 기회입니다. 클라이언트가 편집기를 열 때마다 그 비용을 정당화하는 사용자 정의 WordPress 작업의 한 부분입니다.

계속 "색상 하나만 더" 요청하는 클라이언트는 어떻게 할까요?

팔레트는 약속입니다. 다섯 가지 브랜드 색상을 정의했는데 클라이언트가 여섯 번째를 요청한다면 답은 "아니오"가 아니라 "네, 하지만 제목의 일회성 헥스 코드가 아니라 팔레트에 의도적으로 추가하여 제공됩니다"입니다. theme.json에 색상을 추가하면 사이트 전체에서 일관되게 사용할 수 있습니다. 그것이 그러한 요청을 처리하는 올바른 방법입니다.

이것은 클라이언트와 소통해야 하는 부분이기도 합니다. 사이트 편집기에 브랜드 표준에 맞는 색상과 글꼴만 표시된다고 설명하세요. 그 표준을 확장하려면 디자인 시스템에서 처리하고 그 후에는 모든 새 색상을 아직 만들지 않은 향후 페이지를 포함하여 모든 곳에서 사용할 수 있다고 설명하세요. 그것은 "우리는 그렇게 하지 않습니다"보다 훨씬 나은 답변입니다.

동시에 40가지 색상의 팔레트를 축적하지 마세요. 분기별로 다시 검토하고 일회성 실수였던 항목을 제거하세요. 목표는 작고 의도적인 옵션 세트입니다.

레이아웃을 잠그고 콘텐츠를 열어 두며 팔레트를 클라이언트 관계의 살아있는 부분으로 만들면 사이트 편집기는 더 이상 위협이 아닙니다. 보호하기 위해 비용을 지불받는 디자인 표준을 희생하지 않고 클라이언트에게 진정한 자율성을 부여하는 방법이 됩니다.