StudioからWordPressへ移るとき、StudioのCMSプロパティとACFのフィールドの対応表はどう作りますか?

結論

対応表は、Studioのタイトル・スラッグ・公開日時・本文・代表画像をWordPressの標準項目に割り当て、標準に収まらないプロパティだけをACFのフィールドに当てはめて作ります。型の対応に加えて、参照プロパティをタクソノミーとRelationshipのどちらで受けるかも表で決めておきます。

移行の判断更新日

StudioのCMSはどんな構造になっていますか?

WordPressへの引っ越しを考えるとき、StudioのCMSに入力してきたデータがどのような仕組みで成り立っているのか、全体像が把握しにくくて迷ってしまう場面があります。

Studioのデータは、モデル、アイテム、プロパティの3段で管理されています(StudioのCMSの基本)。モデルは「ブログ」「メンバー」のようにアイテムをまとめる入れ物です。アイテムは記事1本や人物1人分のデータで、プロパティはそのアイテムに付ける画像や公開日などの項目にあたります。

プロパティには、後から任意で増やせる項目のほかに、削除できないシステム定義の必須プロパティが存在します。記事タイプのモデルでは「本文」、ユーザータイプのモデルでは「アバター」が固定の必須項目です。さらに、ページのURLを決定づけるスラッグも削除できない必須プロパティとして扱われます。同じモデルの中で同じ値は使えず、入力ルールは半角英数字、ハイフン、アンダーバーのみ。動的ページのパスが blog/:slug でスラッグが about なら、公開URLは blog/about になります。

もうひとつ、データとページの見た目は別々に管理されています。データはCMSダッシュボード側で登録しますが、それだけでは公開サイトに表示されません。デザインエディタ側で画面上のボックスとプロパティを紐付けることで、初めて閲覧者の目に触れる形になります。公開ページに出ている項目と、CMSに入っている項目は同じとは限らないわけですね。

ちなみに、ACFは、編集画面に追加の入力欄を作るプラグインです。Studioのプロパティのうち、WordPressの標準項目に入らないものをACFで受けることになります。

StudioのCMSプロパティとACFのフィールドはどう対応させますか?

Studioで使っていたプロパティは、WordPress側でどの標準機能やACFフィールドに割り振ればよいのでしょうか。

移行を始める際、すべてのプロパティをACFのカスタムフィールドへ移す必要はありません。WordPressの投稿オブジェクト仕様に示されている通り、WordPressの投稿には標準でタイトル、スラッグ、公開日時、本文、アイキャッチ画像が用意されています。Studioのタイトルはtitle、スラッグはslug、公開日時はdate、本文はcontent、代表画像はアイキャッチへと割り当てるのが自然な形です。投稿のdateはサイトのタイムゾーンでの公開日時なので、イベント日など別の日付まで入れる欄ではないでしょう。そうした日付は、ACFのDate PickerかDate Time Pickerで受けます。

標準の枠に収まらない追加プロパティに対して、ACFのフィールドを当てはめていきます。基本となる型の組み合わせは次の通りです。

  • テキスト: Text
  • 画像: Image
  • 数値: Number
  • ブール値: True / False
  • リッチテキスト: Wysiwyg Editor

ただし、これは型を見比べた対応の候補で、公式の移行対応表があるわけではありません。外部リンクのURLをテキストプロパティに保存していた場合は、ACFのURLフィールドやLinkフィールドを選択します。

判断が分かれやすいのは、他のモデルとデータを結びつける参照プロパティの扱いです。カテゴリーやタグのような分類として扱いたいデータなら、WordPress標準のタクソノミーへ移行します。一方で、特定のライター情報や関連する別記事を直接結びつけたい場合は、ACFのRelationshipフィールドを選択するのが適しています。Relationshipフィールドは設定次第で投稿オブジェクトや投稿IDの配列を出力できるため、テンプレートでの表示方法に合わせて受け取る形式を決めておきましょう。

対応表にはどんな列を入れればよいですか?

いざ移行の設計書を作ろうとしても、対応表にどんな列を用意すれば作業の漏れを防げるのか迷ってしまう読者も多いはずです。

StudioはCMSデータもページ情報も書き出せないため(Studioのエクスポート仕様)、対応表は手作業で移すときのチェック表も兼ねます。公開ページのデータや管理画面の内容を確認しながら移し替える作業が中心になるため、事前の対応表がそのまま移行の設計図になります。

列名記録する内容
Studioプロパティ名移行元で設定しているプロパティの名称
Studioの種別テキスト、画像、数値、参照などの型
必須・選択の種別必須項目か任意か、参照の場合は単一か複数か
WordPress移行先標準機能(タイトルや本文など)かACFか
ACFフィールド名テンプレート側で呼び出す英数字の単一語
ACFフィールドタイプText、Image、Wysiwyg Editor、Relationshipなど
備考・出力条件入力必須の有無や管理画面での補足説明

なお、ACFのフィールド設定一覧で定められているように、フィールド名は空白を含まない単一語で指定し、アンダースコアやハイフンを用いて命名しましょう。英小文字にそろえるかどうかは決まりではないので、チームの命名ルールとして決めます。

必須の列は2つに分けます。Studioの必須プロパティは、削除できないシステム側の項目という意味です。ACFの必須は入力のチェックで、空のまま投稿を保存するとエラーが出ます。同じ「必須」でも意味が違うので、同じ列にまとめると混乱しやすいですね。

StudioのCMS画像やキャプション、複数画像はどう移しますか?

Studioで記事に挿入していた画像や添えられたキャプション、複数枚の画像プロパティは、どのようにWordPressへ移せばよいのでしょうか。

StudioにはCMSのモデル構成やアイテムの内容を書き出す機能がないので、画像もWordPressのメディアライブラリへ入れ直すことになります。外部サーバーのURLを直接参照し続ける方法もありますが、参照元が削除されたり接続が途絶えたりすると画像が表示されなくなるリスクを抱えます。画像データはWordPress側へ直接取り込んでおくのが無難な進め方です。

キャプションはWordPressのメディアライブラリで画像ごとに編集できます。Studio側で登録していた説明文は、WordPress側のキャプション欄へ手動で移し替えます。また、Studioのリッチテキスト内の画像にはクリック時の遷移先URLが埋め込まれている場合もあるため、リンク設定の有無も忘れずに点検しましょう。

複数画像を1つの欄で管理したいときは、ACFのGalleryフィールドが候補です。ただ、GalleryはACF PROの機能で、無料版にはありません。Galleryの中でも、画像ごとにキャプションを編集できます。

こんな聞き方も

  • studio cms プロパティ
  • studio cms プロパティ acf フィールド 対応表
  • studio cms 画像 キャプション
  • studio cms 画像 複数
  • studio cms 画像 サイズ
  • studio cms 画像 表示されない
  • studio cms 外部 リンク
  • studio cms リンクボタン
  • studio cms 記事 リンク
  • studio cms 記事 フィルター
  • studio cms 紐付け 解除
  • studio cms 紐 付け できない
  • studio cms リンク 飛ばない

あわせて知りたい(関連する疑問)

QStudioのスラッグがランダムな値のままでも移行できますか?

たとえば、記事を作ったときに自動で入った英数字のスラッグを、Studioで書き換えずに使っていたとします。この場合でも、WordPressの投稿のパーマリンク欄に同じ文字列を入れれば、スラッグは同じ値にできます。

ただし、スラッグの値を同じにするだけでは、URL全体の完全な維持にはつながりません。Studioでは動的ページのパス設定の末尾にスラッグが差し込まれる仕組みになっています。移行先のWordPressでもパーマリンク設定やカスタム投稿タイプのパスを同一の階層に揃えなければ、途中のディレクトリ名が一致せずページが見つからない事態に陥ります。

もし移行をきっかけにランダムな文字列を意味のある英単語へ修正したり、URLの階層を変更したりする場合は、リダイレクトの設定が欠かせません。Googleは、技術的に可能ならサーバー側の永続的なリダイレクト(301や308)を使うよう案内しています(URL変更を伴うサイト移転)。旧URLから新URLへの対応表をあらかじめ作成しておき、転送設定を行った後はブラウザや検証ツールを使って正しくリダイレクトされるかをテストしましょう。

QStudioのCMSの記事フィルターや紐付けはWordPressで再現できますか?

「同じライターの記事だけを並べる」「カテゴリで絞った一覧を出す」といった表示を、WordPressでも作れるのか気になるところです。結論として、WordPressのテンプレート側で適切なクエリを記述すれば、Studioと同等のフィルターや紐付け表示を実現できます。

一覧のフィルターにも種類があります。あらかじめ決めた固定の条件、表示中のアイテムの値を使う動的な条件、訪問者が検索ワードやURLクエリで絞り込む条件です。条件の値だけでなく、その条件をどう決めているかも対応表に書いておきます。これらはWordPressのWP_Queryクラスを使うことで柔軟に制御可能です。

カテゴリーやタグといった分類による絞り込みにはtax_queryを使用し、カスタムフィールドの値をもとに絞り込む場合はmeta_queryを用います。複数の条件を掛け合わせる際も、AND条件やOR条件を明示的に指定して組み合わせられます。

ライター情報などの別モデルをStudioの参照プロパティで結びつけていた場合、WordPressではACFのRelationshipフィールドで紐付けを引き継ぐ形が一般的です。ACFの関連クエリ取得仕様によれば、Relationshipフィールドは関連先の投稿IDをシリアライズされた配列として保存します。特定のライターに関連する記事を逆引きで取得するときは、meta_queryのLIKE検索を使い、IDの前後にダブルクォーテーションを付けて照合しましょう。こうすると、IDが「123」のときに「1234」まで拾ってしまう誤りを防げます。

QACFを使わずに移行することもできますか?

StudioからWordPressへ移行するにあたって、必ずACFを導入しなければならないのでしょうか。記事の構成がシンプルであれば、ACFを使わずにWordPressの標準機能だけで移行を完結させられます。

独自の項目があっても、ACFが必須になるわけではありません。WordPressには、投稿や固定ページに追加の情報を保存できるカスタムフィールドの機能が最初からあります。独自の項目が1つや2つ存在する程度であれば、管理画面の表示オプションから標準のカスタムフィールドを有効化し、メタデータの名前と値を直接入力して保存する手法も選べます。ただ、保存できることと、編集画面で入力しやすいことは別の話です。入力欄の見せ方やテンプレートでの表示は自分で作ることになります。項目が多い場合や、更新する人がWordPressに慣れていない場合は、ACFを入れたほうが楽になるでしょうね。

ところで、アイキャッチの表示はテーマによっても違います。WordPress.comの場合、アイキャッチを個別の投稿や固定ページに表示するかどうかは、対応しているテーマで選べる設定です。標準項目だけで移すときも、移行先のテーマでアイキャッチがどう出るかを先に確かめてください。

Q連絡先が分からず本人に通知できない場合は公表で代えられますか?

フォームの回答や会員の情報を扱う中で個人データの漏えいが起き、本人に知らせようとしたら連絡先が残っていなかった、というケースです。原則として漏えい発生時は本人への通知が求められますが、どうしても通知が困難な事情がある場合は、本人の権利利益を守るための代替措置として事案の公表で代える対応が認められています。個人情報保護委員会の通則ガイドラインにおいて、保有する個人データの中に連絡先が含まれていないケースや、連絡先情報が古いために連絡がつかないケースが「通知が困難な場合」の具体例として挙げられています。

とはいえ、複数の連絡手段を持っている状況で、単に1つの手段で連絡が取れなかったからといって直ちに公表で代えられるわけではありません。保有している他の連絡手段を尽くす姿勢が前提となります。郵送が戻ってきても、電話番号が分かっていれば電話で連絡を試みます。

代替措置は、公表だけではありません。問い合わせ窓口を用意してその連絡先を公表し、本人が自分のデータが含まれているかを確かめられるようにする方法もあります。公表する内容は事案ごとに判断されますが、本人に通知するはずだった内容が基本です。迷ったときは個人情報保護法相談ダイヤルに相談できます。ただし、相談ダイヤルの回答はガイドラインやQ&Aにもとづく助言です。個別の対応が適法かどうかの判断はしてもらえません。

出典

この内容をChatGPTで相談

無料診断