WordPressプラグインのデータ管理方法ガイド

今回は WordPress から MySQLデータベース操作に関して紹介する予定でしたが、その前にプラグインでのデータ管理方法についてまとめておきます

データ保存先

プラグインをこれから作ってみようという方は、データってどこに保存してるの? という疑問をお持ちだと思います

保存したいデータは、設定値や結果、ログ等様々なデータがあると思いますが、それらのデータをどこに保存したら良いのか、また、その注意点等について紹介出来ればと思います

主なデータ保存先
  1. ファイル
  2. オプション値(WP専用関数)
  3. 有効期限付き一時データ (WP専用関数)
  4. ショートコード (WP専用関数)
  5. カスタムフィールド (WP専用関数)
  6. データベースに新規テーブル作成

想定しているのは小規模のサイトですが、主にこれらの6種類を用途により使い分けたり、組み合わせてデータを管理する事になります

※他にもブラウザ側に情報を保持する Cookie クッキーというのがありますが、今回紹介するサーバー側でのデータ保存とは異なるので除外しています

この6種類のデータ保存でデータベースを使っていないのは、1のファイルのみで、他は全てデータベースを利用しています

但し、2から5は、アクセスする為の関数が用意されていますので、データベースを扱っていることを意識することはありませんが、6を使用する場合には SQL を使ってデータベースにアクセスする必要があります

 

1.ファイル

画像や圧縮ファイル等の特定フォーマットや大きなサイズのデータを扱うときに使用します

保存場所は wp-content/uploads 下にフォルダー等を新たに作成して使用することが多いです。また、フォルダーやファイルには適切なアクセス権限をセットする必要があります

大きな画像データ等の場合は、外部の Flickr の様なサービスを利用する方法もあります

 

2.オプション値

最もよく使用されるプラグインのデータ保存方法です

サイト全体に関係する様な設定オプション値等を保存する場合に使用します

プラグインの設定ページ等でオプション値の保存、更新、取得、削除を行う関数 add_option(), update_option(), get_option(), delete_option() を使ってアクセスします

設定ページの作成に関しては下記が参考になります。定石に従って記述すればOKですが、設定ページやセキュリティも関係しますので、じっくり読んでいろいろ試してみてください

設定値は、保存、更新、取得が出来ればそれでOKと言うわけではありません。後々トラブルを起こさないよう意識しておくポイントがいくつかあります

データの保存先はデータベース

データは、データベースの wp_options テーブルに保存されますが、プラグインオプション値専用というわけではなく、WordPress の標準の設定値を保存するのと共有して使われています

ポイントとしては

  • オプション値が複数ある場合は、一つのプラグインでオプション名を変えてたくさん作るのは止めましょう。連想配列かオブジェクト形式で保存することが出来ます
  • データサイズが大きい場合は、ファイル保存や別途テーブル作成することを検討しましょう
  • プラグインを削除する場合は、オプション値も忘れずに削除しましょう

これらの注意を守らないと wp_options テーブルが無駄に大きくなったり、残骸データが残ってしまいます

WordPressは、起動時に全てのオプション値を読み込んでいます。この時に残骸データ等が残っていると wp_options テーブルを読み込むのに時間がかかる可能性があります。

塵も積もれば山となるで本来なら 10ms で読み込むところが 数百ms かかる場合もあります。気が付きにくい症状ですが、プラグインを全て無効にしたのに何か遅いという場合には wp_options テーブルが残骸データで肥大化している恐れがあります

他にもセキュリティに関する注意等、下記記事が参考になります

http://tokkono.cute.coocan.jp/blog/slow/index.php/wordpress/most-common-mistakes-in-wordpress-plugins-coding/

 

3.有効期限付き一時データ

有効期限を指定した一時的なデータ保存(キャッシュ)で使用します

一時保存データを set_transient(), get_transient(), delete_transient() 関数で簡単に扱うことが出来ます

Transient API – WordPress Codex 日本語版

有効期限付きの一時データ用に簡単に使用することが出来ますが、何故か wp_options テーブルを使って実装されています(メモリの場合もある?)

また、有効期限は内部的に期限判定用の transient データを別に作成するので、1つの transient データを作成すると実際は2つ作られるという謎の仕様です

一時データなのでイメージとしては、有効期限が過ぎたら自動的に消されるのではと思いがちですが、実際は、アクセスされた時に有効期限を判定して、オーバーしていたら削除するという仕様のようです

有効期限が切れた後にアクセスしないと残骸として残る可能性がありますので、使い終わったらきちんと削除することが大切です (コードを読む限りそ~なっているように見えるが、確証はない (^_^;)

結局、wp_options テーブル使っているので、2のオプション値の場合と同じ注意が必要です

あまり大きなサイズの一時データを保存したり、沢山の一時データを作りすぎるとデータベースアクセスに影響して遅延する可能性もあります

何故に wp_options と違うテーブルにしなかったのですかね

便利だからといって使いすぎないほうが良さそうです (^^)

 

4.ショートコード

ショートコードを使って、記事単位に設定を行いたい場合に使用します
ショートコードは応用範囲も広く、手軽に使えるので様々な用途に使うことが出来ます

wordpress 標準のショートコードとしては、 gallery/playlist/video/audio 等がありますが、プログラムで簡単に追加することが出来ます

Shortcode API – WordPress Codex 日本語版

ショートコードに与える設定値も、投稿記事内に文字列としてエディタから入力するので、特別に設定用の画面等も必要なく簡単に使用することが出来ます

設定値の保存、更新、削除はエディタからの操作でおこなうということとなります

また、ショートコード自体はコンテンツの一部ですので wp_posts テーブルに記事毎に保存されます

ポイントとしては

  • ショートコードのプログラム処理は、コンテンツにフィルターフックされるので、ショートコードのプログラム内では echo を行わないということです。リターン値が出力になりますので、echo すると意図どおりに出力できないので注意です。
  • ショートコードのプラグインを削除した場合は、コンテンツ内に記述してある対応するショートコードを消さないと、それ自体が文字列として表示されてしまいます

 

5.カスタムフィールド

これも記事単位に設定を行いたい場合に使用しますが、ショートコードと比較するとプラグラムによる処理を行いやすくなっています

データは、Post IDに関連付けて保存、更新、取得、削除する関数 add_post_meta(), update_post_meta(), get_post_meta(), delete_post_meta() を使いアクセスします

カスタムフィールドは、記事や固定ページの編集画面に表示され操作することが出来ますが、”_” (アンダースコア)で始まるキーを持つカスタムフィールドは非表示にすることが出来ます

プラグイン等で使用する設定値を保存する場合は、アンダースコアで始まるキーを用いれば、間違って操作されることを防ぐことが出来ます

設定値は、データベースの wp_postmeta テーブルに保存されます。ショートコードと違って専用のテーブルが割り当てられているのでプラグラムからもアクセスしやすくなっています

但し、データベーステーブルに保存されるので他の設置値と同様にあまり大きなサイズのデータを保存したり、沢山のデータを作りすぎるとデータベースアクセスに影響して遅延する可能性もあるので注意です

ポイントとしては

  • Post IDに設定したカスタムフィールドキーはデフォルトではユニークでないということです。同じカスタムフィールドキーが複数存在することを許可している為、トラブルになりやすいので注意が必要です
  • データ削除は、Post ID 毎に処理する必要があるので、foreach でループ処理を組む必要があります。2のオプションデータの場合と比べると削除時の処理が一手間多くかかりますが、プラグイン削除時には忘れずに削除することが大切です

カスタムフィールドとして見せるか隠すかで保存の仕方を使い分ける必要がありそうです。編集画面から操作するために個別にキーを割り当てるしかないでしょうが、プログラム等で使用する場合は連想配列等で1つのキーに複数の値を設定したほうがテーブルをコンパクトに保つことが出来ます

 

6.新規テーブル作成

通常は、1-5までで大抵の場合は対応できてしまいますので、新たにテーブルを作成する機会はあまりないかも知れません

ですが、データベースに新規テーブルを作成して、SQLを使ってデータアクセスしてみると勉強になりますし、wordpress がより深く理解できるようになるので一度はチャレンジしてみる事をお勧めします

このあたりが扱えるようになると、WordPressを使ってブログ以外のWebサービス等を作れるようになってきます

詳細は長くなりそうなので、今回はここまでです (^^)

次回からは、少し前に作成したプラグインアンテナというサービスを例にして、SQLを使ったリレーショナルデータベースの世界へ足を踏み入れていきます

 

今回のまとめ

今回は主に WordPress でデータを保存管理する場合に、標準で用意してある関数や注意点等について紹介しました

WordPress は、あまりデータベースを意識しなくても使えるようになっているのですが、プラグインを作成する場合は、裏でデータベースが使われているということを意識することが大切です

意識すれば、データの後始末等をきちんとやらなけいけないと言うことがハッキリ判ります

それでは、次回につづきます

 


まとめ記事紹介

go-to-top