FileMakerでWordPress シリーズ記事の続きシリーズ、前回記事の続きというか、同じことも書いてますが概要からわずかに踏み込んでいます。
前回記事: その1概要
wp_postsを読み込む
リモートのwp_postsと接続します。
超基本的な接続
wp_postsはWordpressの中心的存在のテーブルです。これを中心に各データが繋がっています。とりわけ重要なのが「ID」です。このIDがリレーションを司ります。
すでに接続済みなのでテーブルを読み込みます。「リレーションシップ」タブのこの画面から下方「+」ボタンで読み込めます。
大雑把に言って、このwp_postsさえあれば基本は抑えられます。これだけでOKと言っても過言。
オカレンス
リレーションシップ画面に読み込んだテーブルを「オカレンス」と呼ぶそうです。
テーブルとオカレンス、いったい何のことでしょう。違いはあるんでしょうか。あります。
テーブルとはデータベースのテーブルそのものです。そのテーブルをリレーションで繋げるために「オカレンス」という存在として利用します。エイリアスみたいなもんかな。オカレンスはたくさん作れます。オカレンスを使って複数のリレーションを作れるということですね。この理解で合ってますか？違ったら御免。
FileMakerではリレーションシップタブ画面でこのオカレンスを自在に操り多種多様なリレーションを作ります。
私はこのオカレンスとリレーションについて当初認識不足でした。どういう認識不足だったかというと、オカレンスを使用したリレーションを「データベースの根底を司る力」だと思いすぎていたのです。どういうことかわかりますか？その認識でいたからですね、どうなったかというと、リレーション地獄になったのです。
リレーション地獄
テーブルが増えていくに従ってリレーションシップがねずみ算式に増えていったんです。目眩がするほど張り巡らされたリレーションの蜘蛛の巣地獄、ひとつ接続すれば必要な他の接続が5倍、1個が10個、10個が100個の悪夢のリレーションです。
「なぜこんなことになったのだ」とうなだれてFileMakerファイル（ソリューションというそうです）を捨ててやり直します。
これはひとえにFileMakerのリレーションに対する認識不足から来ていました。リレーションをくまなく網羅しようとすれば当然こうなります。「リレーションはデータ全体の根底を司る仕組み」なんかではなかったのですよ。レイアウトごとの表示するリレーションです。レイアウト内で使わないテーブルのリレーションなんかは基本不要なんですね、小さなリレーションをレイアウトに合わせて小規模に作っていくのが賢い人のやり方のようです。
最も単純なレイアウト
さて、もっとも簡単な編集ならこれだけで準備OK。このままレイアウトを作れば最低限の編集は出来ます。ひとつのテーブル、ひとつのオカレンス、そしてひとつのレイアウトです。
このレイアウトはリモートのフィールドをそのまま表示してるだけです。勝手に触ってはいけないようなフィールドもありますのでそういうのはレイアウトから消しておくのがいいかもしれません。
この状態で本文を修正したりタイトルを変えたりできます。スラッグや日付も変えることができます。検索や置換も容易いでしょう。ただし直接触るので事故の元になり兼ねません。接続中のリモートデータですから検索やソートも遅いです。
削除や新規に要注意
ちょっとした修正ならいいんですが、新規作成はIDの取り扱いに関わる重大ごとなので迂闊にやってはいけません。IDはWordpressかMySQLデータベースの賢い仕組みが陰で執り行うものですので、ユーザーが自由に操作出来ない部分です。新規ポストを作るときはそれなりの手順が必要になります（後に記事にします）
ローカルPostsテーブルを作る
読み込んだテーブルのデータを触るだけというのは、楽ちんですが危険だし遅いし、ローカルで編集してからリモートに反映させるということを目指すのもいいでしょう。
FileMakerの機能を使ってあれこれ創意工夫するにもローカルに何らかのテーブルがないと何もできません。ですから遅かれ早かれローカルにテーブルを作らねばなりません。
ローカルのテーブルに最低限必要なフィールドはIDです。IDでリモートとリレーションします。
そのほか、リモートの wp_postsと内容を合わせたフィールドを作っておくのも手ですね。たとえばローカルに本文を書いて最終的にリモートのcontentに送るとか、そんな安全な運営ができるでしょう。ローカルテーブルにどういうフィールドが必要か、ゆっくり考えながらやっていけばいいと思います。
で、最低限IDだけは要ります。すでに記事がたくさんあるなら過去記事のID全部ほしくなるかもしれません。もしローカルに既存のポストデータを全部読み込んでしまいたいならこうします。
リモートwp_postsからフィールドを「エクスポート」してそれをローカルテーブルにインポート
リモート接続したwp_postsテーブルをFileMaker形式でエクスポートします。これがそのままローカルpostsテーブルになります。ファイルが分かれたままでもいいし、統合したいのなら書き出したファイルをローカルpostsテーブルにインポートします。
これで、現時点でリモートとローカルで同じIDのpostsが揃いました。
ローカルに全くいらない不要なレコードもたくさんありますが（例えばauto-draftとかrevisionとか）そういうのは削除すればいいです。ローカルにまったく要らないフィールドも消しまくればいいですね。
超基本的なリレーション
ローカルとリモートwp_postsを「ID」でリレーションします。
これにより、レイアウトのデザインとしてこんな感じのものが作れます。これはIDだけがローカルのフィールドで、そのIDに紐付いた他のデータをリモートから配置している図です。
例ではIDだけがローカルデータです。他のフィールドが必要なら足していけばいいでしょう。必要なすべての項目がローカルにあれば作業自体は手軽で便利になるかもしれません。ただし、ローカルからリモートに送る、同期させるという作業が増えますから注意。
Postsのフィールド
テーブルwp_postsに含まれるフィールドをもう少し見ていきましょうか。
post_type
post_type はポストタイプです。投稿とか固定ページとかカスタム投稿とかそういうものですね。投稿なら「post」固定ページなら「page」です。attachmentっていうのもポストタイプです。画像などのメディアですわな。実は「メニュー」もポストタイプのひとつなんですよ。
ウェブ上のWordpressを触っているだけだと全く異なるものに見えますが実はポストタイプが違うだけで全部このwp_postsに収まっています。ポストタイプ以外に違いはないのだと、そういうことが判ると思います。
post_status
post_statusは「draft」（下書き）と「publish」（公開済み）などステイタスを司っています。大事です。下書きと公開済みの他「自動保存」や「ゴミ箱にある」「プライベート（非公開）」なんかもあります。
ローカルでWordpressデータを編集するに当たっては、ポストタイプとステイタスのふたつがどういう状態なのかが重要となります。
FileMakerでは「条件付き…」とメニューコマンドがあって、それを使って視覚的に判りやすいデザインを作れます。例えば「post_statusがdraftならフィールドを水色に塗りつぶす、publishなら紫色に」みたいな。
これにより、ぱっとレコードを開いただけでポストタイプや状況が色で明らかになるという、ちょっと工夫してフィールドをでっかく取ったりするとこんな感じの見え方にも出来ます。
あと、この部分はFileMakerからリモートデータを直接変更しても問題ありません。下書きを完成させてpost_statusに「publish」と入力するとあら不思議、瞬時に公開されています（不思議でも何でもないが）。ポストタイプの変更も一発ですね。「変更」に関してはいろいろ楽ちんにできます。
post_name
post_nameはスラッグのことです。関数やタグを弄ってる人には自明ですね。これを変更するとURLが変わってしまいます。
日付、著者
作成日付、更新日付などのタイムスタンプもwp_postsのフィールドです。post_modified、post_modified_gmtの違いは地域の時間帯です。日本だと9時間加算されています。_gmt のほうが加算前ですね。
著者はpost_authorで、著者のIDが格納されます。
post_content / post_excerpt
言わずとしれた本文と抜粋です。抜粋も同時にwp_postsにあるんですね。
post_excerptはなぜか「入力必須項目」となっていて、リモートのpostsテーブルを弄ってると突然「post_excerpt は必須です！」とダイアログで叱られたりします。何だか面倒臭いので、そういう意味でも普段の作業はリモートをベースにするより、ローカルテーブルをベースにしたほうがいいのかなと思ってます。
post_parent
意外と重要なpost_parentがあります。これは「親」です。固定ページに親子関係ありますね。「この記事の親はこれですよ」という親のIDがこのフィールドに入ります。
attachment（添付メディア）もpostsであると言いましたね。そのメディアのレコードデータにはpost_parentに該当ポストのIDが記されます。どのポストに紐付いたメディアなのかということです。
該当記事がない読み込んだだけの画像があったとしますね。ポストに紐付いていないとpost_parentは0になっています。ここに目的の記事IDを入れてやれば、その記事と画像が紐付けできるという案配です。
というような、他にもいくつかフィールドありますが、取りあえずこんな感じで。
次の記事に続きます。次はWebビューアです。
FileMakerでWordPress Webビューアを使う
