FileMakerでWordPress 基本的な編集

大枠 FileMakerでWordPress シリーズ記事の続きシリーズ、前回記事 その1概要 の続きというか、同じことを書いてますが概要からわずかに踏み込んでいます。

広告

wp_postsを読み込む

リモートのwp_postsと接続します。

超基本的な接続

wp_postsはWordpressの中心的存在のテーブルです。これを中心に各データが繋がっています。テーブルの中にはタイトルや日時や筆者、本文などのフィールドがあります。とりわけ重要なのが「ID」です。このIDがリレーションを司ります。

リレーションシップタブからリモートのPostsを読み込んだところ
リレーションシップタブからリモートのPostsを読み込んだところ

すでに接続済みなのでテーブルを読み込みます。「リレーションシップ」タブのこの画面から下方「+」ボタンで読み込めます。

大雑把に言って、このwp_postsさえあれば基本は抑えられます。これだけでOKと言っても過言。

オカレンス

リレーションシップ画面に読み込んだテーブルを「オカレンス」と呼ぶそうです。

テーブルとオカレンス、いったい何のことでしょう。違いはあるんでしょうか。あります。

テーブルとはデータベースのテーブルのことです。そのテーブルをリレーションで繋げるために「オカレンス」という存在として利用します。エイリアスみたいなもんかな。オカレンスはたくさん作れます。オカレンスを使って複数のリレーションを作れるということですね。この理解で合ってますか?違ったら御免。

FileMakerではリレーションシップタブ画面でこのオカレンスを自在に操り多種多様なリレーションを作ります。

私はこのオカレンスとリレーションについて当初認識不足でした。どういう認識不足だったかというと、オカレンスを使用したリレーションを「データベースの根底を司る力」だと思いすぎていたのです。どういうことかわかりますか?その認識でいたからですね、どうなったかというと、リレーション地獄になったのです。

リレーション地獄

テーブルが増えていくに従ってリレーションシップがねずみ算式に増えていったんです。目眩がするほど張り巡らされたリレーションの蜘蛛の巣地獄、ひとつ接続すれば必要な他の接続が5倍、1個が10個、10個が100個の悪夢のリレーションです。
「なぜこんなことになったのだ」とうなだれてFileMakerファイル(ソリューションというそうです)を捨ててやり直します。

リレーションやりすぎ
ほんの一角。こんなのが倍々で増えていくのでした

これはひとえにFileMakerのリレーションに対する認識不足から来ていました。リレーションをくまなく網羅しようとすれば当然こうなります。「リレーションはデータ全体の根底を司る仕組み」なんかではなかったのですよ。レイアウトごとの表示するリレーションです。レイアウト内で使わないテーブルのリレーションなんかは基本不要なんですね、小さなリレーションをレイアウトに合わせて小規模に作っていくのが賢い人のやり方のようです。

最も単純なレイアウト

さて、もっとも簡単な編集ならこれだけで準備OK。このままレイアウトを作れば最低限の編集は出来ます。ひとつのテーブル、ひとつのオカレンス(この一個は自動で作られたもの)、そしてひとつのレイアウトです。

ベーシックレイアウト

このレイアウトはリモートのフィールドをそのまま表示してるだけです。勝手に触ってはいけないようなフィールドもありますのでそういうのはレイアウトから消しておくのがいいかもしれません。

この状態で本文を修正したりタイトルを変えたりできます。スラッグや日付も変えることができます。検索や置換も容易いでしょう。ただし直接触るので事故の元になり兼ねません。接続中のリモートデータですから検索やソートも遅いです。

削除や新規に要注意

ちょっとした修正ならいいんですが、新規や削除は危険です。IDの取り扱いに関わる重大ごとです。Wordpressの奥底の賢い仕組みがあれこれ執り行うものですので、データベースを直接触るのはよほどの達人じゃない限り危険ですから、詳しくないならやめといた方が身のためです。

ローカルPostsテーブルを作る

読み込んだテーブルのデータを触るだけというのは、楽ちんですが危険だし遅いし、ローカルで編集してからリモートに反映させるということを目指すのもいいでしょう。

FileMakerの機能を使ってあれこれ創意工夫するにもローカルに何らかのテーブルがないと何もできません。ですから遅かれ早かれローカルにテーブルを作らねばなりません。

ローカルのテーブルに最低限必要なフィールドはIDです。IDでリモートとリレーションします。

そのほか、リモートの wp_postsと内容を合わせたフィールドを作っておくのも手ですね。たとえばローカルに本文を書いて最終的にリモートのcontentに送るとか、そんな安全な運営ができるでしょう。ローカルテーブルにどういうフィールドが必要か、ゆっくり考えながらやっていけばいいと思います。

で、最低限IDだけは要ります。すでに記事がたくさんあるのなら、過去記事のID全部ほしいです。ですのでこうします。

リモートwp_postsからフィールドを「エクスポート」してそれをローカルテーブルにインポート

wp_postsからIDだけをエクスポートして、それをローカルのテーブルに読み込みます。

wp_postのレイアウトでファイルメニューから「エクスポート」を選んで、書き出すフィールドでIDを選びます。他のフィールドを追加で選んでもいいと思います。形式はFileMaker形式が楽でしょう。書き出します。

ローカルにテーブルを作ってからそれを読み込んでもいいのですが、何もせずに「インポート」を選んでから読み込み画面で「新規テーブル」を選んでも良いでしょう。読み込みます。

これで、現時点でリモートとローカルで同じIDの記事数が揃いました。

ローカルに全くいらない不要なレコードもたくさんありますが(例えばauto-draftとかrevisionとか)そういうのはあとで消せばいいです。

※ あえてまとめて消すのも面倒なので、私はスクリプトトリガで「今開いたこのIDのレコードが不要ならローカルのこのレコードを削除する」って感じのスクリプトを仕込んでます。明らかに不要というのは、post_statusが「trash」「auto-draft」post_typeが「revision」などです。

超基本的なリレーション

ローカルとリモートwp_postsを「ID」でリレーションします。

IDでRelation
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_parent

意外と重要なpost_parentがあります。これは「親」です。固定ページに親子関係ありますね。「この記事の親はこれですよ」という親のIDがこのフィールドに入ります。

attachmentもpostsであると言いましたね。ポストに含まれる添付画像です。その画像のレコードデータにはpost_parentに該当ポストのIDが含まれるということです。なるほどよく考えられています。

該当記事がない読み込んだだけの画像があったとしますね。post_parentに何らかの記事IDを入れてやれば記事と画像が紐付けできるという案配です。

というような、他にもいくつかフィールドありますが、取りあえずこんな感じで。これらフィールドをローカルに作ってスクリプトで同期させてもよし、リモートのまま表示するもよしです。

次の記事に続きます。次はWebビューアです。
FileMakerでWordPress Webビューアを使う

広告
FileMakerでWordPress / FileMakerでWordpress編集
カテゴリーソフトウェア, WordPressタグ
このエントリーをはてなブックマークに追加

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください