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というテーブル名でしょうか、これがやっぱ基本です。

とりあえず posts

ローカルにpostsという新しいテーブルを作成します。最初くらいはリモートのpostsと同じデータでスタートすることが望ましいと思うなら、リモートのpostsから全データをエクスポートしてローカルpostsに読み込みます。不要なら特にそういうことをせず、都度自動作成すればいいでしょう。

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

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

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

 

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

 

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

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