Advanced Custom Fields(ACF)を使いこなそう Vol.1
とても思い入れの深いプラグインで、多くのWordPressサイト構築の際にAdvanced Custom Fieldsプラグインを採用しました。
現状カスタムフィールドを利用する際にはほぼ一択で選択しています。
今回「vol.1」では以下の構成となります。
ACFとは？
Advanced Custom Fields、略してACFと呼ばれています。
WordPressのカスタムフィールドプラグインの中で、今や一番利用されています。登録済みの5万件を超えるプラグインの中でも「人気」順で見てみるとカスタムフィールドの中では群を抜いて最上位に表示されます。
https://wordpress.org/plugins/browse/popular/page/2/
現在では100万件を超える環境で有効化されているようですね。
カスタムフィールドプラグインは他にも沢山ありますが、その中でACFが選ばれている理由ともいえる特長を見ていきましょう。
なぜACFを利用するのか？
ACFでは従来のカスタムフィールドプラグインにはなかった機能を兼ね備えており、それまでより、柔軟なレイアウトを実現できるようになりました。
一部機能はACF Pro版(1サイト$25の買い切り)ありきの機能ですが、2,800円ぐらいなのでまずは一度Pro版の利用がお勧めです。その後「使えそう、便利」と思ったらDeveloperライセンス($100)を検討すると良さそうです。
早速順番に見ていきます。
1. 繰り返しフィールド (The Repeater Field) *Pro版
ACFを代表する機能の1つですが、特定のまとまった要素の繰り返しができるようになります。(もちろん単独フィールドの繰り返しも可能です。)
例えば以下のようなよくあるレイアウトを考えてみます。
これは以下のレイアウトの繰り返しになりますよね。
管理画面側では以下のような形で登録を行えます。
繰り返しフィールドでは、同じ型の要素を必要なだけ繰り返すことができます。
ここでは左端にある「1」と「2」が書かれている箇所をドラッグすると要素の並び替えができたり、右端にある「+」「-」を押すと行の追加と削除を行うこともできます。
最小繰り返し数、最大繰り返し数も指定できるので最低限◯件登録させたい、最大は◯件までにしたいといったことも設定画面から容易に行えます。
2. 柔軟コンテンツ (The Flexible Content Field) *Pro版
これもWP実装をする際に核になる特徴的な機能の一つです。運用者は必要な要素を自分で選択し、利用をすることができます。
例えばこのブログサイトでは管理画面はACFで作成しており、以下のようなフィールドを必要なタイミングで呼び出しができるようになっています。この機能が柔軟コンテンツとなります。
メニュー内の項目は自分で定義できます。例えば予め定義された「見出し」を選択すると以下のフィールドが表示できます。
続いて「画像」を選択すると、以下のようなフィールドの追加ができます。
サイトの表示側もこの追加した順序順に表示できる、まさに柔軟なコンテンツレイアウトを実現するための機能になります。
※また繰り返しフィールドと同様に、このブロック単位でドラッグ＆ドロップで要素の並び替えをしたり、ブロックの最大上限数の指定もできます。
繰り返しフィールドの中に柔軟コンテンツを内包する、または柔軟コンテンツの中に繰り返しフィールドを内包する、といった使い方もよく利用します。
3. オプションページ (Options Pages) *Pro版
普段トップページや、カスタム投稿タイプの一覧ページ、またはサイト内共通で利用したいメニューなどの入力画面を作りたい場合はどうしているでしょうか‥？ACFを利用すると、オプションページという機能があり(これ自体はWordPressでも備えている機能ではあるのですが)、「固定」でもなく「投稿」でもない独立した入力画面を管理画面内に作ることができます。そこに対し、カスタムフィールドを定義が行えます。
このサイトを例にすると、右下にあるプロフィール情報は以下のような入力フィールドから管理をしています。commonと名付けていますが、これがオプションページとなります。
固定ページで無理やり「Top」や「common」などを作らなくて良くなるので、便利な機能です。
4. 投稿オブジェクト (Post Object)
例えば、人物紹介のページを沢山作るとします。その場合、カスタム投稿タイプで「people」などを定義します。そして同じサイト内でコラムやイベント情報を作りたい場合、別のカスタム投稿タイプを作成し、「column」「event」などで作るとします。
そのコラムやイベントそれぞれに人物情報を載せたい‥。そして人物の詳細ページにも、その人のコラムやイベント情報を載せたい、とした場合、いわゆる双方向に対するカスタム投稿のリレーションが発生します。
このように情報を別の投稿タイプから引っ張りたいといった要件の場合、この投稿オブジェクトが便利です。
こういった引用したい、リレーションを張りたいといった要件の場合、それまでは「Relations Post Types」などであったり、タクソノミーを利用する手立てがありましたが、この投稿オブジェクトを利用すると、より手軽に行えるようになります。
同じようなACFの機能に、「関連 (Relationship)」という機能もあります。両方とも似たような用法ですが、「関連」のほうは記事選択の際、プルダウンメニューから特定のタクソノミーでフィルタリングをして表示、といったことができるメリットもあります。
まだまだ便利機能も多いですが、このようにACFでは従来のカスタムフィールドプラグインより便利な機能が多いのが特長です。
ACFを利用する際の注意事項とは
中規模サイトから大規模サイトまで、利用できるシーンはとても幅広いですが、一定規模以上のサイトで導入を考える場合、リスクが伴います。
経験上、一定条件が満たされることで、サイトの記事登録をする際にパソコンがフリーズし、運用に支障が出るほど管理画面が重たくなる恐れがあります。
1. 管理画面内の分岐は多くしないこと
ACFには「条件判定」という機能があり、ラジオボタンでAが選ばれたら特定のフィールドを表示する。Bが選ばれたらこのフィールドを表示する。といったようなことが行なえます。
トリガーは他にもあり、タクソノミーで◯◯が選ばれたらこのフィールドを表示する、固定ページの属性で特定の親が選ばれたら、このフィールドを表示するといったことができます。
とても便利な機能なのですが、この定義数が多すぎる、またはネスト構造（入れ子）を複雑にするを重ねないようにする、といった配慮が必要です。
2. WYSIWYGを多用しないこと
よかれと思い、繰り返しフィールドや柔軟コンテンツなどでWYSIWYGの挿入を沢山できるようにします。そうすると意図せずWYSIWYGがページによって20、30、40と生成されることがあります。これも重たくなる要因となります。
「複数行テキスト」で代替できる箇所は極力それを使うようにします。
3. フィールドグループの数を増やしすぎないこと
これも同様で、案件によっては100、200、300とフィールドグループを生成してくることがあります。フィールドグループと書きましたが、このグループの数というよりカスタムフィールドの定義数が膨大になることでローディングに時間がかかってくる要因になります。
共通パーツ化できる箇所は共通化し、同じ要素を繰り返し定義しないこと。またACFは4系に入ってから、便利な「clone」という機能があり、同じセットを再度呼び出しができるようになりました。これによりなるべく構造をシンプルに保てるようになります。
4. 一定規模のサイトでは全体俯瞰をすること
1〜3のまとめですが、ワイヤーフレームの段階から、いかに精度を上げて全体のフレームを構造化させ、繰り返し利用ができるよう設計するか。実装フェーズから検討すると遅いことが多い為、ワイヤーフレームの段階からチェックをすることが大切です。
その際、実運用を想定して、不要な要素はないか、統合できる要素はないか、定めようとしている設計では使いづらい運用にならないか、複雑な分岐や引用にならないか、などの視点が欠かせません。
カスタムフィールドとGutenberg
今界隈ではv5.0で来るGutenbergが盛り上がりを見せていて、これがカスタムフィールドに取って代わるのでは？なんていう話もあり「確かに‥」と思う側面もありつつ、実際は置き換わらないだろうなと予想してます。
GutenbergはGUIで必要な要素を自分で容易に追加することができ、インターフェース上はElementor Page Builderのようなページビルダーやconcrete5などにどちらかというと近しい印象です。
管理画面側の入力エリア
そしてGutenbergから生成されるHTMLは、WYSIWYGのように1つのデータとして扱えるので扱いやすい魅力もあります。
<!-- wp:paragraph -->
<p>ここにテキストが入ります。</p>
<!-- /wp:paragraph -->
<!-- wp:heading -->
<h2>見出し</h2>
<!-- /wp:heading -->
<!-- wp:list -->
<ul>
<li>リスト</li>
<li>リスト</li>
</ul>
<!-- /wp:list -->
<!-- wp:paragraph -->
<p></p>
<!-- /wp:paragraph -->
<!-- wp:text-columns -->
<section class="wp-block-text-columns alignundefined columns-2">
<div class="wp-block-column">
<p>ここにテキスト情報が入ります。ここにテキスト情報が入ります。ここにテキスト情報が入ります。ここにテキスト情報が入ります。</p>
</div>
<div class="wp-block-column">
<p>ここにテキスト情報が入ります。ここにテキスト情報が入ります。ここにテキスト情報が入ります。</p>
</div>
</section>
<!-- /wp:text-columns -->
Gutenbergでは上記のように、特定のHTML構造やclassなどが割り当てされたHTMLが生成されます。これ自体は今後、より複雑なレイアウトなど表現方法の幅が広がり、そのサイトが「個」として独立をしたWordPressサイトを構築するケースでは使いやすいものになりそうです。
一方でCMSは「Elemeno」や「Contentful」「Directus」などヘッドレスCMSという新しい型のCMSも出てきていて、CMSの用途はあくまでデータを入力する為の箱として利用し、その入力値を必要な配信先に表示しましょう。という流れもあります。
※Directusサイトの例。「headless CMS」と既に記載があります
これはWordPressも同様で、Gutenberg化を推進する一方でREST APIの仕組みを既に提供しています。それこそ「分解する必要がない」ということであればGutenbergという1つのデータをそのまま表示すれば良さそうですが、運用する中での柔軟なサイト規模の拡張、要素のON/OFFやABテストなどのマーケティングテスト、受け取り手となる対象プラットフォームにおけるコンテンツの最適化（それによるユーザーエクスペリエンス）を考えていく場合は、データの分解と再利用が求められ、そこにはカスタムフィールドは欠かせないように思います。
またカスタムフィールドの利点として、必要な要素を必要なタイミングで呼び出すことができる、といったことも挙げられると思います。例えばラジオボタンで特定の○○の場合は、カスタムフィールドの○○のフィールドを表示させるといった使い方です。
つまり不要な要素は「表示させない」という選択肢が作れることで、UI上ノイズが少ないことから運用者にとっては1つのメリットとなりそうです。Gutenberg形式の場合、その場で必要のない要素も表示されることになるので、「極力ノイズを避け執筆への集中させる」という点においてはカスタムフィールドのほうが優位性があるように感じます。
つまり単純に置き換わるかどうかではなく、それぞれのメリットを活かしつつ使い所によって使い分けることでより効率的なサイト構築ができるようになる気がします。
イメージとしては、サイト(というより主にブログ)はWYSIWYGで、ちょっとしたサイトを作る場合はGutenberg、規模の大きいサイトやPDCAをしっかり回していくサイトの場合はカスタムフィールドのような住み分けになるのかなと思いました。