大量の記事のカスタムフィールドの内容を、新規で作成したカスタムタクソノミーに移動したい。
リニューアルや引き継ぎ案件でたまーに発生する作業です。

まず、サイトに掲載するデータをカスタムフィールドにするか、カスタムタクソノミーにするか、これは明確な場合もあれば、迷う場合もあります。
データが一意であればカスタムフィールドにしておけば良いのですが、サイトを長らく運用しているうちに「あれ？これ結構何回も使うぞ？カスタムタクソノミーにして選択式の方が良かったかも。」という状況が発生することもあります。

例えば、
毎回異なる調味料を紹介するサイト。カスタムフィールド「今日の調味料」を作成。
数年経つうちにレシピサイト寄りに路線変更。また、最初は単発の扱いであった「ハリッサ」のレシピが好評で、カスタムフィールド「今日の調味料」に「ハリッサ」が登録されている記事だけでも数十に。

こんな場合、明らかに「今日の調味料」はカスタム投稿タイプにしておいた方が運用が楽で、また「ハリッサを使ったレシピ一覧」の表示も簡単です。

弊社では「後々面倒にならない。運用が楽」であることを最も重視しているので、上記のようなことはめったに起こりませんが、既存のサイトではたまにみる設計です。

今回は、「カスタムフィールド」を利用して多くの記事を書いてしまったが、この「カスタムフィールド」に登録した単語を「カスタムタクソノミー」に移動、記事の他の部分には手を加えない。という作業をしてみます。

作業の順序

作業の順序はこのような感じになります。
1.カスタムフィールドを含んだ投稿をCSVでエクスポート
2.タクソノミー登録用にCSVを加工する。
3.タクソノミーを一気に登録する。
4.タクソノミーと関連付けた投稿CSVをインポートして投稿を上書き
5.カスタムフィールドの削除等の仕上げ

それでは実際に作業してみます。

1.カスタムフィールドを含んだ投稿をCSVでエクスポート

これはプラグインを利用します。
今回は「WP All Export」を使ってみましょう。

投稿タイプを選択してから、エクスポートするデータの項目の設定に進みます。

エクスポートするデータを選択します。
プラグイン「Advanced Custom Fields」（ACF）を利用したカスタムフィールドのラベルは「ACF」に表示されています。
該当のラベルを中央にドラッグします。

インポート時はIDで上書きする投稿を判別するので、「Title」や「Content」は枠外にドラッグしてクリアしても良いでしょう。

設定完了後、CSV形式でローカルに保存します。

2.タクソノミー登録用にCSVを加工する。

ローカルに保存したCSVは
・タクソノミー登録用
・投稿上書き用
の2種類に分けることになります。
まずは「タクソノミー登録用」にCSVを加工しましょう。

GoogleスプレッドシートにCSVをアップする

エクセルでもLibreOfficeでも何でも良いと思いますが、今回はGoogleスプレッドシートで加工してみます。
空のスプレッドシートを作成し、ローカルのCSVをインポートします。

「現在のシートを置換する」をチェックしてインポートします。

こんな感じでずらっと表が作成されます。

タクソノミー作成用の表を作るので、まずはシートをコピーして「タクソノミー抽出作業」のような名前を付けておきましょう。

Googleスプレッドシートで加工

加工に入ります。
この作業では、カスタムフィールド以外の情報は必要が無いので削除しておきます。
下の場合、「Id」と「Title」列は必要ありません。

下はカスタムフィールドのみ残した列のイメージです。
fruitsというフィールドに、みかんやいちご等の単語が並びます。
これらをタクソノミーとしてサイトに登録するために、まずは「重複」を消していきます。

単語の重複を排除する

重複の削除は簡単です。

列を選択して、上部の「データ」から「重複を削除」をクリックして完了です。

重複が削除されました。

基本的な加工は一旦ここまでにして、「3.タクソノミーを一気に登録する。」に進みます。

3.タクソノミーを一気に登録する。

まずは移行対象となるタクソノミーをサイトに登録しておきます。
例えば、カスタムフィールドの項目「Fruits」をタクソノミーに移動したい場合は「Fruits」や任意の名前でタクソノミーを作成します。
「Custom Post Type UI」等のプラグインを利用しても良いでしょう。

このタクソノミーに個々の単語（ターム）を一括で登録する為、プラグインを利用してみます。

今回は「WP Taxonomy Import」を使います。
※長らく更新されていない為、管理画面からのプラグイン検索結果には表示されず、ダウンロードしてインストールする必要があります。

プラグインを有効可して、「設定」→「Taxonomy Import」から設定画面を開きます。

プルダウンから登録しておいたタクソノミーを選択し、フォームにタームを記入していきます。
タームの入力方法は下記の通りです。
・デリミタで区切るとタームとスラッグを同時で登録可能（デフォルトのデリミタ: $ ）
例:りんご$ringo
・タームの親子関係は->で指定可能
例
Toyota->rav4
Toyota->ch-r

スラッグも登録しておく

ということなので、先程作成した表にスラッグも追加してみます。
コツは間に一列を追加し、セルにデリミタ（$）を入れておくことです。

こうしておけば、表をコピーして

エディタ（ATOMやSublime Text、VS Code等何でも良いです）にペースト

余計な空白を置換して削除すれば、「Taxonomy Import」に使えるテキストが完成します。

※画像では一列目（fruits$スラッグ）までコピーしてしまっていますが、ここは必要ありません。

「Taxonomy Import」にテキストをペーストして、タクソノミーをインポートします。

ここまでで、カスタムフィールドに登録されていた単語を特定のタクソノミーのタームとして登録することができました。

4.タクソノミーと関連付けた投稿CSVをインポートして投稿を上書き

後は投稿とタクソノミー（のターム）を紐付けて、既存の投稿を上書きします。

「1.カスタムフィールドを含んだ投稿をCSVでエクスポート」で作成し、スプレッドシートにアップした表を利用します。

投稿の一括登録（上書き）には、プラグイン「Really Simple CSV Importer」を利用してみます。

このプラグインも長らく更新が無く、ダウンロードしてインストールが必要になります。

「Really Simple CSV Importer」の基本的な使い方

基本的な使い方は、プラグイン製作者様のこちらの記事が一番わかり易いです。

CSVの各項目のタイトルをルールに沿ってリネームし、WordPress管理画面「ツール」→「インポート」→「CSV」からインポートを実行します。

「Really Simple CSV Importer」用に表を加工する

今回は既存の記事に、新規設定したタクソノミーを登録するだけなので、表はシンプルです。
必要なのは記事IDとタームのみです。後は、投稿タイプの指定も推奨されているので追加しておきます。

元の表。実際はTitleの列も必要ありません。
エクスポートしたカスタムフィールドの項目名を、今回登録したタクソノミー名に変更します。

「Really Simple CSV Importer」ではタクソノミーを登録する際、下記のルールがあります。
・列名は「tax_タクソノミー名」。例えばfruitsならtax_fruits
・タクソノミーとタームは登録済である必要がある※この為、「3.タクソノミーを一気に登録する。」の作業をしておく必要があります。

今回の作業で最低限必要なのは、このようなイメージの表です。※ポストタイプは必須ではありませんが、指定が推奨。

加工した表をCSVとしてローカルに保存

表の加工が完了したら、「ファイル」→「ダウンロード」からCSV形式でローカルに保存します。

WordPress管理画面からインポート画面（「ツール」→「インポート」→「CSV」）から先程のCSVを選択して、インポートを実行して完了です。

5.カスタムフィールドの削除等の仕上げ

後は、利用しないフィールドの削除、管理画面で該当するカスタムタクソノミーの表示、サイト側の表示コードの修正、等の仕上げを行います。

カスタムフィールドのデータを削除「Delete Custom Fields」

「Advanced Custom Field」から項目を削除しても、以前に入力し、記事に紐付けられているデータは残ったままなので、データベースから削除、またはプラグインを利用します。

これまた長らく更新されていないプラグインなので、下記ページからダウンロードしてインストールが必要です。
利用時には念の為サイトのバックアップを取っておきましょう。
Delete Custom Fields

「ツール」→「Delete Custom Fields」から、データを削除するカスタムフィールドを選択し、実行します。

記事に紐付けられていたカスタムフィールドのデータが削除されます。

最初の設計が肝心

如何でしたでしょうか？
ホームページの設計時に、カスタムフィールドとカスタムタクソノミーの特性を理解しておけば、このような作業は必要ありません。
・後でまとめて表示したいかも
・何回も使うかも
と思うような項目は、カスタムタクソノミーの利用を考えましょう。

引き継いだサイトの中には、繰り返されるセミナーの開催地や、採用ページの勤務地がカスタムフィールドとして設計されているサイトもありました。
つまり、管理画面から毎回毎回同じような住所を記入しなければならないのです。
このような場合は、カスタムタクソノミーで地名を選択式にしておき、連動する要素（住所、アクセス、地図）を自動で出し分ける方が運用が楽でしょう。
カスタムフィールドで選択式にしておく方法もあると思いますが、この場合「同じ会場で開催されているセミナー一覧」「同じ勤務地で募集している採用一覧」などの表示が面倒です。

これからサイトを作る場合は後々運用が面倒にならないように、慎重に設計しましょう。

投稿 カスタムフィールドで登録した情報をやっぱりカスタムタクソノミーに移行してみる は studioDoghands に最初に表示されました。

特殊な例なので参考になる人は少ないと思いますがメモ。
管理画面のカスタム投稿タイプ一覧に「Advanced Custom Fields」プラグインで作成したカスタムフィールド（日付:デイトピッカー）を表示。
更にその日付順で並べる、という作業を行いました。
問題無く反映されたと思いきや、サイト更新時に不具合が発生したので解決方法の記録です。

カスタムフィールドの項目を管理画面のカスタム投稿タイプの一覧に表示

※下記プロジェクトは簡易化したサンプルです。実際は複数のカスタムフィールドの列を追加しています。

カスタム投稿タイプ「イベント(event)」の一覧に、カスタムフィールド「年月日(event_date)」の列を表示する必要がありました。

まずは列を追加して
[php]
//『event』カスタム投稿にカスタムフィールド『event_date』の項目を追加
function add_column_to_event ( $columns ) {
$columns[‘event_date’] = "年月日";
return $columns;
}
add_filter( ‘manage_event_posts_columns’, ‘add_column_to_event’ );
</code>
[/php]

追加した項目に値（日付データ）を入れます。
[php]
//追加したカスタムフィールドの項目に値を表示
function add_column_value_to_event ($column, $post_id) {
switch ( $column ) {
case ‘event_date’ :
echo get_post_meta( $post_id , ‘event_date’ , true );
break;
}
}
add_filter( ‘manage_event_posts_custom_column’, ‘add_column_value_to_event’, 10, 2 );
[/php]

そして、カスタムフィールドで追加した日付順（降順）で並べます。下のような感じのコードになります。
[php]
//カスタム投稿『event』一覧を、カスタムフィールド『event_date』の降順で並べ替え
function set_post_types_admin_order_to_event ( $wp_query ) {
if (is_admin()) {
$post_type = $wp_query->query[‘post_type’];
if ( $post_type == ‘event’ ) {
$wp_query->set(‘meta_key’, ‘event_date’);
$wp_query->set(‘orderby’, ‘meta_value’);
$wp_query->set(‘order’, ‘DSC’);
}
}
}
add_filter( ‘pre_get_posts’, ‘set_post_types_admin_order_to_event’ );
[/php]

問題無く表示されました。

更新すると問題発生。日付形式が強制的に上書きされる

しかし、過去のデータを編集し、保存しなおしたところ問題が発生しました。

例えばカスタムフィールドで登録した日付「2018/09/01」の記事を修正、保存すると、日付は変更していないのにも関わらず、一覧では「20180901」と表示され、順番が狂ってしまうのです。

つまり、保存時に日付のフォーマットが強制的に書き換えられているということです。

原因。プラグインのアップデートによる仕様変更によるもの

そこで、Advanced Custom Fields公式ドキュメントの「Date Picker」を確認してみます。
https://www.advancedcustomfields.com/resources/date-picker/
冒頭から理由が記載されていました。
要約すると次のような感じです。

ACF(アドバンスドカスタムフィールド)の以前のバージョンには「保存形式（Save Format）」という設定が含まれていました。
この設定により、開発者はDBに保存されている形式を変更できました。
保存形式の指定は便利ではありますが、多くの問題を引き起こす為、新バージョンでは削除されました。
現在は「YYYYMMDD」を唯一の保存フォーマットとしています。
公式サイトより一部意訳

つまり、データベースには「2018/09/01」のフォーマットで保存されていても、新バージョンでは「20180901」で保存されるということです。

データベースをチェックしてみる

念の為phpMyAdminでデータベースを確認してみます。
カスタムフィールドのキーと値はpost_metaテーブルに入っています。

該当のカスタムフィールドで検索してみます。

有りました。更新済の記事のみ基本フォーマットで保存されています。一覧表示での順序の崩れの原因が確定しました。

旧バージョン（5以前）を確認

試しにプラグインダウンロードページで、旧バージョンのACFをダウンロード、確認してみます。適当にバージョン4.3.8をインストールしてみます。

なるほど、「フォーマットを保存する」の項目があります。覚えていませんが、恐らく以前ここでフォーマットを指定していたと思われます。

ちなみに最新バージョンは下記のような画面です。
※「Translation preferences」はマルチ言語プラグイン「WPML」によるもので、今回は無関係です。

修正する

「じゃあ全部新しい形式にする為に記事を保存し直せばよいか」と言いたいところですが、このカスタム投稿タイプには1500程度の記事が登録されていました。
元々、これらの記事はCSVから「Really Simple CSV Importer」を使って一気に読み込んだものです。

CSVを確認したところ、確かに「2018/09/01」形式（Y/m/d）で日付を記入しています。ソフトはLibreOfficeを使っています。

何らかの方法で記事をCSVに書き出し、日付を一気に修正、読み込み直す、という方法は記事IDの保持が面倒そうなので、データベースを書き換えることにしました。

データベースで日付を置換

phpMyAdminにログイン後、SQLタブを開きます。
「wp_postmeta」というテーブルの「event_date」キーにあるデータから、「/」を取り除きたい。つまり「2018/09/01」を「20180901」にしたい、というSQLクエリは下のように書きます。
[sql][/sql]update wp_postmeta set meta_value=REPLACE(`meta_value`,’/’,”) where meta_key = ‘event_date’;[sql][/sql]

無事に全て置換されました。

管理画面でもカスタムフィールドで指定した日付の降順で並んでいます。

日付の表示を修正

管理画面とはいえ、この日付フォーマットは少々味気ないのでY/m/d形式で表示することにします。

値を表示するコードを下記のように修正します。
[php]
//追加したカスタムフィールドの項目に値を表示。日付フォーマットも変更。
function add_column_value_to_event ($column, $post_id) {
switch ( $column ) {
case ‘event_date’ :
$date = get_post_meta( $post_id , ‘event_date’ , true );
$date = new DateTime($date);
echo $date->format(‘Y/m/d’);
break;
}
}
add_filter( ‘manage_event_posts_custom_column’, ‘add_column_value_to_event’, 10, 2 );
[/php]

表示形式が修正されました。

投稿 管理画面の一覧にカスタムフィールドのデイトピッカーを表示すると更新時に問題発生(解決済) は studioDoghands に最初に表示されました。

カスタムフィールドを追加/管理する定番WordPressプラグイン「Advanced Custom Fields」。
テキストや画像、投稿オブジェクトなど、様々なフィールドが使えます。
その中で「Wysiwyg エディター」の利用時の注意点について解説します。

カスタムフィールドの登録

このような感じでWysiwygエディターのフィールドを追加してみます。
フィールドタイプは「Wysiwygエディター」を選択します。

投稿画面で適当にテキストを入力します。

カスタムフィールドの表示

投稿表示用のテンプレート（通常はsingle.php）の[code]&lt;?php the_content(); ?&gt;[/code]
の下に、フィールド表示用のコードを追加します。
pタグで囲み、太字・赤文字で出力してみます。
[code]
&lt;?
$wysiwyg = get_field( ‘wysiwyg_test’ );//wysiwyg_testはフィールド名
if ( $wysiwyg ) {
echo ‘&lt;p class="font-weight-bold text-danger"&gt;’ . $wysiwyg . ‘&lt;/p&gt;’;//pタグで囲みクラスを追加
}
?&gt;
[/code]
結果を確認します。
テキストは表示されていますが、意図した装飾が反映されていません。

コードを確認すると、クラスを付与したpタグが閉じられ、新しくpタグが追加されてしまっています。

意図しないpタグの原因

カスタムフィールドを取得する関数「get_field」（表示はthe_field）には3つの引数があり、そのうちの1つが自動整形を担当し、デフォルトでは有効になっています。
これが意図しないpタグのクローズと追加の原因です。

「get_field」関数の引数

[code]get_field($selector, [$post_id], [$format_value]);[/code]
$selectorはフィールド名です。必須の引数です。
$post_idは投稿IDです。デフォルトでは現在の記事を取得するので、空白またはfalseで問題ありません。
投稿ID123の「text_field」を取得する場合は下記のように書きます。
[code]$value = get_field( "text_field", 123 );[/code]
$format_valueがコードの整形に関する引数で、デフォルトではtrueになっています。これが整形の原因です。

参考:公式ドキュメント

それでは上記を踏まえ、引数の2番目と3番目を「false」にしてコードを修正してみます。
[code]
&lt;?
$wysiwyg = get_field( ‘wysiwyg_test’,false,false );//wysiwyg_testはフィールド名
if ( $wysiwyg ) {
echo ‘&lt;p class="font-weight-bold text-danger"&gt;’ . $wysiwyg . ‘&lt;/p&gt;’;//pタグで囲みクラスを追加
}
?&gt;
[/code]

結果を確認します。
意図したとおり、クラスを付与したpタグで囲まれ、文字も装飾されました。
しかし、整形機能をオフにしたことで、今度は改行が無視されてしまいました。

改行を反映させる

改行を反映させるには、PHPの関数「nl2br」を使います。
参考:公式ドキュメント
この関数は、テキストの改行文字(\r\n、 \n\r、\n および \r) の前に
を付与して文字列を返します。
基本的は使い方は下記の通りです。
[code]echo nl2br(‘改行入りの文字列’);[/code]

「nl2br」を利用してコードを修正してみます。
[code]
&lt;?
$wysiwyg = get_field( ‘wysiwyg_test’,false,false );//wysiwyg_testはフィールド名
if ( $wysiwyg ) {
echo nl2br(‘&lt;p class="font-weight-bold text-danger"&gt;’ . $wysiwyg . ‘&lt;/p&gt;’) ;//pタグで囲みクラスを追加
}
?&gt;
[/code]

確認します。
無事改行が反映されました。

投稿 Advanced Custom Fieldsの「Wysiwyg エディター」の出力で挿入されるpタグを除去する は studioDoghands に最初に表示されました。