続きというか、同じことも書いてますが概要からわずかに踏み込んでいます。post_parentwp_postsを読み込むリモートのwp_postsと接続します。超基本的な接続wp_postsはWordpressの中心的存在のテーブルです。これを中心に各データが繋がっています。重要なのが「ID」です。このIDがリレーションを司ります。リレーションシップタブからリモートのPostsを読み込んだところすでに接続済みなのでテーブルを読み込みます。「リレーションシップ」タブのこの画面から下方「+」ボタンで読み込めます。大雑把に言って、この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に紐付いた他のデータをリモートから配置している図です。例ではIDだけがローカルデータです。他のフィールドが必要なら足していけばいいでしょう。必要なすべての項目がローカルにあれば作業自体は手軽で便利になるかもしれません。ローカルからリモートに送る、同期させるという作業が増えますから注意。Postsのフィールドテーブルwp_postsに含まれるフィールドをもう少し見ていきましょうか。投稿とか固定ページとかカスタム投稿とかそういうものですね。投稿なら「post」固定ページなら「page」です。attachmentっていうのもポストタイプです。画像などのメディアですわな。実は「メニュー」もポストタイプのひとつなんですよ。ウェブ上のWordpressを触っているだけだと全く異なるものに見えますが実はポストタイプが違うだけで全部このwp_postsに収まっています。ポストタイプ以外に違いはないのだと、そういうことが判ると思います。post_statuspost_statusは「draft」(下書き)と「publish」(公開済み)などステイタスを司っています。下書きと公開済みの他「自動保存」や「ゴミ箱にある」「プライベート(非公開)」なんかもあります。ローカルでWordpressデータを編集するに当たっては、ポストタイプとステイタスのふたつがどういう状態なのかが重要となります。FileMakerでは「条件付き...」とメニューコマンドがあって、それを使って視覚的に判りやすいデザインを作れます。「post_statusがdraftならフィールドを水色に塗りつぶす、publishなら紫色に」みたいな。これにより、ぱっとレコードを開いただけでポストタイプや状況が色で明らかになるという、ちょっと工夫してフィールドをでっかく取ったりするとこんな感じの見え方にも出来ます。レコードを開くとタイトル周りの色が目に入るレイアウトデザインにしていますあと、この部分はFileMakerからリモートデータを直接変更しても問題ありません。下書きを完成させてpost_statusに「publish」と入力するとあら不思議、瞬時に公開されています(不思議でも何でもないが)。ポストタイプの変更も一発ですね。「変更」に関してはいろいろ楽ちんにできます。post_namepost_nameはスラッグのことです。関数やタグを弄ってる人には自明ですね。タイムスタンプもwp_postsのフィールドです。post_modified、post_modified_gmtの違いは地域の時間帯です。日本だと9時間加算されています。著者はpost_authorで、著者のIDが格納されます。post_excerpt言わずとしれた本文と抜粋です。抜粋も同時にwp_postsにあるんですね。必須です!」とダイアログで叱られたりします。何だか面倒臭いので、そういう意味でも普段の作業はリモートをベースにするより、ローカルテーブルをベースにしたほうがいいのかなと思ってます。post_parent意外と重要なpost_parentがあります。固定ページに親子関係ありますね。「この記事の親はこれですよ」という親のIDがこのフィールドに入ります。attachment(添付メディア)もpostsであると言いましたね。そのメディアのレコードデータにはpost_parentに該当ポストのIDが記されます。どのポストに紐付いたメディアなのかということです。該当記事がない読み込んだだけの画像があったとしますね。ポストに紐付いていないとpost_parentは0になっています。ここに目的の記事IDを入れてやれば、その記事と画像が紐付けできるという案配です。いうような、他にもいくつかフィールドありますが、取りあえずこんな感じで。次はWebビューアです。コメントデータの処理方法の詳細はこちらをご覧ください。[Amazon]執筆者のCDです。