FileMakerでWordPressを編集 – 概要

FileMaker ProとWordpressを接続するお話を書いてきて、最終的にFileMakerからMySQLサーバーに直結してしまうところまで行きました。しかしもちろんそれで終わりではありません。それは始まりにすぎません。FileMakerでWordpressの編集を実際に行っていきます。

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

すでにFileMakerでMySQLサーバーに接続済みの状態です(接続については FileMakerでWP MySQL接続  )ここから個々のテーブルと接続します。

WordPressのテーブル構造はWordPress CSVエクスポートインポート、そしてデータベース構造にも書きました。Codexページにも詳しく載っています。

リレーションシップタブからテーブルに接続

まずは基本となるwp_postsと接続しましょう。

posts読み込み

超基本的にはこれだけでOKです。postsテーブルがあれば、タイトル、スラッグ、本文、抜粋、日付などが編集できます。

必要に応じて、_postmeta, _term_relationships, term_taxonomy, termsなどを同様に接続し、リレーションを設定します。こんな感じになります。

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

ポストにカスタムフィールドとタクソノミーをリレーションしました。これでテーブル内のフィールドにもすべてアクセスできます。

これを元にローカルにテーブルを作って繋げたりリレーションを組み合わせたりしていきながら、自分にとって便利で有用なシステムが作っていけることでしょう。

用語の確認

ここで用語の確認ですが、データベースにはテーブルというものがあります。テーブル内にはフィールドというものがあります。個々のデータはレコードと言います。

wp_postsというのがテーブル、その中の例えばpost_contentがフィールド、実際のpost_contentの中身はレコードと。そんなところです。ネット越しに接続したものを「リモート」パソコン内のデータを「ローカル」と使い分けます。

FileMakerのリレーションシップ画面に出てくるグラフィカルなテーブルはオカレンスと言います。テーブルをオカレンスとして並べたり繋げたりするということで、ひとつのテーブルに複数のオカレンスを持たせられます。いまいちよくわかりませんがテーブルのエイリアスみたいなものかと思ってます。

FileMakerのレイアウトデザイン

FileMakerの特徴はレイアウトデザインにつきます。自由にデザインできる便利さ楽しさもありますが、レイアウトはテーブルオカレンスと直結しておりまして、作成した自由自在なリレーションをレイアウト内に配置して連携作業を効率良く行えます。

さてリモートのwp_postsに接続しました。テーブルwp_postsのレイアウトは例えばこんな感じになっています。ただフィールドを並べただけの状態です。

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

フィールドの置き場所やサイズを工夫すると例えばこんなふうに本文と抜粋を修正するためのレイアウトデザインができあがりますね。

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

一覧のしやすいデザイン、本文修正用、いろいろ確認用、レイアウトはいくらでも作れます。「どのテーブルをベースとして表示するレイアウトであるか」ということだけ押さえておけばデザインの自由を謳歌できます。

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

ローカルテーブルの計画

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

それに、直接データを触るのですからちょっとビビるというのもあります。

そこでもう一歩踏み越えて工夫をするわけです。例えばこんなやり方があります。

ローカルデータで編集し、ある程度まとめてリモートに送る

そもそもの最初、CSVで書き出して読み込んで作業してまた戻すということを目指していました。つまり安全なローカルで作業して本番に持っていくという考え方です。リモートと基本的に同じデータをローカル環境に用意してそれを編集、しかる後にリモートに送信して同期します。

リモートデータを直接編集する弊害

リモートデータを直接触って編集するのは速度が遅いだけでなく他にも弊害があります。ミスって大事なデータを意図せず改変してしまったり失ったりする危険がまずあります。調子に乗ってスクリプトで自動化しようとして失敗するとテーブル破壊にも繋がりかねません。

また、システム的に勝手に変更してはならない部分がたくさんあります。例えば新規ポストを作ったときにそのIDを好きな数字にするなんてできませんし、新規タームを作るのも手順を踏まないと駄目です。

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

ローカルデータで編集して同期を取る弊害

この一連の記事を書き始めてしばらくは「ローカルで編集してリモートに同期する」やり方を大前提にしていました。しかし時は経ち考えも環境も変わり、後に「ローカルは最小限、リモートのデータを直接編集する方向」にシフトしてしまいました。

ローカルで編集してリモートと同期するやり方は快適性安全性は確保されますが、同期させることが想像以上に大変な作業となりました。ローカルを元にリモートに送信するだけに留まらず、実際の運用ではリモートで変更した部分をローカルに反映させることも必要となり、つまり送信というよりシンクロシステムを構築しなければならなくなります。シンクロシステムの開発に本末転倒的に追われてしまうことにもなり兼ねません。

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

ローカルのテーブルをどのように作るのか、フィールドをどうするのか、何が最良なのか答えはありませんし使う人の好き好きというか必要性を元に考えていくことですので一律の答えなんかありません。ローカルデータにどの程度のデータを置くのかによっても変わってきます。

それでもまず思いつく必要なテーブルであるpostsですね。wp_postsというテーブル名でしょうか、これがやっぱ基本のキとなります。このテーブルをローカルにも用意することこそFileMkaerでWordPressを管理する要です。

とりあえず posts

ローカルにpostsという新しいテーブルを作成します。最初くらいはリモートのpostsと同じデータでスタートすることが望ましいと思います。そこで、リモートのpostsから全データをエクスポートしてローカルpostsに読み込みます。

wp_postsテーブル内のフィールドで最低限必要なのはIDフィールドです。これさえあれば後は何とでもなります。これがないと話になりません。

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

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

これが基本となり、後々ローカルのpostsにはいろんなテーブルやフィールドが増えまくります。

ローカルデータを中心に作業を行うならタイトル、本文、ステイタス、タイプ、リモートに合わせてフィールドを作成します。

リモートデータを中心に作業し、ローカルデータを補助的に使うなら各々が必要最低限と考えるフィールドを用意します。

どっちにしろ、リモートには存在しないがローカルに存在する独自フィールドは後々増えてくることでしょう。

 

次の記事「基本の編集(仕切り直し)」に続きます。前半、内容が被りますが、基本的なことはじっくりと。

 

広告

コメントを残す

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