차단 프로토콜에 참여하는 WordPress의 의미

Matt Mullenweg(WordPress 창시자)는 WordPress 편집기가 응용 프로그램 간에 "블록"을 이식할 수 있도록 하는 것을 목표로 하는 최근 릴리스된 사양인 Block Protocol을 준수하도록 하는 데 관심을 표명했습니다.

Matt의 관심에 대해 알게 되었을 때 저는 매우 기뻤습니다. 그러한 발전은 WordPress와 다른 행위자들에게도 여러 긍정적인 결과를 가져올 수 있기 때문입니다. 내 흥분은 공통 사양을 준수하는 서버, 클라이언트 및 도구의 출시로 풍부한 생태계가 생성된 GraphQL에서 발생한 일입니다. 그리고 프로토콜을 통해 새로운 기능을 지원할 수 있는 플러그인을 직접 개발했습니다.

이 기사에서는 이러한 결과와 기타 여러 가지 잠재적인 결과를 분석할 것입니다. 그러나 그렇게 하기 전에 이야기의 맥락을 살펴보겠습니다. 블록이란 무엇인지, 블록 프로토콜이 달성하려는 목표는 무엇이며, 이 모든 것이 WordPress에 연결되는 방식입니다.

블록이란 무엇입니까?

React 또는 Vue와 같은 JavaScript 기반 라이브러리로 작업할 때 함께 그룹화된 코드 조각(일반적으로 HTML, CSS 스타일 및 JavaScript로 구성됨)인 "구성 요소"로 작업합니다. 구성 요소는 정의된 레이아웃을 렌더링하거나 이미지 캐러셀, 이벤트 캘린더 또는 단순 헤더와 같은 특정 기능을 생성합니다. 콘텐츠를 렌더링하기 위해 구성 요소는 API 호출을 통해 서버에서 데이터를 가져오거나 이를 래핑하는 일부 상위 구성 요소에서 props를 통해 데이터를 제공할 수 있습니다. 데이터를 주입하면 구성 요소를 재사용할 수 있게 되어 다양한 컨텍스트 또는 애플리케이션에 대해 다양한 결과를 생성할 수 있습니다.

"블록"도 구성 요소이지만 최종 목적을 주장하고 원하는 레이아웃 또는 기능을 생성하기 위한 요구 사항을 정의하는 상위 수준입니다. 서로 감싸는 구성 요소의 계층 구조에서 가장 바깥쪽 구성 요소이므로 조감도가 있습니다.

Notion을 사용할 때 컴포넌트를 가지고 놀 수 있습니다. 여기서 모든 작업(텍스트 작성, 글머리 기호 목록 추가, 테이블 생성 등)은 하나 또는 다른 블록을 삽입하여 수행됩니다.

블록은 기술이 아니라 개념입니다. 모든 언어에서 구현할 수 있습니다. 클라이언트를 지원하는 JavaScript뿐만 아니라 레이아웃을 렌더링하는 서버 측 언어도 있습니다. 블록은 구성 요소를 생성하기 위한 기술의 모음인 웹 구성 요소와 혼동되어서는 안 됩니다. 그것들은 상호 배타적이지도 않습니다. 우리는 웹 컴포넌트를 사용하여 블록을 생성할 수 있습니다.

애자일 세계에서 비유하자면: MVP(Minimum Viable Product)가 상용 프로젝트를 시작하고 마케팅하기 위한 최소한의 작업인 경우 블록을 기본 단위로 MUC 또는 Minimum Usable Component로 생각할 수 있습니다. 애플리케이션에 일관성과 개성을 부여하는 작업.

블록 프로토콜이란 무엇입니까?

구성 요소는 상당히 재사용할 수 있습니다. 예를 들어, npm에서 "react component"를 검색하면 React 애플리케이션으로 즉시 가져올 수 있는 구성 요소를 제공하는 많은 라이브러리가 생성됩니다.

그러나 블록은 대부분 특정 응용 프로그램을 위해 설계되었기 때문에 이야기가 다릅니다. 블록은 블록과 상호작용할 수 있는 수단을 제공해야 하지만(예: 초기화 및 렌더링을 위한 API 제공 또는 입력으로 필요한 데이터를 설명하는 JSON 스키마 노출) 이러한 수단은 일반적으로 블록이 있는 애플리케이션에 따라 다릅니다. , 따라서 애플리케이션 간에 블록을 재사용할 수 없습니다.

이것이 바로 블록 프로토콜이 필요한 이유입니다. 블록 및 애플리케이션이 충족할 수 있는 사양을 제공하여 블록이 설계된 용도뿐만 아니라 모든 애플리케이션에 포함될 수 있도록 합니다. 구성 요소와 마찬가지로 블록은 응용 프로그램에서 재사용할 수 있습니다.

재사용 가능한 블록 및 WordPress

2018년 12월 버전 5.0부터 콘텐츠 생성을 위한 WordPress의 기본 환경은 블록을 통해 이루어졌습니다. 최근 출시된 버전 5.9 이후, 이 경험은 전체 사이트 편집(FSE)을 통한 웹사이트 레이아웃 생성으로 확장되었습니다. WordPress의 콘텐츠와 테마를 모두 만드는 현대적인 경험은 이제 블록을 통해 이루어집니다.

Joel Spolsky가 최근에 Block Protocol을 세상에 소개했을 때 그는 WordPress 기반 블로그에서 이를 수행했습니다. 그는 블록을 사용하여 게시물을 작성하는 방법을 설명하면서 블록을 웹에서 재사용할 수 있어야 한다고 제안했습니다. 이것은 WordPress 블록을 웹에서 재사용할 수 있어야 한다는 직접적인 제안이었고 Matt Mullenweg는 즉시 동의했습니다.

그런 일이 일어난다면 그러한 발전으로부터 어떤 결과를 예측할 수 있는지 다음으로 분석해 봅시다.

누가 블록 프로토콜을 사용합니까?

이것은 블록 프로토콜이 어떻게 생겼는지에 대한 Joel의 설명입니다.

“[서로 다른 애플리케이션에 의한 블록 구현]은 완전히 독점적이고 비표준입니다.

웹에서 블록을 교환하고 재사용할 수 있다면 멋지지 않을까요?

[...] 사용자는 WordPress, Medium 또는 Notion에서 본 더 멋진 블록을 사용하고 싶어할 수 있지만 내 편집기에는 없습니다. 블록은 쉽게 공유하거나 이동할 수 없으며 사용자는 다시 구현할 시간이 있는 기능으로 제한됩니다."

Joel의 동기에 100% 동의하지만 Notion이나 Medium이 공개적으로 공유되는 프로토콜을 사용하여 블록을 구현하기를 기대하는 것은 비현실적이라고 생각합니다. 왜 그럴까요? 물론 그들은 자신의 블록이 독점적이기를 원합니다. 미디엄이 내장할 애플리케이션에 자체 블록을 제공했다면 누구나 하룻밤 사이에 미디엄 클론을 제공하고 트래픽을 다른 곳으로 돌릴 수 있습니다. 노션도 마찬가지입니다. 고급 기능과 뛰어난 사용자 경험을 기반으로 사용자를 확보하는 것을 목표로 하는 상용 플랫폼이므로 기술을 포기할 수 없습니다(즉, 내부 사용을 위해 여전히 프로토콜을 준수할 수 있지만, 외부인은 혜택을 받지 않습니다.)

그렇다면 WordPress 외에 누가 블록 프로토콜을 준수하기를 원할 수 있습니까? 누가 혜택을 받을까요?

제 감상은 다음과 같습니다.

• 큰 예산이 없는 팀
  자체 블록을 처음부터 개발하는 대신(노력 집약적이고 따라서 전담 팀이 필요함), 다른 사람이 개발한 블록을 사용하여 웹사이트를 구축할 수 있습니다. 그런 다음 팀은 자체 애플리케이션에 맞게 블록을 사용자 정의하고 블록의 오픈 소스 코드에 다시 기여할 수 있습니다.
• 매력적인 사용자 경험을 제공하기 위해 따라잡아야 하는 애플리케이션
  Medium과 Notion은 사용자 경험이 매력적이기 때문에 인기가 있습니다. 우리 웹사이트에 유사한 사용자 경험을 제공할 수 있다면(매우 적은 비용 또는 무료로) 왜 그렇게 해서는 안 됩니까?
  이것은 반드시 소규모 웹사이트에 국한되지 않고 블록 경쟁에서 뒤처지는 인기 웹사이트의 경우일 수도 있습니다. 예를 들어, 얼마 전에 Mailchimp가 뉴스레터 작성을 위해 최신 블록 기반 편집기를 실험하고 있는 것을 보았습니다(이 새 편집기를 더 이상 찾을 수 없습니다... 제거했습니까?). 나는 그것을 시도했지만 버그가 있었기 때문에 고전적인 분할 창 편집기(블록도 지원하지만 다른 종류이며 제자리에서 편집할 수 없음)로 되돌아갔습니다. Mailchimp는 WordPress에서 제공하는 블록을 사용하여 이점을 얻을 수 있습니까?

• 콘텐츠 관리 시스템
  WordPress와 마찬가지로 다른 CMS도 즉시 사용 가능한 블록을 제공하여 애플리케이션을 구축할 수 있습니다. 실제로 Drupal Gutenberg는 WordPress 편집기를 Drupal로 가져오려고 시도했습니다. 블록 프로토콜 덕분에 이 작업을 더 쉽게 수행할 수 있습니다.
• 오픈 소스 프로젝트
  npm을 통해 사용할 수 있는 구성 요소와 유사하게 블록을 재사용할 수 있는 경우 커뮤니티에서 블록을 만들고 이를 오픈 소스로 무료로 제공하기 시작하는 것은 시간 문제일 뿐입니다(Github, Block Hub 또는 다른 곳을 통해). 여러분.

WordPress가 Block Protocol에 합류하면 다른 사람들은 어떤 이점을 얻을 수 있습니까?

우리는 혜택을 받을 수 있는 사람과 블록 프로토콜에 참여할 수 있는 사람을 조사했습니다. 그러나 추가로 우리는 스스로에게 물어볼 수 있습니다. WordPress 가 블록 프로토콜에 합류하면 어떤 이점이 있을까요?

내 인상은 이렇다.

• WordPress 블록에 대한 액세스
  가장 확실한 대답은 현재 WordPress에서 사용할 수 있는 모든 블록(편집기와 FSE를 통해)이 WordPress 기반 여부에 관계없이 자체 애플리케이션에서도 사용할 수 있다는 것입니다.
• 커뮤니티 주도 프로세스에 참여하여 블록 생성
  블록을 만드는 것은 시간과 노력이 많이 드는 프로세스입니다. 구텐베르크 프로젝트에서 Full Site Editor를 제작하는 데 5년이 걸렸고 아직 작업 중입니다. 그리고 WordPress의 새 릴리스와 관련된 사람들의 수는 수백 명에 이르며 최신 릴리스는 600명의 기여자를 초과했습니다.
  WordPress 커뮤니티는 무엇이 잘못되었는지 분석하고 향후 릴리스를 위해 개선하기 위한 회고 회의를 포함하여 이 프로세스가 최대한 원활하게 진행되도록 커뮤니케이션에 지속적으로 많은 리소스를 투자합니다.
  수백 명의 사람들을 관리하여 공통 리소스를 생산하는 이 잘 다듬어진 프로세스와 비교할 수 있는 조직이 몇 개나 될까요? 이러한 이유로 WordPress 커뮤니티가 주도하는 블록 생성 노력에 혼자가 아니라 모두에게 도움이 될 수 있습니다.
• 프로토콜에 대한 신뢰성과 견인력을 제공하는 빅 어답터
  블록 프로토콜은 간신히 공개되었으며 아직 초안입니다. 누가 그것을 사용할 것인가? 프로젝트는 잠재적인 이해관계자로부터 어떻게 동의를 이끌어낼 것인가? WordPress를 지원하는 것은 강력한 신호를 보내고 프로젝트에 기여자와 장기적인 지원이 있다는 것을 알고 다른 사람들이 참여할 수 있는 확신을 줍니다.

WordPress의 내용은 무엇입니까?

WordPress가 향후 15년 동안 관련성이 있으려면 현대적이고 매우 동적인 애플리케이션의 세계에서 생존해야 합니다. 이를 위해 버전 5.0부터 WordPress는 현대화 프로세스에 착수했습니다. 이 프로세스는 서버 측의 PHP 템플릿을 기반으로 레이아웃을 여전히 정적이지만 덜 정적으로 렌더링하는 다소 정적 애플리케이션에서 변형되는 것을 보았습니다. REST API에서 데이터를 가져오고 JavaScript 블록을 사용하여 콘텐츠 및 최신 버전 5.9부터 레이아웃을 렌더링하는 애플리케이션.

참고 : 레이아웃은 사용자의 일부 작업에 반응하는 클라이언트에서 생성되는 대신 wp-admin 에서 미리 생성되고 DB에 저장되기 때문에 여전히 매우 동적이지 않습니다.

이러한 변화는 2015년 Matt Mullenweg가 WordPress 커뮤니티에 "자바스크립트를 자세히 배우라"고 요청했을 때부터 구체화되는 데 시간이 좀 걸렸습니다. 블록 프로토콜에 합류하는 것은 워드프레스의 현대화 여정에서 또 다른 정거장이 될 것입니다.

어떤 이점을 얻을 수 있는지 봅시다.

시장 점유율의 성장 유지

현재 WordPress는 모든 웹사이트의 43%를 차지합니다. 그 성공은 부인할 수 없지만 WordPress가 시장 점유율의 85%에 도달하기를 바라는 마음을 표명한 Matt Mullenweg에게는 여전히 충분하지 않습니다. (이 입장이 옳고 그름을 판단하는 것은 이 글의 범위를 벗어납니다.)

이제 WordPress 사이트가 정확히 무엇인지 스스로에게 물어볼 수 있습니다. 과거에는 모놀리식 PHP 기반 아키텍처로 응답이 매우 명확했습니다. 그러나 오늘날 우리는 여러 기술로 구성된 스택을 기반으로 웹사이트를 구축합니다. React 프론트엔드를 구동하는 WordPress 백엔드가 있을 수 있으며 WP REST API를 통해 데이터를 공급할 수 있습니다. 워드프레스 사이트인가요?

대답은 다음과 같습니다. 잘 모르겠습니다. 하지만 그것도 중요하지 않을 수 있습니다. WordPress가 스택의 기술 중 하나라면 계속 성장할 것입니다. 지금까지 WordPress는 클라이언트에 제공할 데이터를 관리하는 CMS의 역할만 맡을 수 있었습니다. 그러나 이제 블록 프로토콜 덕분에 WordPress는 모든 애플리케이션의 프론트엔드에 전원을 공급하는 블록을 제공하는 새로운 역할을 맡을 수 있습니다.

이 시나리오에서 WordPress는 사이트 생성에 더 큰 역할을 합니다. 이는 WordPress가 여전히 시장 점유율을 확보하고 웹 개발 툴킷에 더욱 확고히 자리잡게 하여 관련성이 없는 상태가 되기 어렵게 만듭니다.

더 큰 기여자 풀

WordPress에서 제공하는 블록을 사용하면 일반적으로 WordPress를 사용하지 않는 개발자가 WordPress에 익숙해지고 감사하게 생각하고 오픈 소스 코드의 기여자가 됩니다. 이는 기여자 풀이 더 커지고(예를 들어 JavaScript에는 PHP보다 약 3배 많은 전문 개발자가 있음) 더 다양한 기술 세트가 제공될 것이기 때문에 중요합니다.

블록의 추가 가용성

말할 필요도 없이 블록 허브는 두 가지 방식으로 작동합니다. WordPress는 다른 모든 사람이 자신의 블록을 사용할 수 있도록 하고 다른 사람을 위해 코딩된 블록도 WordPress 사이트에 전원을 공급하는 데 사용할 수 있습니다.

예를 들어 Mailchimp가 WordPress 블록을 사용하여 뉴스레터 편집기에 전원을 공급하기로 결정한 다음 이를 개선하거나 자체 블록을 생성 및 출시하면 뉴스레터를 만들고 보내는 WordPress 플러그인에서 사용할 수 있습니다.

구텐베르크에서 WordPress 편집기 분리

구텐베르그는 워드프레스 블록 편집기의 토대를 제공하는 프로젝트입니다. 블록과 상호 작용할 수 있는 엔진을 제공합니다. 예를 들어, 편집기에서 HTML을 렌더링하고 DB에 저장하기 위해 블록의 edit 및 save 메소드에서 출력을 가져옵니다.

그러나 블록 편집기를 Gutenberg와 결합할 필요는 없습니다. 결국 "블록"은 개념이고 Gutenberg는 특정 구현입니다. 블록 프로토콜은 개념과 구현 사이의 연결 고리 역할을 하여 그 사이에 완벽하게 배치될 수 있습니다.

그 결과, 이제 구텐베르크가 없어질 수 있고 다른 구현 엔진이 그 자리를 대신할 수 있어 여전히 동일한 블록으로 구동되는 다른 경험을 제공할 수 있습니다.

흥미로운 결과는 구텐베르크가 WordPress 사이트의 모든 곳이 아니라 wp-admin 에만 있기 때문에 WordPress 자체가 이 아키텍처의 이점을 누릴 수 있다는 것입니다. 즉, WordPress를 사용하여 구축하는 공개 사이트 자체는 Gutenberg에 의존하지 않습니다. 대신 백엔드에서 Gutenberg로 만든 HTML을 단순히 인쇄합니다. 그렇기 때문에 이전에 WordPress 사이트가 여전히 동적이지 않다고 언급한 것입니다.

블록 프로토콜을 사용하여 블록과 통신하면 블록을 사용하기 위해 클라이언트 측에서 Gutenberg가 필요하지 않습니다. 대신 사용자 상호 작용을 기반으로 블록을 직접 렌더링하여 사이트를 보다 동적으로 만드는 React 애플리케이션을 가질 수 있습니다.

Gutenberg를 사용할 수 없는 페이지에서(적어도 사용할 수 있을 때까지는) 동일한 아이디어가 wp-admin 에서 작동할 수 있습니다. 예를 들어 플러그인용 블록으로 완전히 구동되는 설정 페이지를 제공하려는 경우 블록 프로토콜을 사용하여 React를 사용하여 필요한 구성 블록(캘린더, 대화형 지도, 슬라이더, 옵션이 있는 드롭다운 또는 적절한 입력) 및 약간의 PHP 논리를 추가하여 데이터를 wp_options 테이블에 저장합니다.

공개 사이트에 블록 포함

이전 섹션에서 조금 더 나아가 사용자가 상호 작용할 수 있도록 실제 블록을 공개 사이트에 포함할 수 있습니다.

다음을 포함하여 이러한 기능에 대한 끝없는 사용 사례가 있습니다.

• Calendly에서 수행한 대로 사용자가 회의 슬롯을 예약할 수 있는 캘린더를 표시합니다.
• 사용자가 Brush Ninja처럼 무언가를 그리거나 Block-a-saurus와 같이 게임을 할 수 있습니다.
• FSE와 함께 곧 있을 개선된 미디어 환경에서 가능한 것처럼 사용자가 이미지를 조작하도록 합니다.

또 다른 예는 내 자체 WordPress 플러그인에서 가져온 것이며, 이를 지원할 수 있다는 것이 내가 블록 프로토콜에 대해 흥분하는 이유입니다. WordPress용 GraphQL API는 GraphQL 지속 쿼리를 작성할 수 있는 GraphiQL 클라이언트 블록과 함께 제공됩니다.

동시에 방문자가 이를 사용하여 GraphQL 서버가 작동하는 방식을 발견할 수 있도록 문서 사이트에 GraphiQL 클라이언트를 포함합니다.

블록 프로토콜을 사용하면 문서 사이트에 GraphiQL 클라이언트를 노출하는 아이디어가 내 플러그인 사용자에게도 부여될 수 있습니다. 그런 다음 방문자를 위해 자체 GraphQL API에서 데이터를 검색하는 방법을 문서화하기 위해 자신의 공개 사이트에 GraphiQL 블록을 포함하기만 하면 됩니다.

구텐베르크의 "협업" 단계 지원

공개 사이트에 블록을 포함할 수 있다는 것은 Google 문서 또는 Dropbox Paper와 유사한 공동 작성 경험을 생성하기 위해 협업을 간소화하는 것을 목표로 하는 블록 편집기의 3단계에서도 유용할 수 있습니다.

Dropbox Paper에 대한 링크를 받으면 해당 내용을 시각화하기 위해 로그인할 필요가 없습니다.

마찬가지로, 블록을 렌더링하고 상호 작용할 수 있는 클라이언트 측을 가질 수 있으므로 로그인하지 않은 사용자도 피드백을 제공할 수 있습니다. 이러한 방문자는 사이트의 wp-admin 에 액세스할 필요가 없으므로 협업 기회를 극대화할 것입니다.

"모든 것을 위한 단일 API" 개념 추가 개선

블록 개념은 WordPress 사이트에 콘텐츠를 추가하는 모든 다양한 방법을 통합하는 방법으로 도입되었습니다. 과거에는 "클래식" 편집기를 사용할 때 위젯이나 단축 코드를 통해 동적 코드를 추가하고 사용자 지정 프로그램을 통해 사이트 모양을 조작할 수 있었습니다. 블록은 사이트의 모든 콘텐츠를 생성하고 사용자 지정하는 "단일 API"를 제공하여 이러한 모든 메커니즘을 대체합니다.

이 단순화는 UI에서 발생했습니다. 그러나 동적 블록은 JavaScript와 PHP에서 동일한 출력을 렌더링해야 하기 때문에 블록 자체가 항상 하나의 처리 방법을 제공하는 것은 아닙니다. 공개 사이트). 이러한 상황은 개발자에게 불안의 원인이 되며 새로운 기여자에게 장벽을 추가합니다.

이 문제를 해결하기 위한 몇 가지 제안이 있었지만(이 토론에서 훌륭하게 요약됨) 그 중 어느 것도 충분히 설득력이 없습니다. WooCommerce 플러그인도 비슷한 문제를 처리했지만 그 솔루션은 (내 생각에) 약간 복잡해 보입니다. DRY 코드를 생성하는 메커니즘은 해킹 없이 CMS에서 이상적으로 제공해야 합니다.

블록 프로토콜은 더 나은 대안을 제공할 수 있습니다. 개발자가 PHP에서 동일한 로직을 다시 코딩하고 싶지 않다면 블록 렌더링은 동일한 블록을 사용하여 프론트엔드에서 대신 수행할 수 있습니다. 이것은 항상 권장되는 것은 아니지만(검색 엔진에 의한 콘텐츠 인덱싱에 영향을 미칠 수 있기 때문에) 서버 측 렌더링(SSR) 대신 클라이언트 측 렌더링(CSR)을 기반으로 하지만 둘 중 하나를 결정하는 옵션은 개발자에게 휴식을 취하십시오.

부수적인 이점으로 이 솔루션은 더 많은 React 개발자가 WordPress를 사용하도록 유도할 수 있습니다.

WordPress 영역 외부에서 개발 사용

앞서 언급했듯이 공유 프로토콜을 고수하면 GraphQL에서와 같이 풍부한 생태계를 생성하는 조정되지 않은 개발로 이어질 수 있습니다.

예를 들어 SpectaQL은 GraphQL API용 문서 생성기입니다. GraphQL 사양을 준수하기만 하면 이 프로젝트를 통해 API를 자동으로 문서화할 수 있으므로 개발자의 노력이 거의 필요하지 않습니다.

블록 프로토콜을 준수하면 유사한 효과를 얻을 수 있습니다. 일부 프로젝트는 자동으로 block-metadata.json 에서 정보를 추출하고 모든 블록을 문서화하는 정적 사이트를 생성할 수 있습니다. 이와 동일한 아이디어가 현재 Gutenberg에 대해 구현되고 있습니다. 일부 프로젝트가 이미 블록 프로토콜에 대해 이 작업을 처리했다면 구텐베르그는 이를 편승하여 기여자들이 다른 작업을 처리할 수 있도록 할 수 있습니다.

GraphQL 지원 개선

특히 나를 흥분시키는 또 다른 이유는 워드프레스용 GraphQL 서버(WPGraphQL 및 WordPress용 자체 GraphQL API)가 현재 구텐베르크에 대한 최적의 지원을 제공할 수 없다는 것입니다. block.json 은 객체 또는 배열 속성의 실제 유형을 선언하지 않기 때문입니다. 예를 들어 구텐베르크의 블록은 속성을 array 유형으로 선언할 수 있지만 GraphQL은 그것이 String 유형의 array 임을 알아야 합니다.

블록 프로토콜은 속성의 궁극적인 유형을 정의할 것을 강력히 권장합니다.

사용 가능한 경우 블록은 블록으로 전송된 엔티티에 대한 엔티티 유형 정의가 포함된 entityTypes 필드를 예상하고 처리해야 합니다(SHOULD).

따라서 WordPress 블록이 블록 프로토콜을 준수하는 경우 해당 JSON 스키마가 이 정보를 제공하도록 업그레이드되고 GraphQL 플러그인은 해킹에 의존하지 않고 블록 데이터를 검색할 수 있습니다.

마무리

이 기사에서 저는 WordPress가 블록 프로토콜에 합류했을 때의 잠재적인 결과에 대해 논의했으며 긍정적인 결과를 낳을 것이라고 제안했습니다. 그러나 그것이 일어날 가능성이 얼마나 되는지에 대해서는 언급하지 않았습니다.

기술적으로 가능한가요? 이전 버전과의 호환성을 깨뜨리지 않고 수행할 수 있습니까? 잠재적인 이점이 필요한 노력을 능가합니까? 블록 프로토콜이 애초에 존재하는 것이 말이 됩니까? 아니면 다른 응용 프로그램의 다른 요구 사항을 블록 수준에서 조정할 수 없습니까?

이러한 모든 질문(및 기타 많은 질문)은 블록 프로토콜 가입 여부에 대한 결정이 내려지기 전에 응답이 필요합니다. Matt Mullenweg가 관심을 표명한 것처럼 이제 커뮤니티가 무게를 측정하고 WordPress가 현대화 여정에서 이 새로운 항구에서 멈춰서 연료를 보급해야 하는지 아니면 건너뛰고 계속 항해해야 하는지 결정할 때입니다.