전체 사이트 편집이 WordPress 5.8에 포함됩니까? 결정이 임박하다

어제 Josepha Haden Chomphosy는 전체 사이트 편집(FSE)이 WordPress 5.8에 포함될 것인지 여부를 결정하기 위한 로드맵을 발표했습니다. 4월 14일 Gutenberg 10.4가 출시된 후 소규모 핵심 리드 그룹이 go/no-go 데모에 참여할 것입니다.

다음 사람들이 통화 중입니다.

• Matias Ventura – 데모를 주최할 Gutenberg 프로젝트 리드.
• Matt Mullenweg – WordPress 프로젝트 리드.
• Helen Hou-Sandi – 수석 개발자.
• Josepha Haden Chomphosy – 전무 이사.

회의 안건은 간단하다. Ventura는 데모를 주최하고 그룹은 구현 문제를 논의하고 다룰 것입니다.

차단기가 없으면 FSE를 WordPress에 병합하는 계획을 공유합니다. 더 가능성 있는 결과는 해결해야 하는 항목이 최소한 몇 개 있다는 것입니다. 이 경우, 그들은 4월 27일의 두 번째 go/no-go 날짜 이전에 문제를 해결하기 위한 계획과 함께 이를 공개적으로 공유할 것입니다.

WordPress 5.8의 첫 번째 베타 릴리스는 6월 8일, 일반 공개 릴리스는 7월 20일로 설정되어 있습니다. 팀은 테마 및 플러그인 개발자가 준비할 시간을 주기 위해 릴리스 주기의 초기에 포함 여부를 결정해야 합니다.

많은 사람들이 최종 결정을 기다리고 있지만 현재로서는 약간의 인내심이 필요합니다. 프로젝트 리더는 모든 것을 신중하게 평가해야 합니다. 두 번째 기한인 4월 27일까지 결과를 알 수 없을 가능성이 큽니다.

대부분의 FSE 전환은 하위 사용자를 위한 베타 실행입니다. 코어에 이러한 기능을 포함한다고 해서 WordPress가 즉시 스위치를 전환하고 웹의 40%에 대해 모든 것을 활성화한다는 의미는 아닙니다. 전체 FSE 경험을 위해 사용자는 블록 기반 테마를 설치하고 활성화하기 위해 명시적인 선택을 해야 합니다.

이를 염두에 두고 온보딩 경험은 사용자를 사이트 편집에 초대하는 동시에 잠재적인 문제를 알리는 환영하는 경험이어야 합니다. 기본 제공 베타인 경우 개선 사항 이 곧 제공될 것임을 이해해야 합니다.

몇 년 전 블록 편집기가 출시된 프로젝트를 고려할 때 이와 같은 인코어 베타 실행도 환영합니다. 사람들이 블록 편집기를 좋아하든 싫어하든 관계없이 롤아웃이 모든 사람에게 순조롭지는 않았습니다. WordPress는 최종 사용자를 정밀 검사된 시스템으로 끌어들였으며 이는 많은 사람들에게 충격적인 변화였습니다. 이 프로젝트는 사용자에게 기능을 점진적으로 도입하고 다른 사람들이 자신이 선택한 새로운 경험에 몰입할 수 있도록 하여 이번에는 더 잘할 수 있는 기회가 있습니다.

"공유해야 할 가장 중요한 컨텍스트 는 사용자를 위한 완전한 기본 환경으로 제공되지 않는다는 것입니다 ."라고 Chomphosy는 게시물에서 팀이 과거의 실수를 넘어 성장하고 있다고 언급했습니다. "Phase One 병합 프로세스의 가장 분명한 피드백 중 하나는 확장자(에이전시, 테마 작성자, 플러그인 개발자, 사이트 빌더 등)가 다가오는 변경 사항을 준비할 시간이 충분하지 않다는 것입니다."

의사 결정자는 또한 일부 부품을 배송하기로 결정할 수 있지만 다른 부품은 배송하지 않을 수 있습니다. FSE는 여러 구성 요소로 구성된 프로젝트입니다.

"전체 사이트 편집 프로젝트는 도구와 프로젝트의 집합을 가리키는 일종의 포괄적인 용어이므로 일부는 배송되고 다른 일부는 배송되지 않을 수 있습니다."라고 Haden Chomphosy가 말했습니다. "당신이 언급한 것처럼 예외가 있을 수 있지만 대부분은 준비되는 대로 배송될 수 있습니다."

그녀가 언급한 예외는 함께 더 의미가 있는 구성 요소입니다. 예를 들어 theme.json 구성 파일을 통한 블록 기반 테마와 대부분의 사이트 편집 블록은 분리되어 있을 때만큼 유용하지 않습니다.

물론 Query 블록과 같은 것을 사이트 편집기 외부에서 사용할 수 있는 경우도 있습니다. 예를 들어 사용자는 사이트 편집기를 사용하지 않고 페이지 내에서 사용자 지정 쿼리를 만들 수 있습니다.

제 주요 관심사는 사이트 편집기와 관련된 기능이 아니라 블록 기반 위젯과 관련된 기능입니다. 전통적인 테마를 사용하는 사용자를 위한 과도기적 도구입니다. 새로운 탐색 메뉴 화면과 함께 블록 기반 테마 경험의 일부가 아닙니다. 목표는 사용자가 더 많은 곳에서 블록을 사용할 수 있도록 하는 것입니다. 그러나 이로 인해 많은 경우 UX가 중단됩니다.

위젯 경험은 여전히 ​​부분적으로 손상되어 각 블록을 별도의 위젯으로 취급합니다. 사용자는 사이트 프론트 엔드의 올바른 위젯 관련 클래스에 대해 제목(위젯 제목)과 다른 블록(위젯 콘텐츠)을 그룹(위젯 래퍼)에 넣는 방법을 배워야 합니다. 일부 테마의 경우 사용자가 이를 수행하는지 여부는 문제가 되지 않습니다. 다른 사람들에게는 보기에 보기에 좋지 않을 것이고 최악의 경우 레이아웃을 깨뜨릴 것입니다. 이 책임을 최종 사용자에게 떠넘기는 것은 수용 가능한 솔루션으로 간주되었습니다.

이 문제에 집중하고 싶었습니다. 이 문제는 모든 사용자에게 간단히 적용될 수 있는 문제 중 하나이기 때문입니다. 나는 여전히 작동하는 시스템에서 잠재적으로 고장난 시스템으로 전환하는 것이 울퉁불퉁한 라이드를 만들까봐 두렵습니다.

WordPress 5.6 릴리스 팀은 블록 기반 위젯을 제공하지 않기로 결정했습니다. 5.6의 핵심 기술 리더인 Hou-Sandi는 결정에 대한 역사적 설명과 포함할 준비가 되지 않은 이유를 제공했습니다.

프론트 엔드에 영향을 미치는 기능에 대한 내 질문은 "내 사이트를 엉망으로 만들지 않고 이 새로운 기능을 사용해 볼 수 있습니까?"입니다. — 즉, 사용자 신뢰입니다. 현재로서는 위젯 영역이 테마 없이 사이트에서 볼 수 있는 것과 같이 표시되지 않으며 실제 컨텍스트 보기를 얻으려면 수정 없이 변경 사항을 실시간으로 저장해야 한다는 점을 감안할 때 위젯 영역 블록은 그렇지 않습니다. 실험에 대한 불이익 없이 이 새로운 기능을 사용해 볼 수 있습니다.

위젯은 틀림없이 개선되었지만 나는 여전히 작년 10월과 같은 대답을 보고 있습니다. 테마 개발 커뮤니티에서 블록 편집기 자체를 지원하기에 충분한 동의를 얻지 못했고 새로운 블록 관련 기능은 훨씬 더 적었습니다. 그러나 어느 시점에서 프로젝트는 단순히 진행해야 합니다. 테르는 따라가기만 하면 됩니다.