ACF + WPGraphQL を使用して最初のヘッドレス WordPress プロジェクトを構築する方法

WordPress の開発に関しては、誰もがお気に入りのツールを持っており、それらのツールを使用せずにヘッドレス サイトを構築するという考えは気が遠くなる可能性があります。 幸いなことに、WordPress 開発者のお気に入りの 2 つのツールである ACF と WPGraphQL を使用すると、ヘッドレス開発に足を踏み入れることができます。

このセッションでは、WP エンジンのシニア デベロッパー アドボケイトである Jeff Everhart が、Atlas を使用してわずか数分でデモ サイトを構築することにより、インフラストラクチャのすべてを紹介します。

セッションのスライド:

転写:

JEFF EVERHART: 皆さん、お元気ですか? 私の名前は Jeff Everhart です。ここ WP Engine のシニア デベロッパー アドボケイトです。 今日は、ACF と WP GraphQL を使用して最初のヘッドレス WordPress プロジェクトを構築するという私の講演に参加していただき、ありがとうございます。 構築に入る前に、ヘッドレス WordPress とは何かについて説明したいと思います。 ヘッドレスはニッチな用語ではなくなり、より主流になりつつあるように思われるので、説明を簡潔にしようと思います。

ヘッドレス WordPress の核心は、API を介して WordPress CMS を使用して、他のタイプのアプリケーションを強化することです。 このスライドの図を見ると、ユーザーが site.com/page をリクエストすると、WordPress がそのリクエストを処理する代わりに、JavaScript アプリケーションがそのルートに応答します。 パスを見て、WordPress やその他のソースから必要なデータを判断し、それらの API 呼び出しを行い、ユーザーへの応答を生成します。

その Node.js ランタイム スロットにあるものは、実際にはさまざまな種類のアプリケーションまたはクライアントである可能性があることに注意することが重要です。 最も一般的なフレームワークのすべてで構築されたモバイル アプリや Web サイトのさまざまな例が、このパターンを使用して大きな成功を収めているのを見てきました。 ヘッドレス WordPress とは何かについてよく理解できたので、今日のプロジェクトで使用する技術スタックについて見ていきましょう。

一番後ろのレイヤーでは、WP GraphQL を API として使用します。 WP GraphQL は、WordPress バックエンドを強力な GraphQL API に変えます。 ネイティブの WordPress とコア REST API が行うのと同じ役割と機能のセキュリティ チェックをすべて実施します。 WP GraphQL は、宣言型クエリ言語を使用して、そのコンテンツ クラフト全体でさまざまなコンテンツ タイプをクエリできるため、ヘッドレス アプリケーションの開発に最適です。 したがって、投稿、ページ、カテゴリをすべて同じリクエストで取得します。

それでは、WordPress CMS を使用して、より複雑なデータを構造化およびモデル化する方法を見てみましょう。 ヘッドレス プロジェクトに取り組む多くの開発者は、異なるデータをモデル化して保存する必要がありますよね? WordPress の典型的な投稿やページを超えて拡張します。 ACF または高度なカスタム フィールドは、これらのカスタム フィールドをモデル化するための優れたツールです。 今後のリリースでは、このプラグインの無料版の UI で投稿タイプとタクソノミーを直接登録できるようにすることで、さらに強力になります。

REST API 経由ですべてのデータを簡単に利用できるようにしますが、そのフィールド データの一部を GraphQL スキーマに追加するには、WP GraphQL 拡張機能をインストールする必要があります。 個人的には、このプラグインが進化し、ヘッドレス開発者にとってより強力になるのを見るのが本当に楽しみです。

複雑なデータをモデル化し、WP GraphQL を介してクエリを実行できるようになったので、WordPress をすでに知っていて気に入っているコンテンツ編集者をサポートしながら、ユーザー向けに最新の Web エクスペリエンスを作成する方法が必要です。 そこで登場するのが Faust です。Faust は、WordPress プラグインと Next.js ベースの JavaScript フレームワークで構成される 2 つのフレームワークです。 これらは連携して、ヘッドレス WordPress サイトを簡単かつ直感的に構築できるようにします。

ポスト プレビューやすぐに使用できる認証などのサポートが追加され、最新の JavaScript で再考された WP テンプレート階層エクスペリエンスを活用できます。 Faust.js は非常に拡張可能なプラットフォームを目指しており、特定のユース ケースをサポートするエクスペリエンスをカスタマイズおよび作成するために使用できるプラグイン システムと管理バーが付属しています。

最後になりましたが、これらのツールをローカルおよび本番環境で使用する方法がいくつか必要になります。 ローカルと WP の移行を使用して、このプロジェクトに必要なすべての WordPress リソースを 1 つの zip ファイルにまとめました。ローカルにドラッグ アンド ドロップして開始できます。 サイトの構築が完了したら、作業を Atlas プラットフォームにプッシュできます。 Atlas WP Engine のオールインワン ヘッドレス ホスティング ソリューションは、WordPress バックエンドと Node.js コンテナーを組み合わせて、すべてが連携するように調整されており、1 つのシームレスなダッシュボードから利用できます。

今日のプレゼンテーションで使用するすべてのツールについて十分に理解できたので、早速作成に取り掛かりましょう。 このスライドの URL を開いて、ブラウザーでデモ コードにアクセスします。 この体験をできる限り簡単に理解できるように努めましたが、次の 25 分間で多くのことを説明しますので、今すぐ見て、この GitHub リポジトリとこのセッションを後で記録して、会議後も作業を続けることができます。 デコードの残りが自動車ショーである場合、このセッションはエンジンの構築に関するものです。 しゃれは完全に意図したものです。

GitHub リポジトリが開いたので、始めましょう。 最初にお勧めするのは、自分のアカウントでこのリポジトリのフォークを作成することです。 このレポジトリに何が含まれているかを調べると、一連のサンプル コードと、このプレゼンテーションで行うすべての手順についての readme の手順がいくつか表示されます。 実際、このリポジトリからプロジェクトに直接コピー アンド ペーストする作業を何度も行います。 これをローカルにクローンするには、端末内で Git clone コマンドを実行してみましょう。

ダウンロードには 1 秒しかかかりません。プロジェクトをダウンロードしたら、ディレクトリをそのプロジェクト ディレクトリに変更します。 そこからコマンドを実行してこのプロジェクトを VS Code で開きますが、必要なコード エディターを自由に使用してください。 VS Code には既にターミナルが統合されているので、これをクリーンアップしてから iTerm を閉じます。 これで、WordPress ローカル サイトの配置に移行できます。 そのために、このプロジェクトを Finder で開き、用意したヘッドレス WP デモ zip ファイルを見つけます。

その zip ファイルをローカルの開発環境に直接ドラッグ アンド ドロップすると、ローカルがデモ WordPress サイトの解凍とブートストラップのプロセスを開始します。 デフォルトのままで十分です。その後、ローカルで新しい WordPress サイトを作成するのに数分しかかかりません。 さて、これは WP migrate pro の優れた機能で、任意のサイトを zip としてエクスポートし、それをローカルに直接ドラッグ アンド ドロップできるため、プラットフォームに関係なく、本番サイトをローカル マシンにすばやく移動できます。

インストールが完了したら、この SSL 証明書を信頼してから、WP Admin でこのプロジェクトを開きます。 local は既に実行されているので、そこから先に進み、最小限に抑えます。他に何もする必要はありません。 そこからリポジトリを開きます。このリポジトリには、このデモ サイト用に既に作成した管理者のユーザー名とパスワードがあります。 これらの資格情報を使用して、WP Admin ダッシュボードにログインできるはずです。 そこから、このローカルに WordPress をインストールするのに少し時間がかかります。

最初に、この WordPress サイトにインストールされているプラ​​グインを確認します。 データ モデリング用の高度なカスタム フィールドなどがあります。 ヘッドレス機能の一部を有効にすること、サイトの API として機能する WP GraphQL、ACF フィールド グループの一部を表示する ACF 拡張用の WP GraphQL を有効にすることには問題があります。 では、投稿も見ていきましょう。 このプロジェクト内に事前に入力したさまざまなデモ投稿をすべて見ると、さまざまなカテゴリのさまざまな投稿が多数あることがわかります。

各投稿内のコンテンツを見ると、多数の本文コンテンツ、いくつかの画像、アイキャッチ画像、いくつかの ACF フィールド グループが既に作成され、事前入力されていることがわかります。 それでは、フィールド グループをさらに詳しく見てみましょう。 ACF メニューを開くと、Food Resources と sweet mixtape という 2 つのフィールド グループが作成されていることがわかります。 まず、食料資源を見てみましょう。

これは、テキストと URL という 2 つの個別のフィールドを持つ非常に基本的なフィールド グループです。 これらのそれぞれについて、Show in GraphQL オプションをオンにして、GraphQL に表示されるようにします。 次に、フィールド グループ レベルでそのオプションもチェックしました。 さらに、これらの投稿をいつレンダリングするかを決定するための条件付きロジックがいくつかあります。つまり、投稿カテゴリが食品に等しい場合です。 そして、甘いミックステープがどのように見えるかを見てみましょう.

これは私たちの食糧資源と非常によく似ており、いくつかの異なる分野があることがわかります。 それぞれに Show in GraphQL オプションがチェックされており、さらにフィールド グループ レベルでチェックされています。 WP GraphQL 拡張機能によって提供される、必要のない設定がいくつかあることがわかります。 さらに、これも投稿カテゴリに基づいて条件付きで表示していることがわかります。

それでは、WP GraphQL と、それがツールに関して提供するものを見てみましょう。 GraphQL メニューを開くと、グラフィカル IDE 内にドロップされます。 現在、これは WP GraphQL を使用してクエリを作成できるインタラクティブな開発環境です。 たとえば、カテゴリ付きの最初の 10 件の投稿が必要であると指定し、追加の ACF フィールドもここに含めることができます。 [実行] ボタンをクリックすると、そのクエリのデータと一致する WordPress サイトからライブ データが返されます。

必要に応じて、Query Composer ウィンドウを開いて、クエリの側面を視覚的に構成できます。 そのため、特定のフィールドやデータが特定の WordPress オブジェクトにあるかわからない場合、これは非常に便利なツールです。 Query Composer を使用して、これらのクエリをリアルタイムで調査および実行できます。 それでは、Faust 設定メニューを開いて、Faust の設定に移りましょう。 イントロ トークで述べたように、Faust は実際には、WordPress プラグインとフロントエンド コード ベースで構成される 2 つの部分からなるフレームワークです。

したがって、WordPress プラグインの設定メニューに戻ると、フロントエンド サイトの URL にこのオプションが設定されていることがわかります。これは、フロントエンド サイトのアドレスを指します。 そのすぐ下のシークレット キー オプションで、[再生成] をクリックして、デモ プロジェクトに使用できる一意のキーを生成します。 そこから、実際に JavaScript コード ベースに戻りましょう。このコマンドを実行して、サンプルの環境変数ファイルをサイトで使用できるファイルにコピーします。

これを実行したら、コマンドで .env.local ファイルを開き、いくつかの変更を加えます。 まず、次のパブリック WordPress URL オプションをローカル サイトの場所に置き換えます。 つまり、ACF.WPEngine.local です。 そして、その秘密鍵の値も取得し、それをファウストの秘密鍵に使用します。 それもコメント解除したいことを確認してください。最後の環境変数は、ローカル開発環境への接続中に発生する可能性のある SSL の問題を解決できるように、テストとローカル開発に本当に役立ちます。

そこから、NPM Install を実行してプロジェクトのすべての依存関係をインストールします。それが完了したら、これを開始して NPM Run Dev を実行してプロジェクトを開始します。 コンパイルには 1 秒しかかかりませんが、コンパイルが完了すると、ブラウザーで localhost:3000 を開くことができ、Faust サイトが動作しているのが表示されます。

それがレンダリングされると、ファウストがすでにいくつかの魔法を処理していることがわかります。 右上のメニューを見ると、WordPress バックエンドで定義したメニューからページとコンテンツが既に取り込まれていることがわかります。WordPress 管理画面に戻ると、この接続がどのように機能するかをもう少し詳しく説明します。

Faust プラグインはフロントエンド URL のアドレスを認識しているため、プレビュー リンクなどの多くのリンクを書き換えて、ブラウザで開くとフロントエンド サイト URL で開くようにします。コンテンツがフロントエンドでどのように表示されるかを実際のライブ プレビューで確認できます。

それでは、Faust JavaScript プロジェクトの構造を詳しく見ていきましょう。 Next.js での作業に慣れている場合は、ページのディレクトリを使用して、ルートを実装するページ コンポーネントを作成したことがあるでしょう。 Faust でもこれを行うことができますが、WordPress ノードと呼ばれるキャッチオール ルートを提供することで、この概念に基づいて構築されています。これにより、WordPress が管理する任意の URI を取得し、それを特定のコンテンツに解決できます。

次に、そのコンテンツ アイテムに関する追加データを取得し、それをコンポーネントに渡します。これにより、個々のコンテンツの 1 つの部分を WP テンプレート フォルダー内の特定のテンプレートに解決できます。 これは、テンプレート階層の概念と従来の WordPress テーマ、および多くの命名規則に非常に似ています。 たとえば、frontpage.js は Web サイトのフロント ページであり、page.js はページ コンテンツ タイプのレンダリングを担当します。 また、single.js は単一の投稿をレンダリングするためにあります。

それでは、frontpage.js をもう少し動的にしましょう。 OK 。 まず始めに、front page.js ファイルを開き、もう少し余裕を持って作業できるようにします。 したがって、このファイルの内容を見ると、3 つの主要部分があることがわかります。 レンダリングするコンポーネント自体、コンポーネントにアタッチされるクエリ プロパティがあり、これはコンポーネントをレンダリングするたびに実行され、最後にいくつかの変数を渡すことができます。

ご覧のとおり、これには主に 2 つの使用方法があります。 コンポーネント内で use query フックを使用するか、props としてコンポーネント自体に渡すことができます。これについては、後の例で説明します。 リポジトリに戻り、ステップ 2.1 から始めて、frontpage.js のクエリを更新します。 それをコピーしてから、グラフィカル IDE に戻り、そこで少し遊んでみます。 したがって、クリップボードにあるこのクエリは、最初の 10 件の投稿を取得し、それらの投稿のそれぞれに関連付けられたいくつかのデータを取得する必要があります。

そこをクリックして実行すると、すべてがうまく機能することがわかります。 そのため、先に進み、それをコンポーネントのクエリ プロパティに追加します。 それで、それを行うのに適した場所を見つけて、そこに貼り付けて、少し再フォーマットします。 つまり、クエリのこの個々の部分をそのクエリ自体に追加するということです。 そのため、そのクエリの結果をコンポーネントの残りの部分で利用できるようにする必要があるため、先に進んで、その投稿結果を抽出するだけのこの追加行を追加して、使用できる変数に入れます。

さて、このホームページを動的にするための次のステップは、これらの投稿の抜粋をレンダリングするコンポーネントを実際に作成することです。 それを実行して、components フォルダーにいくつかのファイルを作成します。ここで言及します。先に進んで、post excerpt フォルダー内に postexcerpt.js を作成します。 m 実際には、この Faust.js Getting Started プロジェクトの一部である既存のコンポーネントの構造を複製しているだけです。 ここでは何をするのも本当に自由です。フレームワークは、この入門の一部として既にレイアウトされているので、フレームワークに従っているだけです。

これらの 3 つのファイルがすべて揃ったら、これらの投稿をレンダリングするためにファイルに何かを追加し始めます。 したがって、最初に行うことは、いくつかのコンテンツを投稿の抜粋コンポーネントに入れることです。 これをリポジトリからコピーして貼り付けるだけで、module.css ファイルをインポートしていることがわかります。 そして、post excerpt と呼ばれる関数があります。これは、投稿である 1 つの小道具を味わうコンポーネントです。次に、セクションをレンダリングし、その投稿 URI に直接移動するリンクを持ち、タイトルをレンダリングします。 次に、同様にレンダリングするカテゴリ タイルを取得し、HTML で危険な設定を使用して、投稿の抜粋の HTML コンテンツを設定します。

すべてがうまく保存されたら、それを保存しますが、ここに来て、この追加の範囲指定されたスタイルをコンポーネントに追加して、カテゴリのスパンタグをスタイルします。 index.js ファイル内でインポートとエクスポートを実行して、デフォルトのエクスポートから名前付きのエクスポートに変更すると、それらすべてが保存されます。 そして、これを他の用途に使用できるようにする最後のステップは、コンポーネント フォルダーの index.js ファイルにもう 1 行のエクスポート行を追加することです。 これで、ホームページ frontpage.js に戻ると、既存の import ステートメントに追加のインポートを追加して、投稿の抜粋を使用できるはずです。

さて、それを実装する場所を見つけたいと思います。下に降りてメイン要素の内部を見ると、ヒーローのすぐ下にいくつかのものがあることがわかります。リポジトリのコードの一部をコピーして貼り付け、投稿の抜粋を使用してメインの内容を上書きします。 そして、いくつかのものを滑らかにするために少しだけ再フォーマットを行いますが、私たちが行っていることはそのコンテナの内部にあることがわかります.クエリの結果を返し、投稿を渡してキーを与える投稿の抜粋コンポーネントを返します。

そして、すべてを保存してブラウザーでレンダリングし、更新すると、すばらしい動的なホームページが作成されていることがわかります。 ええ、個々のカテゴリ タイルと同様に、これらの各タイトルにはクリック可能なリンクがあります。 クリックすると、Faust に既に存在するテンプレートの利点により、ACF を使用して作成したリソース グループの一部が欠落しているものの、すべての投稿が既にレンダリングされていることがわかります。 したがって、クリックして 2 番目の投稿に進むと、事前に作成されたすべてのカテゴリ リンクと同様に、優れたレンダリングが行われていることがわかります。これらのカテゴリ URI を使用して、そのカテゴリ JS テンプレートをレンダリングする際にファウストに頼っているだけです。 .

動的なホームページができたので、single.js テンプレートでレンダリングする ACF フィールドの取得に移りましょう。 それでは、コード エディターをクリーンアップしてから、single.js ファイルを開いて、その中身を見てみましょう。 その最上位には、実際に props を受け取る、エクスポートしているこのコンポーネント関数と、シード クエリから取得した変数の一部を読み取る動的 GraphQL クエリを持つ component.query プロパティがあることがわかっています。

最終的にやりたいことは、さまざまな投稿リソースの一部を投稿コンテンツの下部に表示することです。 リポジトリに戻り、ステップ 3.1 までスクロールします。ここで単一の投稿クエリを更新します。これを見ていきます。前のステップ。 そのクエリをコピーしてグラフィカルに貼り付ける場合は、投稿用のデータベース ID をハードコーディングし、As Preview やその他のフラグメントなど、必要のないさまざまなものをいくつか削除します。 .

先に進んで実行すると、実際に期待したものを含むデータが返されることがわかります。 コンテンツ、作成者を返します。重要なことに、これらのフィールド グループとそのデータの両方を返します。 それでは、そのクエリをコピーして、single.js に戻ります。 そこから、クエリのその部分をクリップボードから取得したものに置き換えるだけです。 保存しておきましょう。 必要に応じて再フォーマットできますが、これは空白にとらわれないため、ほとんどの場合、問題なく表示されると思います。

そこから、最後のステップで行ったのと同じことを行いたいと思います。そこでは、それをクエリの一部にしました。 ここで、これらの変数をコンポーネント内で使用できるようにします。 これらをその構造化ステートメントに追加します。さらに、投稿にはいくつかの異なるカテゴリがあるため、食品リソースまたは甘いミックステープを表示する必要があるかどうかを判断するのに役立つブール値を作成したいと考えています. ご覧のとおり、両方を取得しても、甘いミックステープ フィールドが見つからない場合は、null として返されます。 ここで条件チェックを行いたいので、この 2 行のコードをファイルに追加します。

そして、これが基本的に行うことは、テンプレートを条件付きでレンダリングするために以下で使用できるブール変数を作成することです。 このことでは、各カテゴリのノードを見て、基本的にそれらをフィルタリングして、それらに食べ物や音楽が含まれているかどうかを判断し、長さをチェックしています。 このタイプのブール変数を実装する方法はおそらくたくさんあるので、よりクリーンな方法があれば自由に変更してください。

次のステップでは、前のステップと同様に、追加のコンポーネントを作成します。 そこで、コンポーネント ファイル内に食料資源コンポーネントを作成します。 そこでフォルダーを作成し、その中に food resources.js ファイルを作成し、それに加えて index.js ファイルと CSS モジュール ファイルを作成します。 そして、SCSS モジュール ファイルは、スタイルをその特定のコンポーネントにスコープできるため、非常に役立ちます。 そのため、これを行うのはファンキーな構文のように感じますが、多くのクラスなどを記述する必要がないため、最終的には非常にクリーンな結果になります。

そこで、リポジトリからコンポーネント コードをコピーして、これらのファイルに直接貼り付けます。 2 つの小道具のレシピ名とレシピ リンクを取得する食品リソース関数があることがわかります。ブリトーの絵文字を使用して、ナイス エイジの下にそれらをレンダリングしています。 また、いくつかの SCC ファイル スタイルをこの特定のフォルダーにコピー アンド ペーストし、コンポーネント フォルダー index.js から確実にエクスポートします。 前の例と同じように、これをコンポーネント フォルダーの index.js にエクスポートして、コンポーネントから直接見たように、インポートする本当に良いグループを作成できるようにします。これらの異なるファイルのいくつかの別の場所にあるフォルダー。

これを追加したら、音楽リソース コンポーネントに注目して、同じことを行います。 先に進み、同じファイル構造を作成します。 音楽リソース フォルダーとその中に musicresources.js ファイルがあります。 次に、 index.js ファイルを作成してエクスポートし、それらのスコープ スタイル用の musicresources.module.scss ファイルも作成します。

そのため、すべてのものを入手したら、食料資源に対して行ったのと同じことを行い、リポジトリからこのコードの一部をコピーして貼り付けます. このコンポーネントがほぼ同じに見えることがわかります。 音楽リソースがあります。 これには実際には 2 つではなく 3 つの props がありますが、このフィールド グループには 3 つのフィールドがありましたが、styles.component の規則は同じです。 コンテンツが異なるため、わずかに異なるレンダリングを行っているだけです。

そこから、SCSS コードも追加し、それをコンポーネント フォルダー index.js からエクスポートして、ここのフォルダーにインポートします。実際に作成したと思います。すぐに名前を変更してindex.js とコンポーネントが音楽リソースを検出し、そのすべてが適切に機能するように、すべてのネーミングが適切に見えることを確認してください。 それでは、これらのコンポーネントを実際に single.js ファイルに実装する準備ができたので、これらの不要なタブをすべて閉じます。

そのためには、これら 2 つのコンポーネントを既存の import ステートメントに追加するだけで、これらのコンポーネントは自動的に認識されます。 このコンテンツ ラッパー コンポーネントがここにあります。 現在、コンテンツを渡していますが、実際にはオプションで子も受け入れます。 したがって、コンテンツを渡すことができますが、いくつかの子コンポーネントをそのコンテンツ ラッパーに直接渡すこともできます。これにより、既にある適切な水平スペースに表示され、すべてが整列します。

それが私たちがやることであり、そこにそのコードをコピーして貼り付け、再フォーマットし、この特定の例で何が起こっているかを話します. そのコンテンツ ラッパー コンポーネントのすぐ内側で、is food および is music ブール変数を使用して、対応するリソース コンポーネントを条件付きでレンダリングします。 したがって、食品が true で、この投稿が食品のカテゴリにある場合は、それをレンダリングします。 それが音楽の場合も、同じことをします。 そして、それをレンダリングするために必要なさまざまな小道具をすべて渡していることがわかります。

また、戻って single.js テンプレート ページの 1 つを更新すると、食品リソースが期待どおりにレンダリングされていることがわかり、WP Admin または自宅に戻ったときにそのリンクが適切に機能することがわかります。ページ。 そして、食品カテゴリまたは音楽を見つけたら、Kinfolk Synth DIY を開いて、音楽リソース コンポーネントがどのように見えるかを確認できます。 そして、実際に両方のカテゴリにあるものを見つけた場合、実際には、下部にある両方のコンポーネントが期待どおりにレンダリングされていることがわかります。

OK。 希望どおりのサイトが完成したので、このサイトをデプロイする方法について説明します。 これで、GitHub リポジトリのセクションが作成されました。実際には、finish ブランチに完全に別のデプロイ済みブランチを作成しました。 Git チェックアウトの実行が完了しました。 また、そのブランチを WP Engine のヘッドレス WordPress ホスティング ソリューションである Atlas に直接デプロイすることもできます。

これにより、WordPress のインストールと Node.js コンテナーの両方が提供され、Atlas のランディング ページでこのボタンをクリックするだけで、無料のサンドボックス アカウントにサインアップできます。 非常に簡単なフォーラムに移動します。ご覧のとおり、価格はゼロです。 詐欺防止の目的でのみ使用するクレジット カードを入力する必要がある場合もありますが、無料のアカウントを使用して、これらのいずれかを試してテストし、心ゆくまでヘッドレスで学習することができます。 それでは、WP Engine ダッシュボードを開いて、このサイトを Atlas にデプロイする作業を始めましょう。

実際に最初に行うことは、サイトのリストを開くことです。次に、本番用の WordPress サイトを開きます。 実際、ここに表示されているこの ACF ヘッドレス サイト (新しいウィンドウで WP Admin を開きます) は、皆さんがローカルで使用している zip ファイルの親サイトです。 そのため、WP エクスポートを使用してその zip を作成しました。これは、実際に本番環境の展開に使用するものです。

そこから [Atlas] タブをクリックし、[Create App] をクリックします。 そして、このオプションが表示されます。 [Pull From Repo] を選択し、[Continue] をクリックします。 GitHub で認証していない場合は、ここで認証する必要がありますが、既に認証済みなので、先に進んで自分のリポジトリを選択できます。 先に進み、このプロジェクトに使用しているリポジトリを選択し、[続行] をクリックしてから、アプリを米国中部にデプロイします。

ここから、ブランチを選択できます。前述のように、Finished を使用します。 モノレポを使用している場合のオプションもありますが、私たちはそうではありません。[WordPress のインストールを持っている] チェックボックスをオンのままにし、[ACF ヘッドレス サイトを検索] をオンにします。 ここで、.env ファイルを使用する代わりに、ファイル プロジェクトから 2 つの環境変数をコピーしたいと思います。

したがって、最初のものは次の公開 WordPress URL です。 これらは、ローカル プロジェクトで設定した環境変数と同じです。そこに、本番環境の WordPress インストールへのリンクをコピーします。 次に、別の環境変数を追加します。これは、ファウストの秘密鍵用です。 ファウストの設定メニューからそれをコピーし、そこにポップして、そのキーをファウストの秘密鍵に設定します。

それが完了したら、[アプリの作成] をクリックすると、Atlas がアプリのビルドとデプロイのプロセスを開始します。 Atlas のビルド プロセス中に、NPM のインストールと、使用しているフレームワークの NPM ビルド コマンドが実行されます。 そして、そのコードがすべてビルドされると、その Node コンテナーがネットワークにデプロイされます。 そして、これらすべてがほんの 1 秒間スピンすると、成功メッセージが表示されます。次に、提供された URL をクリックして、実際にサイトをライブで見ることができます。

成功メッセージが表示されるので、この URL を別のタブで開くことができます。 そして、サイトがローカルとまったく同じように見え、すべての正しいデータ、すべての正しい画像を取り込み、すべての ACF コンテンツを吸い込んでいることがわかります。 私たちの投稿の多くは非常に素晴らしく、Atlas でのパフォーマンスは非常に優れています。実際、ここでは非常に大きな画像をいくつか使用しています。

Atlas プラットフォームには、最新の JavaScript 開発者が喜ぶ機能がぎっしり詰まっています。 残念ながら、このプレゼンテーションではそれらすべてを詳細に説明するには時間が足りません。

しかし、Atlas は、ヘッドレス エコシステムのフロントエンド部分とバックエンド部分の両方から重要な詳細を 1 つの便利なダッシュボードにまとめて、個々のビルド ログとビルド出力を確認し、デプロイや使用した環境変数を調べることができるという非常に優れた仕事をします。特定のビルドだけでなく、GitHub リポジトリに対して作成されたすべての PR に対して追加の環境を作成できるプレビュー環境など、有効にできる追加の設定や機能にアクセスしたり、環境 Webhook を作成して特定の部分を再構築したりできます。 WordPress に変更を加えたときのアプリまたは CDN。

これらすべてが Atlas プラットフォームで可能になり、ヘッドレス WordPress で構築を開始するための障壁が本当に低くなります。

おお。 私が言ったようにおめでとう、25分でカバーすることはたくさんありました. プレゼンテーションの後もお気軽に練習を続けてください。デモ リソースの使用を開始するにあたって質問がある場合は、私に連絡してください。 ヘッドレスについて詳しく知りたいが、そのためのスペースが必要な場合は、無料の Atlas Sandbox アカウントにサインアップしてください。 今日行ったように、独自のコード リポジトリをデプロイするだけでなく、完成したヘッドレス プロジェクトがどのように見えるかを確認するのに役立つワンクリック プロジェクト スタックである、事前に作成されたブループリントを使用して開始することもできます。

We have a basic scaffold example, a portfolio example with some custom post types, and a new ecommerce example that integrates with big commerce through some of their APIs. Our team and developer relations is really passionate about meeting you wherever you are on your journey towards learning headless. So check out our headless developer's roadmap for a step-by-step series of articles and videos that build on one another to help backfill some of the concepts we've just glossed over today.

The headless ecosystem is young, but it's growing quickly. If you need help on a project, want to talk to some people using headless WordPress in production, or just want to hang out where the magic happens, join the roughly 1,000 other developers in our Discord focused on headless, where we chat, help each other with projects, and help get you moving. Thank you so much for coming to this talk. I look forward to collaborating with you on all of your future headless projects.