DE{CODE}: Gutenberg とヘッドレス WordPress

WordPress ブロックとも呼ばれる Gutenberg は、従来の WordPress サイトでコンテンツをレイアウトする強力な新しい方法をコンテンツ プロデューサーに提供します。 しかし、ヘッドレスの WordPress 開発者がマーケティング チームに同じ機能を与えるにはどうすればよいでしょうか? この DE{CODE} セッションでは、GraphQL for WordPress (WPGraphQL) の創設者である Jason Bahl が、ヘッドレス サイトで WordPress ブロック エディターを使用するための新しい機能とベスト プラクティスを共有します。

セッションスライド

全文トランスクリプト

JASON BAHL : こんにちは。 Gutenberg とヘッドレス WordPress に関する私の講演へようこそ。 私の名前はジェイソン・バールです。 私は WPGraphQL の作成者でありメンテナーです。 私は WP Engine のプリンシパル ソフトウェア エンジニアです。 Twitter @jasonbahl または Twitter @wpgraphql で私を見つけることができます。

今日は、Gutenberg とは何か、ヘッドレス WordPress とは何か、ヘッドレス WordPress を使用するタイミングと理由、ヘッドレス WordPress でグーテンベルクを使用する方法、ヘッドレス WordPress とグーテンベルクの使用方法とその理由についてお話したいと思います。一緒にすることは、あなたのプロジェクトにとって意味があるかもしれません。

そのため、WordPress には歴史的にこのようなエディタがありました。 コンテンツを編集できる TinyMCE テキスト領域があります。 メディアを挿入してコンテンツを公開できます。2018 年には、この空白のキャンバスにコンテンツを挿入し、ブロック レベルでコンテンツを操作できるブロックベースのエディターである Gutenberg が登場しました。

したがって、各段落には設定があります。 各画像には設定があります。 各ギャラリー、見出しなど、コンテンツについて考えられるものはすべて、ブロックと呼ばれるものです。 また、コンテンツを非常にきめ細かく制御できるようになり、ドラッグ アンド ドロップしてコンテンツを構成できるようになりました。 つまり、WordPress での非常にリッチな編集エクスペリエンスであり、Gutenberg とは何かについての入門書です。

ヘッドレスWordPressとは？ ヘッドレスを理解するために、従来の WordPress を見てみましょう。 従来の WordPress では、管理 UI である WordPress にログインし、コンテンツを公開してから、ユーザーがサイトにアクセスし、WordPress に組み込まれている言語である PHP がページをレンダリングします。 したがって、CSS、HTML、および JavaScript をロードして、ページをユーザーに配信します。 つまり、これは伝統的な WordPress のようなものです。

ヘッドレス WordPress では、引き続き WordPress を CMS として使用します。 WordPress でコンテンツを公開し、コンテンツをキュレートし、コンテンツを管理しますが、HTML でページをブラウザに配信する代わりに、WordPress は通常 JSON 形式でデータを配信し、クライアント アプリケーションはそのデータを消費できるため、ネイティブの iOS または Android アプリケーションを使用できます。または仮想現実アプリケーションでさえ。

私の同僚である Anthony が、WordPress を使用して仮想現実アプリケーションを強化する方法についてのコンテンツを共有しています。 または、印刷版の新聞のエントリ ポイントとして WordPress を使用している新聞社で働いていました。 つまり、印刷された新聞のハード コピーを読んでいる場合は、WordPress で作成されたコンテンツを読んでいることになります。

もちろん、そのデータを使用して Web にレンダリングすることもできますが、PHP テンプレートに縛られる代わりに、必要なフロントエンド テクノロジを柔軟に選択できます。 したがって、ヘッドレスは、バックエンド、コンテンツの管理、および WordPress で管理されるデータの表示方法を分離します。

したがって、このデータを使用する一般的な方法は 2 つあります。 WordPress の組み込み API である WP REST API から JSON 形式でデータを取得できます。また、WPGraphQL という別の API もあります。 これは、インストールして WordPress と JSON からデータを取得できるオープンソースのプラグインです。 そして、今日は WPGraphQL について話します。

WordPress とは何かがわかったところで、なぜヘッドレス WordPress プロジェクトを構築するのでしょうか? 前述したように、フロントエンド技術の選択には多くの柔軟性があります。 一部の人々にとっては、フロントエンド プロジェクトの構築方法を選択できることは非常に重要なことです。 Next や Gatsby や Svelte など、改善されたコア Web バイタルを実際にターゲットとするフレームワークがいくつかあります。 したがって、WordPress でヘッドレスに移行し、コア Web バイタルを改善できる可能性があります。

コード内のコード分割などのメリットがあります。 したがって、フロントエンド アプリケーションのコンポーネントを構築できます。 また、特定のページ用に構築されているコンポーネントに基づいて、クライアントに送信されるアセットが少なくなり、ページが高速化されます。 また、ヘッドレスにより、開発者はフロントエンドのユーザー エクスペリエンスをより細かく制御できるため、WordPress 管理画面にインストールされたプラグインがフロントエンドに与える影響は少なくなります。

そのため、管理者ユーザーはプラグインをインストールするだけで、任意のスクリプトや任意のマークアップをヘッドレス サイトのフロントエンドに追加することはできません。 開発者がフロントエンドの制約を定義し、WordPress が送信されたデータを取得するというより、私が重要視したいことの 1 つは開発者の経験です。

ヘッドレス WordPress では、必要な技術スタックを柔軟に使用できるため、場合によっては開発者エクスペリエンスが向上するという利点があります。 これから取り上げるケースの 1 つは、コンポーネント ベースの開発と呼ばれるもので、これについてはすぐに詳しく説明します。

これがいくつかの理由です。 では、ヘッドレス WordPress を使用したい場合、どのような状況になる可能性がありますか? ネイティブ モバイルのような非 Web アプリケーションを構築する必要がある場合は、おそらくヘッドレスを使用することをお勧めします。 繰り返しになりますが、WordPress サイトまたは現在の WordPress サイトでコア Web バイタルが貧弱である場合、または問題はないが、それらを維持するのに非常にコストがかかる場合は、ヘッドレスを検討することをお勧めします.

組織内に WordPress からデータを取得する必要があるアプリケーションが複数ある場合は、ヘッドレス化も必要になる場合があります。 また、組織のコンポーネント ライブラリまたはコンポーネント ベースのデザイン システムに既に投資しており、WordPress からのデータが必要な場合は、ヘッドレス化に投資することをお勧めします。 チームが JavaScript を好み、PHP で何かを構築することを好まない場合、それもヘッドレスを検討する理由になります。

ただし、ヘッドレスに移行したくない理由はいくつかありますが、現在のところ、開発に少し余分な時間がかかります。 そのため、予算が少ないか時間の短縮があり、従来の WordPress に既にソリューションがある場合は、まだヘッドレスに移行していない可能性があります。 サイト管理者がフロントエンドを変更するプラグインのインストールを本当に制御する必要がある場合、まだヘッドレスに移行していない可能性があります。

チームが本当に PHP を好み、JavaScript や別のフロントエンドを学びたくない場合は、従来の WordPress を使い続けることもできます。 また、コンポーネント ベースの開発やコンポーネント ベースのライブラリに投資していない場合、またはそれに興味がない場合は、従来の WordPress 開発ワークフローを使い続ける可能性があります。

また、従来の WordPress のコア Web バイタルが非常に優れており、Web サイトを非常に高速に維持するためのメンテナンス コストが非常に低い場合は、従来の WordPress を使い続けても問題ないかもしれません。 したがって、ヘッドレスにする必要はありません。 しかし、ヘッドレス化が一部のチームにとって良いと私が考える理由を説明します。

したがって、WordPress 開発者の経験をもう一度見てみると、大量の HTML を生成する 1 つのフィールドにコンテンツを公開しています。 これらの細かいブロックを持つ Gutenberg エディターを使用している場合でも、最終的には HTML の 1 つの大きな塊になります。 したがって、グーテンベルグでパブリッシュする場合でも従来のクラシック エディターでパブリッシュする場合でも、この HTML のチャンクは PHP を介してテーマに送信され、HTML、CSS、および JavaScript をロードする 1 つのグローバル ページが作成されます。 そして、これらのアセットはページにグローバルに適用されます。

そのため、WordPress 開発者は通常、ファイルの種類に基づいて開発を分離します。そのため、ページにグローバルに適用される別のファイルに CSS を配置するか、HTML を PHP で記述し、WordPress から必要なデータを取得してから JavaScript を使用します。 jQuery を使用して別のファイルに記述されることがよくあります。 この 3 つの要素が組み合わさってページが作成されます。

問題は、これらが分離されておらず、ページ全体に適用されていることです。 そのため、変更を加えることができる場合もあります。 これが私に起こったように。 あるとき、マネージャーの要求に従ってサイトのフッターのスタイルを変更したところ、その 3 日後に、そのパス コードのレビューが原因で、サイトの別の場所でスタイルが変更されたことが報告されました。 合格しました。

突然、サイトの何かが壊れました。これは、CSS がグローバルに適用されており、気付いていないことに影響を与える可能性があるためです。 しかし、過去に新しいトレンドがありました.7、8年はコンポーネントベースのアーキテクチャと呼ばれていたかもしれません. これにより、コンポーネントと呼ばれるものでアプリケーションの特定の部分を構築できます。

また、JavaScript、HTML、CSS を個別にテストできる小さなビットに結合して、アプリケーションの一部を構築することができます。 いくつかの問題、マークアップ、JavaScript、スタイル、およびこれらのコンポーネントを組み合わせて、より複雑なアプリケーションを構築できます。

そのため、コンポーネントベースの開発により、複雑な機能をより小さな分離された部分に分割し、それらを分離してテストし、それらが機能していることを確認してから、結合する必要がある懸念事項を結合することができます. UI のすべてのスライスには、特定の責任があります。 画像カードの場合は、特定の URL を使用して特定のサイズで画像をレンダリングする必要があります。

したがって、マークアップの依存関係があります。 スタイルの依存関係があります。 ステートフルな相互作用がある場合があります。 これらはすべて、その特定のコンポーネントに関係しています。 したがって、マークアップ、JavaScript、および CSS を 1 か所で結合し、テストして、うまく機能することを確認できます。 このため、これらのコンポーネントをアプリケーション全体で再利用したり、プロジェクト間でコンポーネントを再利用したりすることさえできます。

そのため、コンポーネント ライブラリと呼ばれる傾向があります。 マテリアル UI やエンド デザイン コンポーネントなどのプロジェクトがあり、Chakra UI も人気があります。 そして、これらのコンポーネントをプロジェクト全体で使用できます。 また、アクセス可能なマークアップなどの中心的な問題も解決できます。 そして、それらを更新して、組織内の複数のプロジェクトに一度に適用することができます。これらの理由により、より多くの自信を持って、頻繁に反復して出荷することができます.

では、ヘッドレス WordPress をどのように使用できるでしょうか。 前に述べたように、WordPress からコンポーネントにデータを取得するには、2 つの方法があります。 1 つは REST API です。 1 つは WPGraphQL です。 私の友人であるドレイクは、しばらくの間ヘッドレス サイトを構築していたので、彼に尋ねたところ、これが彼の答えでした…

彼は WPGraphQL を好みます。 それが、今日お話しすることです。 では、WPGraphQL とは何ですか? あなたは尋ねるかもしれません。 これは、あらゆる WordPress サイトに拡張可能な GraphQL スキーマと API を提供する無料のオープンソース WordPress プラグインです。 ではGraphQLとは？ まあ、それはグラフクエリ言語です。

よし、ジェイソン。 私はまだあなたの言っていることが理解できません。 いいから見せてやろう。 つまり、GraphQL の仕組みは、クライアント アプリケーションがサーバーから必要なものを指定してリクエストを送信することです。 リクエストは次のようになります。 値のない JSON キーのように見えます。 したがって、この場合、リクエストはビューアーを要求しており、ビューアーでは「名前」フィールドが返されるようにします。

そして、GraphQL サーバーからの応答は次のようになります。 実際の JSON データ、キー、および値であり、リクエストの形状と一致します。 したがって、この場合、名前を取得するか、Jason Bahl という名前のビューアーを取得します。 そのため、GraphQL では、クライアント アプリケーションがアプリケーション データ グラフからツリーを抜き出します。

そして、それが視覚的にどのように見えるかは、このようなものです。 グラフに入ることができます。たとえば、ビューアーまたはユーザー フィールドまたはノードを追加します。 そのノードには、Jason という名前のようなプロパティがある場合があります。 そして、そのノードは、画像 URL のようなプロパティを持つアバターのようなグラフ内の他のノードへの接続を持っている可能性があります。

また、そのユーザーは、そのユーザーが作成した投稿などの他のノードへの接続を持っている場合があります。 そして、それらの投稿自体に、タイトル、こんにちは世界、さようなら火星などのプロパティが含まれる場合があります。 また、これらの投稿には、ニュースやスポーツなどの独自のタイトルを持つカテゴリなど、グラフ内の他のノードへの接続がある場合があります。 そして、これらのカテゴリは、他のノードや他の投稿との接続を持っている可能性があります。 そして、それらの投稿には注目の画像などが含まれている可能性があります。 つまり、GraphQL を使用して断片を求めることができる、この大きなデータ グラフがあります。

そのため、GraphQL 管理者または WordPress 管理者でツールを使用できます。 クエリを作成できる GraphiQL というツールがあります。 ここでは、サブセレクション、名前、アバター、URL を含む Viewer フィールドを選択しています。これを実行すると、要求したフィールドが取得されるので、クエリは視覚的に次のようになります。

グラフに入り、1 人のユーザーを求めました。 アバターの URL で接続されたアバターであ​​るユーザーの名前を尋ねました。 このデータのグラフはすべて利用できますが、特定のデータ セットのみを要求すると、その特定のセットが返されます。 そして、コンポーネントを使用できるようになりました。

そこで、コンポーネント ベースの開発の利点について説明しました。これを実際に見てもらいたいと思います。 これが、私がプレゼンテーション コンポーネントと呼ぶものです。 したがって、これは責任のあるカードコンポーネントです。 このカードを画像とタイトルでレンダリングする役割が 1 つあります。

コードを見ると、スタイル コントロールがあることがわかります。 幅を設定し、必要な画像を渡し、タイトルを渡すことができます。 したがって、プロジェクト全体でこのコンポーネントを再利用できます。 このコンポーネントには、必要な依存関係がすべて含まれています。 レンダリングする HTML があります。 スタイルがあります。 ここにはいくつかのスタイル コントロールがあります。 ホバー状態などのステートフルなコンポーネントがいくつかあります。

したがって、これは再利用できる分離されたコンポーネントであり、GraphQL を使用すると、WordPress 管理画面で GraphQL を使用して作成したばかりのクエリを取得し、それを取り込み、ビューアー カード コンポーネントを作成できます。 したがって、クエリを記述し、それをカード コンポーネントと結合して、コンポーネントを完成させることができます。

HTML、CSS、JavaScript があります。 そして、データのおかげで、要求したデータでレンダリングするものができました。 アプリケーション全体でこれを使用できるようになりました。GraphQL にはフラグメントと呼ばれる機能があり、GraphQL クエリを再利用可能な断片に分割することができます。

この場合、ユーザー プロファイル カード フラグメントを作成し、名前、アバター、および URL を指定してから、そのフラグメントをより大きなクエリで使用しています。 実行すると、期待どおりの結果が得られます。 そのフラグメントを取得して、コンポーネントに入れることができます。 これで、ユーザー プロファイル カードと呼ばれる別のコンポーネントができました。

このユーザー プロファイル カードは、ユーザーにクエリを実行するたびに、名前、アバター、およびコンポーネントで使用するアバターの URL を取得する必要があることを指定します。 これで、この再利用可能なコンポーネントができました。この再利用可能なコンポーネントは、アプリケーションのどこにいてもユーザーを要求し、アバターとユーザーの名前を含むこの再利用可能なカードをレンダリングするために必要なデータを取得できます。

そのため、これを取り込んで、アプリケーションのより大きな部分で使用できるようになりました。 これは、再利用可能なユーザー プロファイル カード コンポーネントからインポートしているフラグメントを使用してビューアー クエリを実行する前のクエリです。 そして、それをビューア カード コンポーネントに出力し、これをアプリケーション全体で再利用できるようになりました。

このユーザー カードまたは作成者カードに依存するアプリケーションのより大きな部分を作成できます。 そのため、タイトルを担当するブログ タイトル コンポーネントのような複数のコンポーネントを使用できるようになりました。 ユーザーのプロファイルをレンダリングする、作成したばかりのユーザー プロファイル カードを使用できます。 アプリケーションのこの部分のマークアップとデータを担当するコンテンツまたは抜粋コンポーネントを使用できます。

はい、このアプリケーションの構築に必要なマークアップ、CSS、およびデータを担当するこれらの小さなコンポーネントを構築できます。 そして、それらを一緒に構成することができます。 それらを個別にテストすることも、より大きなユニットとしてテストすることもできます。 したがって、これをさまざまなテンプレートでも使用できます。

これらの再利用可能なコンポーネントは、異なる著者がいるブログ投稿またはブログの役割に使用できますが、同じコンポーネントを使用してそれらをレンダリングできます。 他のアーカイブページに使用できます。 WordPress のテンプレート パーツと非常によく似ているため、ヘッドレス アプリケーションを小さな断片に分割することができますが、テクノロジを結合する利点があります。

これは、ヘッドレス WordPress 開発者がコンポーネントベースの設計とその利点を経験していることについて少しです。 では、具体的に Gutenberg に関して言えば、ヘッドレス WordPress と Gutenberg を具体的に検討する理由は何ですか? チームがすでにヘッドレス WordPress を使用しており、場合によっては高度なカスタム フィールドとフレックスフィールドを使用しており、エディタ エクスペリエンスを更新して Gutenberg を使用したい場合、それは明らかに Gutenberg でヘッドレスに移行する理由の 1 つです。

管理で使用されるコンポーネントとフロントエンドで使用されるコンポーネントを構築することから利益を得たい場合は、ブロック エディターの Gutenberg バックエンド エディターはすべてコンポーネント ベースであるため、Gutenberg でヘッドレス化を検討するのは十分な理由です。 構造化入力を利用したい場合があります。 admin の各ブロックには、構造化されたフィールドがあります。

フィールド レベルで制御できる特定の属性があります。 また、その構造化された出力をコンポーネントにも送信することでメリットが得られる場合があります。 前述したように、プロジェクト間でコンポーネントとブロックを再利用したい場合があります。 同様に、プロジェクト全体で使用したいアクセシビリティや特定のマークアップの問題などを解決するために、機関が構築したブロック ライブラリが必要になる場合があります。 そして、個々のプロジェクト内だけでなく、プロジェクト全体でそれらを更新できます。

したがって、これは、WordPress の子テーマと同様に、すべてのサイトに移動してマークアップなどを更新する必要があるため、スケーリングが難しい場合がある部分です。 ここでは、ブロック ライブラリを NPM の依存関係として使用し、組織全体でそれらを更新できます。

そのため、現在、Gutenberg を使用した WordPress 開発の状態は、バックエンドにコンポーネント ベースのブロックがあるということです。 独自のカスタム ブロックを作成するか、WordPress のコア ブロックを使用できます。 しかし、PHP での出力は、先ほど述べたように、HTML の 1 つの大きな塊であり、この HTML の 1 つのブロックを取得することから、フロントエンドのコンポーネントにも転送されるバックエンドのコンポーネントに移行するにはどうすればよいでしょうか?

そこで、WordPress からコンポーネントに Gutenberg データを取得するためのいくつかのオプションを見ていきます。 したがって、1 つのオプションは、コンテンツを HTML として取得することです。 したがって、WordPress コンテンツを HTML としてクエリし、その HTML を解析してコンポーネントにすることができます。 または、GraphQL 型としてブロックをクエリできます。 これにより、ブロックのリストをクエリできます。各ブロックは、コンポーネントにマップできる GraphQL タイプになります。

したがって、コンテンツは HTML です。 これは、現在 WPGraphQL コアで実行できることです。 ブロックを個別の GraphQL タイプとしてクエリする場合、現時点では 2 つのオプションがあります。 コミュニティ拡張機能である Gutenberg 拡張機能用の GraphQL と、私が個人的に取り組んでいるベータ プラグインである WPGraphQL ブロック エディターがあります。

それでは、これらのオプションを見てみましょう。 WPGraphQL コアでは、コンテンツを HTML としてクエリし、コンポーネントに解析できます。 投稿のようなものをクエリすると、ID やタイトル、コンテンツなどのフィールドを要求できます。 コンテンツは 1 つの大きな文字列と HTML の 1 つの大きなチャンクを返し、その HTML を解析して、さまざまな DOM ノードをさまざまなコンポーネントにマップできます。

この wpgraphql.com の場合と同様に、左側のリンクは、これが実際に発生しているコードへのリンクです。 WPGraphQL から返されたマークアップを取得して解析し、特定の HTML ノードを探して React コンポーネントに変換します。 そのため、このコード ブロックのようなインタラクティブなものを使用できます。これにより、構文が強調表示され、ユーザーが [コピー] をクリックできるようになり、解析して目次を作成することもできます。 それが1つのアプローチです。 そして、今日の本番環境で wpgraphql.com で使用しています。

この方法を使用する場合に考慮すべき点として、HTML ペイロードは予測できない可能性があります。 新しいブロック ライブラリのインストールや、編集者がコンテンツに挿入できるさまざまな HTML など、サーバーの変更は予測できません。 そのため、解析が非常に難しい場合があります。 変更を相互観察することはできません。 クライアント開発者としては、何が変わったのか分からないので、考慮すべき点があります。

このアプローチは、WordPress 管理者とフロントエンドを非常に厳密に管理しているチームに最適です。 したがって、WordPress のバックエンドとフロントエンドに取り組んでいる 1 人または小さなチームの場合は、入力と出力をより適切に制御できるため、問題なく機能する可能性があります。

他のオプションの 1 つである Gutenberg の WPGraphQL は、コミュニティが管理するプラグインです。 これにより、各ブロックを独自の GraphQL タイプとしてコンテンツ ブロックをクエリできます。 これが機能する方法は設定ページです。ブロックだけをスキーマとして入力する必要があるため、非表示の iframe で Gutenberg を開き、JavaScript クライアントからブロック レジストリを取得してサーバーに送信します。

次に、GraphQL を使用してブロックを特定のタイプとしてクエリし、前に示したようにフラグメントを使用し、これらのフラグメントを使用してフロントエンドのコンポーネントにマップできます。 したがって、これは 1 つのオプションです。 このプラグインに関する考慮事項として、ブロック レジストリへの変更はイントロスペクト可能であるため、これは良いことです。

フロントエンド アプリケーションで作業しているチームは、GraphQL イントロスペクションを使用して、時間の経過とともにスキーマがどのように変化するかを確認し、破壊的な変更や使用できる新しいフィールドがあるかどうかを知ることができます。 このアプローチは、複数の人または複数のチームのプロジェクトで少しうまく機能すると思います. WordPress 管理者を担当するチームと、フロントエンドを担当する別のチームがある場合、このアプローチがうまくいく可能性があります。 両側で使用されているブロック間のコントラクトとして GraphQL スキーマを使用できます。

少し興味深いのは、前述のように iframe にブロックをロードすることです。 このため、すべての状況に対応できるとは限りません。 したがって、ブロックを特定のページ、特定のテンプレート、または特定の投稿タイプに登録する場合、ブロック レジストリ マップをスキーマに取得するこの方法では、いくつかのブロックを見逃す可能性があります。 そのため、すべてのプロジェクトに対応できるわけではありません。

次のプロジェクトである WPGraphQL Block Editor は、私が現在取り組んでいるベータ プラグインです。 また、これにより、コンテンツ ブロックを独自の GraphQL タイプとしてクエリすることもできます。Gutenberg の WPGraphQL と非常によく似ており、指定したデータを返すフラグメントを作成できます。 そして、それらのフラグメントをフロントエンドのコンポーネントで使用できます。

これにはいくつかの考慮事項があります。これはベータ版プラグインなので、それがあります。 構造化された入力と構造化された出力の恩恵を受けます。 したがって、フロントエンド開発者として、それは確かに勝利です. block.json ファイルに登録されているブロックで動作します。 したがって、コア WordPress Gutenberg ブロックにはこのファイルが含まれているため、これはそのアプローチで機能します。 多くのサードパーティはこの方法でブロックを登録していないため、これらのブロックを手動でマッピングする必要があります。

ブロックは個々のノードとして扱われません。 ブロックを個別のノードとして扱いたいのですが、グローバル ID がないため、ポスター ページのような大きなオブジェクトの一部としてこれらのブロックにアクセスする必要があります。

ヘッドレス WordPress、ヘッドレス WordPress の利点、ヘッドレス WordPress を Gutenberg で使用することについて何かを学んでいただければ幸いです。 今日は WPGraphQL をお試しください。 wpengine.com/atlas で無料の Atlas Sandbox アカウントにサインアップできます。 そして、私のプレゼンテーションに参加していただきありがとうございます。 繰り返しになりますが、Twitter、jasonbahl、または Twitter @wpgraphql で私を見つけることができます。 ありがとう。