WordPressでホームページを作成する際、Advanced Custom Field（ACF）って便利ですよね。
私もホームページ作成時に初期段階から導入して、検索機能用の属性設定などに使用したりしています。

ただし、ある程度作ってから、仕様変更したい時ってありますよね。
「用途とID名が一致しないから、ID変えても良いですか？」とか「今までフリーテキストにしてたけど、誤入力が多いからドロップダウンリストに変更したい」等、あると思います。

これやっちゃった場合、どうなるのかな？
大きなサイトを運営している方だと、とても心配ですよね。
この件、ちょっと調査したので、報告します。

Advanced Custom Fieldのフィールド定義はデータベースのwp_postsに保存されている

さて、それではACFをインストールして検証していきましょう。

まず、検証用のカスタムフィールドを定義します。

とりあえず、最初はテキストフィールドを作ります。

さて、この時点で確認ですが、カスタムフィールドの定義情報はwp_postsの中に存在しているようです。

wp_postsにこのようなデータが格納される場合、一般的な投稿記事や固定ページと区別するために、post_typeカラムが使用されます。

今回もその例に漏れず、
カスタムフィールドグループはpost_typeが”acf-field-group”として登録されており
カスラムフィールドはpost_typeが”acf-field”として登録されています。

Advanced Custom Fieldの値はデータベースのwp_postmetaに保存されている

Advanced Custom Field（ACF）でカスタムフィールドを定義したら、各ページやカテゴリーでデータ入力をします。

さっき、テキストフィールドとして定義したので、何か適当に文字を入力します。

さて、このデータが保存される先ですが、データベースのwp_postmetaに保存されます。

データベースのwp_postmetaを開くとこのようにデータが保存されていました。
テキストフィールドなので、そのまま文字が入っています。
どのフィールドの値かを紐づけている部分は、フィールドIDではなく、フィールド名が入っています。

ここで１つ気が付いたことがあるのですが、カスタムフィールドの値を登録した記事を更新すると、カスタムフィールドのレコードがどんどん増えていくんです。

これはリビジョンの機能と関係していると思いますが、更新するたびに新しいレコードを作って、カスタムフィールドも履歴が残るような仕組みになっているみたいです。

でも、これたくさんカスタムフィールドを使っているサイトを長期運用したら、データベースの検索処理速度に影響出るんじゃないのかな・・・？

Advanced Custom FieldのフィールドIDを変更した場合

さて、ここから本題です。
Advanced Custom Field（ACF）のフィールドのIDを変更したい時、ID変えたらどうなるか・・・

実際に変えてみます。

“text_field”を”text_field_alt”に変えてみます。

まだフィ－ルドIDを変えただけですが、この時点でデータベースを確認してみると、wp_postsに保存されているフィールド定義は新しいデータが作られるわけではなく、先ほど登録されていたIDのデータが”text_field_alt”に上書きされていました。

では、wp_postsのフィールドIDが上書きされているので、wp_postmetaのフィールドIDも更新されているかというと、こちらは自動的には更新されません。

Advanced Custom Field（ACF）のデータはフィールドIDで紐づいているため、IDを変更すると上記のようにデータの紐づきは解除されてしまいますので、フィールド定義画面でフィールドIDを変更すると、編集ページを開いた時にデータは飛びます！

さっき入力したのに、空っぽになっちゃった！

でも、逆に値がそのままであれば、フィールドIDを元に戻せば、データも再び紐づくので、直すことができます。
また、力づくですが、クエリを使って、データベースを変更してしまうのもありです。

UPDATE wp_postmeta SET meta_key = "text_field_alt" WHERE meta_key = "text_field";

ただし、複数のカスタムフィールドグループを定義しているサイトの場合、別のカスタムフィールドグループでも同じフィールドIDを使用していると、そっちのデータもまとめて変更されてしまうので、要注意です。

Advanced Custom Fieldのフィールドタイプを変更した場合

さて、IDを変更するとマズイことはわかりました。
それではデータ型の変更はどうでしょうか？

例えば、先ほどのテキストフィールドを選択フィールドに変更した時、どうなるでしょうか？
やってみよう！

こんな感じでフィールドタイプを変えてみました。

フィールド定義のwp_postsを覗くと、やはり同じIDのフィールドが書き換えられていました。
フィールドタイプを変更しても新しいレコードは作られないようです。

そして、先ほどと同じくwp_postmetaに変化はありません。
フィールドIDは”text_field”のままなので、データの紐づけは途切れていないはずです。

なので、このまま先ほど”test”と入力したフィールドを覗いてみます。

セレクトボックスに一致するデータがないため、リストの先頭が表示されているようです。

ん？待てよ・・・もし、選択フィールドにテキスト入力の内容と同じ文字列が入っていたらどうなる？

選択肢の間に”test”を挟み込んでみました。

初期値がtestに変わっている！
記事の更新を行っていないので、データはテキストフィールドの時のままです。

ここで、選択ボックスの値を変更してみましょう。

カスタムフィールドの値を変更して、投稿記事を更新します。

データを見ると、選択肢の番号などではなく、選択肢の値が入っているようです。
なるほど。テキストフィールドでも数字フィールドでも、選択フィールドでも値を文字列として保存して管理しているようですね。
なので、PHPの型が曖昧な比較した時に、一致したらそのまま使えるっていうことなんだ！

何の役に立つかわからない検証でしたが、ご活用ください。
データベースのどこにどういう形式で保存されているかわかったので、最終的には力技でなんとかなりますね！

パワー！！！