WordPressアップデート後エラー「SELECT option_value FROM wp_options WHERE option_name」




wordpress-logo

ようやく重い腰を上げてWordPressのバージョンアップをしました。3.4系から3.7系への大幅バージョンアップです。ずっと、めんどくさくてアップデートを怠っていました。だってバージョンのアップデートするタイミングって、テンプレートやプラグインとの相性などもあって、何かとエラーが発生するリスクがありますから。

例えるなら、長い間歯医者に行かずに放置していて、久しぶりに歯医者に行く感覚です。虫歯を宣告されるのが怖かったんです。

jetpack photonをインストールしたかった

バージョン3.7系の売りと言えばセキュリティ関連の強化ですが、今回のアップデートの目的は別にありました。ワードプレスのホストサイトであるWordPress.comの画像サーバーをCDNとして使えるプラグイン「jetpack photon」を入れたかったんです。ですが、このプラグインはバージョン3.5以上でしか動かないために、ついにバージョンを更新することにしました。

それほど魅力的に見えた「jetpack photon」。というかCDNを導入してみたかった。

バージョンアップデート後エラー

当初の不安が嘘のように、新バージョンのインストールはあっさりと終わりました。アップデート後サイトを表示してみても問題なし。

無事にアップデートが完了したと思って、一応ログを確認してみたところ、エラーログにこんなエラーが何万行も出力されていることに気づきました。
何やら怪しいにおいプンプンするエラーログ。

[warn] mod_fcgid: stderr: WordPress \xe3\x83\x87\xe3\x83\xbc\xe3\x82\xbf\xe3\x83\x99\xe3\x83\xbc\xe3\x82\xb9\xe3\x82\xa8\xe3\x83\xa9\xe3\x83\xbc: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” at line 1 for query SELECT option_value FROM wp_options WHERE option_name = ‘sharedaddy_disable_resources’ LIMIT 1 made by require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), do_action(‘init’), call_user_func_array, sharing_init, get_option, dbrc_wpdb->query, dbrc_wpdb->dbcr_query

エラー文言を確認しよう

stderrに、以下のような記述があり、

xe3\x83\x87\xe3\x83\xbc\xe3\x82\xbf\xe3\x83\x99\xe3\x83\xbc\xe3\x82\xb9\xe3\x82\xa8\xe3\x83\xa9\xe3\x83\xbc

これは何かメッセージ的なので、\xを%に置き換える。

%e3%83%87%e3%83%bc%e3%82%bf%e3%83%99%e3%83%bc%e3%82%b9%e3%82%a8%e3%83%a9%e3%83%bc

URLエンコードされてるっぽいのでデコードする。

「データベースエラー」

WEBエンジニアなら見たくない文字列「データベースエラー」が。
どっかでサイト表示時にデータベースエラーが発生しているっぽい。

エラー文言中に、SQLクエリーが出力されている。このクエリーが手がかりになりそうだ。

SELECT option_value FROM wp_options WHERE option_name = ‘sharedaddy_disable_resources’ LIMIT 1

phpMyAdminを確認しよう

今度はphpMyAdminを確認しよう。WordPressのインストールを売りにしているサーバーなら入っているはず。もちろん直接DBを操作しても構わない。

サイトで使用しているデータベースをphpMyAdminで開いて、テーブルにwp_optionsを指定すると、テーブルの中身の一覧を表示してみる。

そこからoption_nameに’sharedaddy_disable_resources’が入っているレコードを探してみたところ、データが存在しなかった。どうやらこのエラーは、DBからデータ取得を試みたがデータが返らず、データありきで処理を想定しているコードでエラーが発生しているものと思われる。

同じように他の行のSQLも見てみると、以下のようなフォーマットのエラーで、(hoge)の箇所がいろいろ異なるエラーが頻出していた。原因はどうやら1つのようだ。

SELECT option_value FROM wp_options WHERE option_name = ‘(hoge)’ LIMIT 1

「option_name」に指定されていた値。

headspace_global
syntaxhighlighter_settings
embed_autourls
widget_grofile
widget_jetpack_readmill_widget
widget_image
widget_facebook-likebox
widget_twitter_timeline
widget_blog_subscription
widget_simpletags
widget_tag_cloud

推測しよう

「option_name」の値を見てみると、widget_*という値が多く入っている特徴があったので、ウィジェットデータを取得している箇所でうまくいっていないように思われた。

ワードプレスで使用されるウィジェットは、
「利用できるウィジェット」
「利用しているウィジェット」
「使用停止中のサイドバー 」
「使用停止中のウィジェット」
という4つのステータスがあり、デフォルトのステータスは「利用できるウィジェット」のようだ。

その「利用できる」というステータスから、実際にサイトで使用するウィジェットと、使用停止にするウィジェット振り分けるんだけど、使用しないウィジェットについては、意図的に「使用停止」にしなくても「利用できる」というステータスのままで問題ないから、多くの人はデフォルトのステータスのままウィジェット管理していると思う。

しかしステータスを移動しないと、テーブルwp_optionsにデータが挿入されないらしく、そのために新しいバージョンのWordPressではエラーが発生するようだった。

まとめると

今回出力されていたエラーは、ウィジェットデータをデータベースから取得しようとして発生していたエラー。

・エラーの出たウィジェットは、そもそも利用していないので、サイト上は実害がない。エラーは気持ち悪いけど。

・ウィジェットを使用したくなった場合、ステータスを移動するタイミングでwp_optionsにデータが入るので、エラーが解消されるため実害はない。

ということで今回のエラーは、サイトの見た目上影響の出るエラーではないことが分かりました。気になる人がいれば、ウィジェットのステータスを意図的に移動することでエラーが解消されます。


この記事が気に入ったら
いいね!してね

最新情報をお届けします!