WordPressのupdate_option/add_option、キーは良きに計らってくれない (>_<)
WordPressのプラグインを作成していると、設定画面を作って値を保存したいシーンがよく登場します。その際には、WordPressで用意されているadd_option関数またはupdate_option関数を使用することで、キー＆バリュー形式のデータを簡単に保存できる様になっています。
ただ、このキーを決める際には他のプラグインやWordPressで既に使われた名前を使ってしまわない様に注意が必要です。
書籍のサンプルでは
私がWordPressプラグイン開発の相棒として愛読している書籍「サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル
update_option( 'my-data', $_POST['my-data'] );
これは、「”my-data”というキーで POSTパラメータで渡された”my-data”パラメータの値を登録して」というコードです。
ただ、この’my-data’ってノリで自分のプラグインを実装しているとまずそうです･･･
理想と現実
理想はプラグイン自身が自主的に、他のプラグインとはかぶらないキーで登録してくれることです。書籍のサンプルからもそうなのだろうと勝手に判断していました。
ところが開発中のゴミデータを削除しようとしてデータベースを除いた際に、登録されていたキーの値が気になりました。
update_optionの設定値はwp_optionsに登録されます。そこの「option_name」がキーにあたるのですが、特にプラグイン毎に値が設定されている用には見えませんでした。
簡単に競合した
そうなると別のプラグインで偶然にも同じキーを指定してしまうと上書きされる懸念が生じますが、さすがにそうはならないだろう、option_idの方がなんらか考慮してくれているのではないかと思い、試しに既に登録されているキーを指定してupdate_optionを呼び出してみました。
「site_icon」というキーで「0」が登録されていたので、試しに以下のコードを実装してみました。
update_option('site_icon', 1);
その結果･･･
見事に1となりました。既存の誰か（他のプラグインかWordPressでもともと登録されていた）が登録したキーの値を書き換えることに成功してしまいました。
これは他のプラグインからも予期せず消される可能性があるということで、けっこう危険です。対処として、キーの先頭にプラグイン名だか自分が所有しているドメイン名だかをつけて、例えば「info.felt-life.site_icon」の様にした方がいいと思いました。
キーが格納される option_nameの項目の型はvarchar(191)なので、桁数があふれないかは神経質にならなくても大丈夫そうです。
