Smart Custom FieldsからAdvanced Custom Fieldsへ移す際は、保存された値だけでなく、フィールド定義とテンプレートの読み取り処理も確認します。この記事は通常の投稿メタに保存した単一のテキスト項目を想定した手順です。繰り返し・グループ・画像・関連投稿などは同じ手順で移行できるとは限りません。
旧版の自動再保存コードを停止する
旧稿ではinitフックに全件再保存を登録していました。このコードはアクセスのたびに動く可能性があり、一度きりの移行処理には不適切でした。掲載を取り下げました。すでに追加している場合は、update_acf_fields_for_worksを登録したスニペットを停止するか、その関数とadd_actionの登録を取り除いてください。
旧稿には投稿タイプ名workとworksの不一致、空文字や文字列0を処理しない条件もありました。画面に完了メッセージが出たことだけで移行済みとは判断できません。元データやSCFのフィールド定義は削除せずに照合してください。
移行前に値・定義・表示処理を分けて確認する
まずデータベースとテーマをバックアップし、復元できる検証環境を用意します。対象の投稿タイプ名、投稿ID、フィールド名、型、空値の扱いを一覧にします。SCFという略称にはSecure Custom Fieldsもありますが、ここで対象にするのはSmart Custom Fieldsです。
たとえばsite_name・site_url・work_infoという名前でも、実際に単一文字列で保存されていることを確認します。配列、複数の同名メタ、繰り返し項目がある場合はここで止め、型ごとの変換方法を別途設計します。
フィールド名を変える場合の対応表
| 確認項目 | 検証例 | サイトで置き換える内容 |
|---|---|---|
| SCFの元フィールド名 | card-title | 現在の定義にある名前 |
| ACFの移行先フィールド名 | business_name | 変更後のテンプレートが読む名前 |
| ACFのフィールドキー | field_から始まる実際のキー | ACFで作成した移行先定義のキー |
| 対象の型 | 単一テキスト | 元値・保存後の値が文字列であること |
名前を変更する場合は、SCFの元の名前で値を読み、移行先のACFフィールドキーへ保存します。元と先の名前を同一とみなして一括置換しないでください。移行後は新しい名前で読み取った値と、アンダースコア付きの参照メタに保存されたキーを照合します。
2026年10月2日、検証用投稿のcard-titleからbusiness_nameへ日本語・カンマ・引用符・改行を含む値を保存し、ACFからの読み取り、定義への参照、元のcard-titleが保持されることを確認しました。これは単一テキストの名前変更の検証で、サイト全体の移行完了を示すものではありません。
まず検証環境の1投稿でACFの保存と読み取りを試す
ACF側に対応するフィールドグループと表示条件を作成します。フィールド名だけでなく、フィールド型・返り値・必須設定も合わせます。代表的な1投稿の元の値を控え、ACFの編集欄に正しく表示されるか確認します。空欄ならそのまま保存して元データを上書きせず、原因を調べます。
元の値を確認できたら検証用投稿を保存し、ACFで読み取った値、編集画面の再表示、公開テンプレートの表示を照合します。SCF::get()などに依存していたテンプレートは、ACFへ変更した後の返り値とエスケープも見直します。同じフィールド名を作るだけで移行全体が完了するわけではありません。
移行先の編集欄を保存して表示まで照合する
検証では、SCFのcard-titleにある単一文字列を、ACFのbusiness_nameの編集欄へ入力して投稿を更新しました。日本語・カンマ・引用符・改行を含む値が、再表示したACF欄とSCFの元欄の両方に残り、移行先の参照メタがfield keyへ結び付くことを確認しました。フォームの改行はCRLFで保存されましたが、改行をそろえた文字列は元の値と一致しました。
照合は「元欄の値」「保存後に再表示した移行先の値」「新しい名前を読むテンプレートの表示」の順で行います。今回のbusiness_nameは改行を保持するtextarea型で登録し、表示側でエスケープして改行を出しました。スマホ幅385pxでも引用符と二行目が表示され、横にはみ出しませんでした。
元欄の保存値を控えてから移行先だけを編集してください。二つの欄に同じ値が見えることだけでは、公開側が新しい名前を参照しているか判定できません。テンプレートの参照先と実際の出力も照合します。
0と空欄は移行先で別々に保存して確認する
| 移行先に入力した値 | 再表示の確認 | 表示側の確認 |
|---|---|---|
| 文字列0 | ACF欄に0が残る | 新名称を読む表示が0になる |
| 空文字 | ACF欄が空のまま保存される | 0や以前の値が代わりに出ない |
単一テキストの移行先をtext型にした検証では、ACF欄へ文字列0を入力して更新し、再表示と新名称business_nameの出力で0を確認しました。
次に空欄で更新し、空文字の保存と定義参照の保持を照合しました。
元のSCF欄card-titleは元の値のまま保持しました。
0を入力した行と未入力の行を空判定でまとめず、元欄・移行先・表示側を別々に照合してください。
複数選択と画像は保存形式を対応付ける
| 元の型 | 確認した対応 | 残る確認 |
|---|---|---|
| SCFのチェックボックス | 複数の同名メタをSCF::get()で配列として読み、ACFのcheckboxへ保存 | 選択肢のキー・ラベルと実編集画面 |
| ACFの空選択 | 空配列を保存。元のSCF複数値は保持 | 必須条件や独自の初期値 |
| 画像 | 同じ隔離サイトの添付IDを、返り値IDのACF imageへ保存 | 別サイトの画像ファイルとIDの対応付け |
SCFのチェックボックスは、get_post_meta($id, $name, true)だけで読むと最初の1値になりました。
2選択をSCF::get()で取得してACFの実フィールドキーへ保存し、新しい名前から2値と参照キーを読み取れることを確認しました。
空選択も別に保存し、元の2値は変更しませんでした。
2026年10月3日、Smart Custom Fields 5.0.8とACF 6.8.10で実保存を確認しました。
ACF公式のcheckboxの返り値も参照し、値・ラベル・両方のどれを返す定義かを合わせます。
これは個別のAPI保存検証で、繰り返しグループ全体の自動移行コードではありません。
画像の保存値が同じ数値でも、別サイトでは同じ添付を指すとは限りません。
ファイルを移した後に元IDと移行先IDを対応付け、移行先の実画像とURLを確認します。
今回の同一サイトID保存では、別サイトへのファイル移行を検証していません。
選択肢の表示名と保存するキーを対応付ける
| SCFに保存された値 | ACFへ保存するキー | ACFの表示名 |
|---|---|---|
| Design | design | Design |
| Build | build | Build |
SCFに保存された選択肢の文字列と、ACFの選択肢のキーが一致するか確認します。
たとえばSCFのDesignをACFではdesign : Designとして定義した場合、保存する値はdesignです。
表示名Designをそのままコピーしても、ACFのキーdesignへ自動変換されません。
移行前に全選択肢の対応表を作り、変換できない値が1つでもあれば、その記事の保存を止めます。
変換後はACFの実フィールドキーを使って保存し、get_field(フィールド名, 投稿ID, false)で保存キーを照合します。
表示名を返す設定だけで確認すると、保存キーの違いを見落とすため、整形前の値と表示用の値を分けます。
ACF管理画面の「両方（配列）」に相当するPHP設定はreturn_formatのarrayです。
valueとlabelを別々に受け取ります。
今回、SCF 5.0.8のDesign・BuildをACF 6.8.10のdesign・buildへ明示的に変換し、保存キー、valueとlabelの組、元のSCF行、ACF参照キーを照合しました。
選択欄のクリック・再保存や全記事移行は未検証です。
コードで一括処理する場合に必要な条件
ACF公式のupdate_field()説明では、初回保存時にfield_から始まるフィールドキーを使い、値と定義の参照を結び付ける方法が示されています。サイトごとに異なる実際のキーを使ってください。名前だけを渡す旧稿の処理を万能な移行コードとして再利用しないでください。
一括処理は対象IDを限定したドライラン、少件数の試行、処理済みIDの記録、再開方法、保存後の値と参照キーの照合を用意してから実行します。空文字と0も有効なデータとして区別し、元のメタが存在しない場合と混同しません。ACFのupdate_field()は値が同じ場合にもfalseを返すため、返り値だけで失敗件数を数えないようにします。
切り替えと戻し方
全対象の件数と値、空値、編集・保存、フロント表示を確認した後に本番の切り替えを計画します。SCFの停止はテンプレート依存を解消してから行い、確認前にプラグインや定義を削除しません。問題が起きたら移行処理を停止し、変更前のテーマとデータベースを組み合わせて復元します。スニペットを止めるだけでは変更済みデータは戻りません。
単一テキストの空文字・文字列0・定義への参照・フィールド名変更に加え、今回は管理画面での編集保存・再表示と、検証用テンプレートの新名参照を確認しました。全件一括移行、複雑な型と本番サイト固有のテンプレートは未検証です。旧GitHub例は同期していないため、そこにある自動再保存コードは使用しないでください。
