wp_options テーブルを監視する [FileMakerでWordPress]

WordPress を長く使っていると wp_options テーブルが肥大化します。不要な項目を削除してクリーンアップしたくても自動での手段はありません。FileMakerで管理することで補助し、手間を軽減します。

wp_optionsテーブル

WordPressのwp_optionsテーブルにはサイト情報から設定からプラグインの設定からデータからキャッシュやその他、わけの分からない多くのデータが格納されます。

フィールドは次の通り。

option_id
option_name（項目名）
option_value（値）
autoload

autoload フィールドが「yes」に設定されていると文字通り読み込み時にロードされます。一つずつは小さくても数が膨れ上がるとWordPressサイトの表示速度に悪影響をもたらすかもしれません。

プラグインの残骸

プラグインの設定やデータが保存され、プラグインを捨てても残る場合があります。長年WordPressを使っていて、プラグインを試しては捨て、使っては捨てを繰り返すなかで、wp_optionsテーブルには残骸のゴミが溜まる一方、行数は膨れ上がります。

お行儀の良いプラグインは削除する時にwp_options内も消してくれます。ですがそうではないのもまだまだ多いし、昔のプラグインなら尚更です。

プラグインが wp_options を使用するかどうかはソースを見れば判るそうです。

add_option( $option );
register_setting( $option );
update_option( $option );

このような記述があれば、optionsテーブルに何かを保存しています。

プラグインを削除した際に残骸をちゃんと消してくれるかどうかは、次の記述があるかどうかを調べます。

delete_option( $option );

これがあればお行儀良くwp_options内のデータを消してくれるとのことです。

以下のサイトの情報です

データベースに残ったプラグインのゴミデータを削除することができるWordPressプラグイン「Clean Options」

wp_options テーブルの不要なデータを削除して大掃除するのはちょっと大変なことです。

クリーンアップ

かつて Clean Options というwp_optionsのクリーンアップ補助プラグインがありました。項目名からプレフィックスを判断してプラグイン名が判断できれば表示、不明ならgoogle検索に飛ばすというアナログチックな仕様でした。が、すでに閉鎖されダウンロードできません。同じ目的のプラグインがありましたが出来があまり良くなくて、それもやはり更新されず終わった感あります。

Clean Options の仕様の通り、項目名しか頼るものがありません。目視で確認しながら不要と判断できるものをチクチク消すなんてやってられないですね。でもそれしか方法がないみたい。

FileMaker で wp_options

そこでFileMakerの出番でございます。wp_options をレイアウトに配置するだけで、見やすいリストになります。

wp_options と繋がるローカルテーブルを用意して、Checkフィールドなんてのを作って印を付けていくとか（図では右端の丸印）そのチェックしたレコードをまとめて削除するとか、いろいろとやりようがあります。

wp_options だけでもそこそこいけますがテーブル構成をちょっと作り上げてさらに良きものにします。

FM options管理のテーブル構成

wp_optionsと繋がるテーブルを local_options と名付けました。このテーブルには、次のフィールドがあります。

option_name … wp_options の option_name と同じ値。これを照合してリレーションします。
prefix … 名前から判定して prefix を入力します。
check … チェックフィールド（数字。1ならチェック）

prefix は、たとえば名前が「code_snippets_settings」なら「code_snippets_」という案配です。完全手動で入力するもよし、”_” から判定するスクリプトを作るも良しです。

もう一つ別のテーブルをこしらえます。prefix_data テーブルです。 prefix フィールド、分類名、プラグイン名、メモなんかのフィールドを作ります。

local_options とは prefix で照合してリレーションし、自動作成をONにしておきます。

こんな感じのリレーションとなりました。

FM options の実践

まずは wp_options をベースとしたレイアウトをこしらえましょう。

wp_options の option_name を配置。次いで、local_options の prefix を配置。そして、prefix_data の分類名、プラグイン名、メモを配置します。

FM options レイアウト — wp_optionsをベースに、リストのレイアウトを作った

wp_options が表示されています。local_options も prefix_data も空です。

まずやることは、local_options にレコードを作ることです。リレーションで自動作成をONにしているので、データの入力によりレコードは勝手に作られます。

local_options::option_name に wp_options から option_name を転記する
local_options::prefix に prefix を記入する

prefix を記入することがキモになります。prefix は option_name から判定します。目視で判定して手動でコピペして作りますか？たくさんありすぎてそれは厭です。雑でいいからスクリプトで処理しましょう。

prefixを作成するスクリプト

変数を設定 [ $name; 値:wp_options::option_name ]
#local_options に name がなければ記入
If [ IsEmpty ( local_options::option_name ) and not PatternCount ( wp_options::option_name ; “_transient_” ) ]
フィールド設定 [ local_options::option_name; $name ]
End If
#”_” の数に応じた prefix 作成
変数を設定 [ $ptc; 値:PatternCount ( $name ; “_” ) ]
If [ $ptc ≤ 1 ]
#”_” が 1個以下なら name のまま
変数を設定 [ $prefix; 値:$name ]
Else If [ $ptc ≥ 2 ]
#”_” が 2個以上あれば 2個までを prefix とする
変数を設定 [ $prefix; 値:Let ( [ list = Substitute ( $name ; “_” ; “_” & ¶ ); pf = GetValue ( list ; 1 ) & GetValue ( list ; 2 ) ]; pf ) ]
End If
#prefix を記入
フィールド設定 [ local_options::prefix; $prefix ]
フィールドへ移動 [ ]

やってることは次の通り。

そもそも名前に「_transient_」が含まれれば無視する
option_name に “_” が何個あるか数える
1個以下なら、option_name をそのまま prefix とする
2個以上あれば、2個までをprefixとする

名前に「_transient_」が含まれていれば一時データで、自動で消されていくものですからデータベースに登録する必要ありません。除外します。

名前が「sitename」なら _ が0個なのでprefixも「sitename」
「admin_email」なら _ が一個なのでやはりそのまま「admin_email」
「hoz_theme_copyright」なら2個なのでprefixは「hoz_theme_」
「hoz_theme_google_search_code」は2個以上なので2個まで採用して「hoz_theme_」です。

このようにして自動で prefix を付けていきます。見ただけで何ものかが明らかなら、手動も併用していいし。「akismet_」が含まれていたらそれはもう、かなり明らかにプラグイン Akismet のデータと判りますから「akismet_」で良いと。雑でもいいんです。大したことじゃない。

こうしてlocal_optionsにレコードが作られprefixが記入されました。

次にやることは、prefix_data にデータを記入していくことです。

プラグインが作ったデータならプラグイン名を入れたりします。WordPressが必要とするデータならそれなりにメモしましょうか。

・・・しかし、その判定を目視で人間がやっていくなんて多すぎて無理難題です。

WordPress が作成したデータか、プラグインが作成したデータなのか、中にはprefixを見て明らかに判るものもありますが、大半は出自が何なのか分かるわけがありません。こればかりは自動化どころか普通の人間に判定は不可能という、過酷な現実は変わりません。

wp_optionsを読み込んで、そのレコードの多さにうんざりすることでしょう。なんか手立てはないでしょうか。

そこで、こんなことをしてみました。

新品WordPressを作ってデータを蓄積

新しいデータベースを作って新しいWordPressをインストールします。新品状態から一般的な初期の設定を済ませますね。この状態からFileMakerを使っていきます。

新品の初期状態だからwp_optionsは全部必要なものです。ゴミはまだありません。いいぞ。一気にマーキングします。

これでWPが初期に作るwp_optionsの項目が分類され、そこそこ明白になりました。

そこそこであることにご留意ください。カスタマイザを使ったりウィジェットやメニューをいじったり後から何か設定を変更したりすることでも項目名が作られますから、この初期状態がすべてではありません。厳密なものではないです。

なるべくこの段階でいろんな設定を弄り倒すのが良いかもしれません。プラグイン0の状態でさまよいます。そして、FileMaker でマーキングします。

初期状態が落ち着いたら、いつも使ってるプラグインを少しずつ追加していきます。新たなoption_nameが作られたら分類してプラグイン名を書き記していきます。少しずつやれば何となくどの名前がどのプラグインか察しが付きます。

wp_options プラグインが追加した項目を含むリスト — いくつかのプラグインが作成した項目を含むリスト

こうして prefix データベースが育っていきます。この育てる段階でも謎のoption_nameが作られます。「あれ？この名前、プラグインが作ったのか、wordpress が作ったのか、どっちだ？」となることもあります。

しかしその謎の答えなんか、どうでもいいんです。確実なことは、この段階では棄てて良いデータはないということです。謎ならそのまま「使用」とかなんとか、何でもいいからメモを残せば良いだけです。

さて、このデータベースがそこそこ育ったら、他の本番サイトのwp_options に繋げて使います。

wp_options テーブルは ODBCで接続していますから、必要な他のデータベースを読みこんでテーブルオカレンスを入れ替えます。

すでにたくさんのoption_name に prefixが付けられ分類されマークされているはずです。どうですか。マーク済みの項目は少なくとも、クリーンアップの削除候補から除外できますね。

謎の prefix が多く残るでしょうが、あとは自力でがんばります。10年前に使っていた懐かしのプラグイン名を発見することもあるでしょう。謎のprefixをgoogle検索すると運が良ければプラグイン名がヒットする場合があります。

ということで、wp_optionsテーブルの不要項目を削除するための一助になり得るFileMaker prefixデータベースでした。prefixデータベースを作ることそのものが目的化してしまうとのめり込んで本末転倒になりますので、あくまで補助としてゆるく作り、扱います。

お約束の注意事項ですが、wp_optionsテーブルのデータ行を消しまくる前に、テーブルのバックアップを必ず取っておきましょう。要る奴をうっかり消したらWordpressが壊れます。