FileMakerでWordPressを編集 その1 概要

FileMaker ProとWordpressを接続するお話を書いてきて、最終的にFileMakerからMySQLサーバーに直結してしまうところまで行きました。しかしもちろんそれで終わりではありません。それは始まりにすぎません。FileMakerでどのようにWordpressの編集を効率化していったか、自分の備忘録のためだけにまた書き進んでいこうという新連載です。

Digital Boo Pennguin Icon

前提として、SSH接続を迂回してFileMaker ProからMySQLサーバーに接続できている状態です。これが前提でない場合は過去の記事を参照してください。
WordPressとFileMaker Proの接続メニュー(このページの最下部)

リモートと接続してFileMakerで運用

リモートのテーブルと接続するには、FileMakerの 管理 > データベース からリレーションの画面を開いて下方左のボタンをクリックします。

各テーブルをリレーション

データベース管理、リレーションタブ
データベース管理、リレーションタブ

まずは基本となる_posts、必要に応じて、_postmeta, _term_relationships, term_taxonomy, termsなどを同様に接続します。それからリレーションを設定しますね。

主要なテーブルを繋げたところ
主要なテーブルを繋げたところ

これでテーブルと接続されており、テーブル内のフィールドにもすべてアクセスできます。

使いやすいレイアウトを試しに作る

FileMaker Proの楽しいところはレイアウトを自由に作れるところです。この状態でもレイアウトを使いやすく作ることでコンテント(本文)の修正など簡単なことは十分賄えます。

postsのフィールド
postsのフィールド

postsではこんな感じで、例えば別のレイアウトを作るとすれば、大事なpost_type、post_status、post_title、post_name(スラッグ)なんかを判りやすく配置して、post_contentを大きめテキストボックスなんかにすると使いやすいかもしれません。

postsレイアウトの例
postsレイアウトの例

「書式」>「条件付き」から、フィールドの値によって色を変えたりもできますから、例えばpost_typeがポストの時、ページの時、attachmentのとき、といった条件をつけて色を変えると視認性が上がったりします。

ここからの使いやすいレイアウトや便利な自動化の遊びも楽しいものになりますがとりあえず置いといて話を先に進めます。

 

MySQLのテーブルとローカルテーブルの計画

MySQLの各テーブルに接続するとちゃんとこのように読み込めますしデータに手を入れたり変更を施したりできます。ただしリモートのデータですから速度がのろいです。数万件のデータがあったりした日にはソートや絞り込みも随分待たされますし、あまり快適環境とは言えません。

そこでもう一歩踏み越えて工夫をするわけです。どんな工夫をするのか、その目的は何なのか。こうです。

基本ローカルデータで編集し、ある程度まとめてリモートに送る仕組みを目指す

これを目指したいところです。基本的にはローカルデータで編集をさくさく行って、ある程度まとまってからリモートに送る、あるいはリモートに同期させる仕組みを作りたいわけです。

もちろんこれは使う人がどのように使いたいかによります。ローカルデータをわざわざ用意してリモートに送るほうが面倒だと考える人もおられましょう。

リモート編集の弊害

リモートデータを直接編集するのは速度が遅いだけでなく他にも弊害があります。システム的に勝手に変更してはならない部分がたくさんありますし、何より致命的なのはタクソノミーやポストメタなどをポストに紐付けるリレーションを手動で勝手に作ってはいけないからです。

例えば新規ポストを作ったときにそのIDを好きな数字にするなんてできませんし、カテゴリーやアイキャッチ画像をポストに登録したくても外部からリレーションを作成することなんかできません。

*厳密にはそれを行う方法がありますが、それはまたいずれ。

これらはWordpressの仕組みの根っこの部分で自動的に処理される部分で、データベースのデータだけを直接触ってしまうと破滅的な結果になりかねません。

私がFileMakerで管理しようとしているのは主にMovieBooのサイトですが、カスタムフィールドやタクソノミーをかなり多用していて、その基礎的入力の部分がウェブからだとめちゃくちゃ面倒臭いんです。これを簡素化したいがためにFileMakerを引っ張り出して苦労してリモートに接続したわけなんです。

そんなこともあって、後々あれこれと悩むことにもなりますがまず第一歩としてローカルデータを用意するというところから始めることにします。

ローカルデータを用意する

ローカルのテーブルをどのように作るのか、フィールドをどうするのか、これらはシステムを作っていく中で何度も試行錯誤を続けました。何が最良なのか答えはありませんし使う人の好き好きというか必要性を元に考えていくことですので一律の答えなんかありません。

それでもまず思いつくのは最も重要なテーブルであるpostsですね。wp_postsというテーブル名でしょうか、これがやっぱ基本のキとなります。

posts

すでにテーブルのデータをFileMakerに取り込むことをやりました。そのデータを使います。作業開始時点でリモートのpostsテーブルとローカルのpostsテーブルは同じデータを持っているという前提になりますね。同じものってことです。こういうのを使うと当面便利ではないでしょうか。

まずはローカルテーブルとリモートテーブルをIDで照合するリレーションを組んでおきましょう。これが基本の形となります。

ID照合のリレーション
ID照合のリレーション

このリレーションの設定、ひもで繋がった真ん中のところをクリックして設定しますが、このとき双方ともデータの作成を許可しておきます。

カスタムフィールドとタクソノミー

さて問題はカスタムフィールドとタクソノミーです。

考え方として、MySQLと同じテーブルを用意するという手もあります。

同じ構造では上手くいかない

posts、postmeta、relationships、taxonomy、termsですね。同じ構造にするのが簡単です。でもそれでは上手く行きません。

何が上手く行かないかというと、新規でカスタムフィールドやタクソノミーを設定していくことです。

ローカルでポストにメタデータをつけ加えると、リレーションしているテーブル側でレコードを新規作成することになります。このときメタデータ側のIDがリモートと合わなくなります。

リモート、つまり通常のWordpressを使ったメタデータ付加の際に振られるIDはWordpressやMySQLの都合で決定されるIDです。ローカルではFileMakerの設定によってIDが振られます。合わなくて当然ですね。

構造を無視した別の仕組み

そこで、別の仕組みを作りました。別の仕組みを作るにあたって、もともとの構造から大きく逸脱することを思いつきます。本来なら元の構造を生かしつつ、最良の方法を考えるのが筋ですがそうはしませんでした。

なぜかというとローカルデータにとって、というか私の頭の中では、カスタムフィールドとタクソノミーに違いがないからです。

仕組み的には大きく異なりますが、根本的にその違いがわかっておらず、意味合い的には同じものとして扱っているんです。私もしかしてとことんアホなんでしょうか。

単数か複数か

カスタムフィールドとタクソノミーの違いよりもっと大きな違いがあります。それは、データが複数か単数かです。こっちの違いのほうがよほど大きいんです。

例えば映画の記事があります。MovieBooではカテゴリーを公開年にしています。公開年ですから記事につきその値はただ一つです。公開年がないということもありませんし複数の値があることもあり得ません。記事の中でカテゴリーは例外なくただ一つの値を持ちます。

製作国はどうでしょうか。アメリカ製日本製スペイン製イラン製、いろいろありますね。フランス・ルーマニア合作なんてのもあります。つまり複数の値が存在します。値が存在しないということはあり得ません。必ずどこかで作られたものだからです。MovieBooでは製作国をタクソノミーに設定しています。

脚本やプロデューサーや出演者はどうでしょう。こちらも複数の存在があり得ますね。MovieBooではカスタムフィールドにこうしたクレジットを割り当てています。記事の中で値が存在しない場合も多々あるからです。実際には存在していてもすべてを表記しているとは限らないんですね。記事的に重要度が低いと言うか。

と、そんなこんなで、カスタムフィールドかタクソノミーか、その違いは「記事の中に必ずその分類が含めるか、含めない場合もあるか」てなことを基準に分けていますが、そのいい加減な分け方はともかく、ここでは「値が一つか、複数があり得るのか」がとても重要になります。

ローカルならではの簡略化を行う

値が一つの場合、それがカスタムフィールドであろうがタクソノミーであろうが、意味合い的には「記事の中のただ一つの何か分類の値」であります。これが何を意味するのか、それはこうです。

リレーションしなくてもローカルポストテーブル内のフィールドでいいんじゃない?

MySQLのテーブル構成に捕らわれずに考えてみれば、記事内の「タイトル」や「日付」や「ポストタイプ」なんかと同じ扱いでいいんじゃないかと気づきます。おお。これは目から鱗。

それに気づいた私はローカルpostsのテーブルに、おもむろに必要な分類名をフィールドとして作り足していくのでした。

MovieBooの例で言えば「公開年」「観た日付」「ふりがな」「原題」「オフィシャルサイトのURL」などなどです。ローカルposts内にがんがんフィールドを追加していきました。

後には、他のテキストフィールドやスクリプト用のフィールド、メモや画像用の何か、その他その他と、フィールドが際限なく増えてくる羽目になりました。

ローカルpostsは最早postsではなくローカルEDITのセンター司令塔と化したわけです。

ほんというと司令塔になったのはシステムを作り始めて随分あとです。その前はすべての値をこの後出てくるBridgeというテーブルで管理していました。でも値が1個なのにそんなの不要じゃね?と気づいてこうなったといういきさつがあります。

*厳密には値が単数か複数かというのとは別の基準を設けることになりました。その話はまたいずれ。

複数の値を持つ分類

複数の値を持つ分類をどうするのか。これもMySQLの構造を無視することにしました。カスタムフィールドもタクソノミーもひっくるめて、複数の値を持つ可能性のあるデータを「Bridge」とカッコ良く名付けた新規テーブルに収束させます。

Bridgeの役割はポストに関連する各種分類の総保管庫となります。MySQLでいうとpostmetaとtaxonomy関連を合体させたような完全に独立したテーブルです。

Bridge 例
Bridge 例 こんな画像出しても意味ありませんがこんな感じってことで

実はこのBridgeとカッコ良く名付けたテーブルについてはいろんな問題も山積して、後に一筋縄ではいかぬことになってしまったのですが今はまだその件については考えないふりをしてとりあえずの方向性として結論づけておきます。

Bridgeテーブルにはカスタムフィールドとタクソノミーの合体したデータが羅列されますが、これをどのように使うのかというとこうします。

ポータル用です

FileMakerの真骨頂、ポータルです。昔は「繰り返しフィールド」でした。

FileMakerにリレーションの機能が追加されたとき、繰り返しフィールドを置き換えるよう奨められました。しかし当時は意味がわからず「繰り返しフィールドのほうが簡単やん」と、何の処置もせずにおりました。実際繰り返しフィールドのほうが簡単です。

でも繰り返しフィールドは繰り返し数を指定したら全レコードがそれに準じなければならないとか、制約もあってやっぱりポータルのほうがいいということになりました。そんなこんなで、複数の値を持つフィールドはすべからく別テーブルを用意してポータルで取り入れることになります。

カスタムフィールドとタクソノミーも、その値が複数になる可能性があるなら、すべてポータルでレイアウトに配置します。

Bridgeにどうやってデータを入れたのか

はて。今になって思い返せば、どうやってデータをインポートしたんでしょう。何だか忘れてきています。備忘録を書くのが遅すぎたか。

多分、最初はpostsと同様にリモートと同じ構造のテーブルをダウンロードしてテーブルを作り、それを元にしてBridgeにインポートしたかルックアップしたような気がします。

Bridgeのフィールドにはpostmeta、term_relationships、term_taxonomy、termsのフィールドをもれなく設置し、それぞれIDを照合しつつがんがん取り込んだような記憶が。多分そうですね。多分そうやったはずです。

WordPressのテーブルはよく考えられていて、無意味にテーブルが別れているのではなく効率的にリレーションされていますね。これをわざわざ解体してすべて別レコードとしてBridgeに取り込んだものですから、どうなったかというとBridgeのレコード数が膨大になりました。当然そうなりますね。効率よくまとめられていた元のデータをバラして一個ずつにしたわけですからね、一気に数万レコードに達しました。

ただ、ローカルデータですからそれでも動作は軽いんです。無駄に容量食っていますが気になるレベルでもありません。

Bridgeのややこしさは実は筆舌に尽くしがたい大変なことになってくるんですがここではまだ細かく書くのを控えておきます。とりあえずカスタムフィールドとタクソノミーをまとめてBridgeというテーブルをこしらえたのだということだけ伝わればいいかなと。

 

ポータルをレイアウトに配置する

さて実際にポストの中にBridgeからポータルをレイアウトしてみましょう。

ポータルのボタンをクリックしてレイアウトの中にがーっと入れます。リレーションのテーブルを選択する画面からBridgeを選んで必要なフィールドを置きますね。

portal設置例
portal設置 例 また必要もない例です。ポータルがたくさん設置してあります。

ただ設置しても、ポストの中でたくさんのBridgeを上手に配置できませんから少し工夫をします。

ポータルの「フィルタ」を利用するんです。

portal設定

ポータル設定を開いて、フィルタを指定します。

portal計算式

こんなふうに計算式でフィルタを指定すると、ポータル内に必要な項目だけ表示されます。

計算式の例では「ジャンル」ですね。ラベルフィールドが「ジャンル」である値を表示するよう計算式に入れています。これでポータルの中でジャンルだけ表示させることができました。

こんな感じでがんがんポータルを使います。フィルタやソートも駆使しましょう。インスペクタの表示・非表示のコントロールや、条件付きやいろんな機能を駆使してあなただけの使いやすいレイアウトを作ってください。

ポータルのちょっとした弱点は、自動化のスクリプトが面倒臭いことになることです。単独のフィールドみたいに簡単にはいきませんね。いろんな可能性を考慮に入れた長ったらしいスクリプトが必要になってきます。そういう話はまたいずれ。

データをリモートに送る

ということでいよいよこれですね。ローカルで編集したデータをリモートに送りたいわけです。

本日の記事、最初のほうに見出しをつけたように、ローカルで編集したデータをリモートに送ることを目指すという内容のはずですが、実際にリモートに送る記事はまた後日になります。

本日はただ目指しただけという、目指したのでそのための下準備を果たしたという、そういう内容になりました。だってリモートに送るって、意外と躓くんですもの。内容も複雑になりますし。

具体的にはまたいずれ。

 

ここまでこれをしました

ということで本日まずはリモートに接続して各テーブルを繋げました。

次にリモートポストをダウンロードしたデータのローカルポストテーブルを作りリモートとリレーションしました。

カスタムフィールドとタクソノミーについては単数の場合postsに、複数の場合Bridgeという新規テーブルに集めました。

ポストにポータルとしてBridgeデータを配置したりもしました。

こういった事柄が概要となります。実は例外があったりいろいろ複雑なんですが概要としてこんな感じで。

これ以降は、複雑怪奇なBridgeについて、カスタムフィールドとタクソノミー(Bridge)をリモートに送る取り扱いについて、それからFileMaker Proの楽しいレイアウト機能や自動化にまで話を広げられればいいなと考えていますがこれからこの時期はちょっと身動きできなくなる多忙期故次回の更新はいつになるやらわかりません。

 

 

コメントを残す