Notice: has_cap の使用はバージョン 2.0 から非推奨になりました ! プラグインやテーマでのユーザーレベルの使用は推奨されていません。代わりに権限グループと権限を使ってください。
先日管理画面が真っ白になってデバッグモードを試してみたら、実はこんなエラーも一緒に表示されていました。
普段動いているということは致命的なエラーではないのでしょうが、出なくなるのであれば修正したいと思い調べたところ解決策はすぐに見つかりました。
以下毎度おなじみの備忘録です。
主な原因はプラグイン内の関数に有り！
プラグインを構成しているPHPファイル中で使用されている関数で「add_options_page()」というものがあり、そこで使用されている引数によってこのエラーが発生するという記述を随所で見かけました。
最初にエラーメッセージを見たとき、自分の環境の場合では
～wordpress/wp-includes/functions.php on line 3318
なるエラーメッセージが出ていたので該当するファイルであるfunctions.phpを眺めますがadd_options_page()なんて関数は存在しません。
更に調べると「エラーを吐く」という処理を行っているのがfunctions.phpの3318行目という意味らしいです。う～ん、分かりにくい・・・
そしてadd_options_page()関数の3番目の引数に数字が入っていたらこれが原因ということ。
数字を消して'administrator'に書き換えるとエラーが治まるのだそうです。
この3つ目の引数、プラグインの動作や表示を行うための権限を指定する値らしいんですが、数字ではなく'administrator'という文字列を与えるとエラーが解消されるということが分かりました。
とにかくadd_options_page()関数を使っているプラグインを調べなければなりません。その調査方法とは・・・？
プラグインを全停止して一つずつ調べる
これは確実といえば確実でしょう。しかもこれでエラーが収まらなければ「テーマに問題あり」という新しい課題も見つけることができます。
一度全てのプラグインを止めた後、一つずつ有効化していってエラーが発生したらビンゴ！という具合です。
そうして一つずつ試していくとエラーとなる要素を持ったプラグインを特定できるわけですね。
端末でgrepコマンドを使って一気に調べる
grepコマンドを使用して、プラグインディレクトリ以下のファイル内に「add_options_page」という文字列を含むものを抽出できればピンポイントで調べられるのでは？と思い試してみました。
↓プラグインディレクトリへ移動する # cd WordPressのインストールディレクトリ/wp-content/plugins/ ～/wp-content/plugins# grep -ilr add_options_page ./
ちなみにオプションで使用した「-ilr」は
- iで大文字、小文字を識別せず検索する
- lでファイルのみを対象とする
- rで指定したディレクトリ以下を検索対象とする
という意味を持っています。
これで調べるとズラズラと出てきましたよ、add_options_pageという文字列を含むPHPファイルが。
あとは一つずつ開いて中身を確認していきます。ちなみに導入している全てのプラグインがこの関数を使用しているわけではなさそうで、全体のうち6割程度が表示された感じでした。
これらのファイルをviエディタで開き、中身を調べるんですが検索はコマンドモード中に「/add_option」と入力すれば簡単に探すことができますので念のため。
自分の場合1件だけ第3引数が8になっているものがありました。この値を'administrator'に書き換えてプラグインを再起動すると無事エラーが消えました。
まとめ
WordPressが随時アップデートされていることは使っている方ならご存知のはずですよね。
繰り返される更新の中で機能の定義が変化するのは当然であり、それに追随してプラグインも変更されるわけです。が。
長いこと更新されていないプラグインも存在しているわけで、問題なく動くうちは良いのですが今回みたいに表向きは動いていても内部ではエラーを吐いているということも十分ありえる話なんですね。
デバッグモードについて調べていたときにwp-config.php内の記述を増やすことでエラーメッセージをログに吐き出す方法も見かけましたので、余裕があるときに導入すると共にログ監視でもできれば・・・とちょっと思ったのでした。