FileMakerでWordPressを編集するシリーズ、今回はカスタムフィールドについてです。
カスタムフィールド postmeta
カスタムフィールドのテーブルは postmeta です。
このテーブルはpostsのIDで照合され、ポストとの繋がりが密接です。というかポストに直接紐付けされた追加データでメタ情報だからシンプルなのも当然です。
- post_id： 連携するポストのIDです
- meta_id： postmetaの固有のidです
- meta_key： キー、項目名というか分類というか、キーです
- meta_value： バリュー、キーに対する値です
これをFileMakerで扱うとき、wp_postsテーブルのIDとpost_idを照合してリレーションするだけで事足ります。
新規カスタムフィールド
ポストに紐付く新規のカスタムフィールドを作るのは何の苦労もありません。IDとpost_idで繋げたリレーションを作って、postmetaのほうに「レコードの作成を許可」しておき、これをpostsレイアウトにポータルで表示させます。keyとvalueを入力すれば勝手に新規カスタムフィールドが作成されます。
単数と複数
postmetaのデータには単データと複数データがあります。単データか複数データかというのは大きな違いで、php的にも必ず「配列」で制御するなど、異なる処理になりますよね。FileMakerで管理する上でも、ポータル表示やスクリプトの処理が変わってきたりします。
例えばですね、特定のkeyだけを表示するポータルがあったとして、単データなら一行、複数データなら複数行になります。スクリプトで既存データの有無をチェックしたり、空なら新規作成したり、そういうことを行うとき必ず1行であるのか複数行の可能性があるのかによって条件の指定が変わってきますよね。複数行のときはチェックする if や ポータルの行移動についての記述がだらだら長引いたりします。
keyに対する値がただ一つのメタデータ
postmetaのあるkeyに対するvalueが単データの場合、運用やスクリプト作成はとても簡単なものになります。シンプルにことが済むでしょう。もしローカルにpostテーブルを作ったりしてローカルでの構築をしているような場合だと、ローカルのpostテーブル内にフィールドとして組み込んだって構わないのです。
例えばカスタムフィールド「誕生日」なんて項目があったとしますね。postmetaテーブルのデータですが、ローカルのテーブルの中に「誕生日」というフィールドを作ってもいいってことです。
わざわざローカル環境など作っていない場合はポータルフィルタを使って一行のみのポータルで表示させたりします。
一意のkeyのみを一行だけ表示することが決まっているポータルの場合、自動化のためのスクリプト作成が何かと楽ちんになります。
複数の値があり得るメタデータ
複数の値があり得る場合は、ローカルだろうがリモートだろうがidなり何なりで照合してポータルに行表示することになります。ポータルフィルタで工夫したり、自動化のスクリプトで利便性を高めたり、いろいろやります。単データと違って、これをわざわざローカルに作成する意味はあまりありません。
ポータルには複数の行を表示させることになります。
ポータル表示
カスタムフィールドをFileMakerで運用するとき、postmetaテーブルをポータルに表示します。
ポータルは別のテーブルから関連レコードを引っ張ってきて表示できる機能で、ポータルフィルタにいろいろ書くと表示内容をコントロールできます。
wp_postmeta::meta_key = “一意のkey”
例えばこんなふうに書くと、ある特定のkeyを持つレコードだけを表示できますね。
フィルタを駆使してポータル表示を行い、カスタムフィールドの入力や確認を便利に行うことができます。FileMakerで表示させるカスタムフィールドのポータルは、うまく使えればウェブ上のWordPress編集画面より見やすくて使い勝手もよくなります。
この図はカスタムフィールドやタクソノミーのポータル表示の例です。ここでは、フィルタをガチガチに設定して、一つのポータルにただ一つのデータを表示するようにしています。
次の図は複数のkeyとvalueをリスト表示するように設定した例です。
こんな感じで表示を切り分け、入力や確認で楽ができるように工夫しております。
ポータル表示のコントロールは曲者で、ちょっと思うようにいかないこともありますし難しいんですけど、うまく付き合えればとても操作しやすい画面を作ることが出来ます。
カスタムフィールドは扱いが楽
ということでカスタムフィールドのことをさらりと書いておきました。
カスタムフィールドはpostmetaテーブルだけで成り立っており、postのIDと照合されるシンプルな作りです。
新規レコードでkeyとvalueを入力すれば自動でmeta_idが生成されるし、WordPressのPHP的に運用上大きな問題が起きることもありません。
FileMakerで管理しだしてから、カスタムフィールドの便利さ、同時にtaxonomyのややこしさに触れてしまい「こんなことならtaxonomyでやってるこっちのデータも全部カスタムフィールドにしておけば良かった」なんて思いました。
以前、CSVファイルを介してWordPressを管理しようとしていたときは逆でした。taxonomyなら楽でカスタムフィールドの扱いがややこしかったのです。このとき、カスタムフィールドでやっていたことの多くをtaxonomyに変更してしまったんですよね。・・・迂闊なことをしたもんだと後悔しています。
