何かセキュリティ関連のプラグインは使用されていませんか？
返信ありがとうございます。
セキュリティ関連のプラグインは、
Acunetix WP Security
Akismet
を使用しています。
その他、何点かセキュリティ以外のプラグインを使用しています。
プラグインの最終更新日時が確認できれば、調査対象は絞れるのですが。。
version 3.9がリリースされたので更新したところ、同じ現象が起きました。
原因を探っていると、やはり「ms_files_rewriting」が更新のタイミングで書き換わっているようです。
wp-admin/includes/upgrade.php 1353-1355行の
// 3.5
if ( $wp_current_db_version < 21823 )
update_site_option( ‘ms_files_rewriting’, ‘1’ );
の処理でフラグを書き換えていました。
ローカルでは、この条件に入らないのになぜか本番環境では入ります。
$wp_current_db_versionの値がずれているようです。
$wp_current_db_versionを正常値に戻す方法はあるのでしょうか。
通常はWPをアップグレードすると、データベースの更新があれば書き換えられます。
バージョン3.9に更新したのであれば’27916’になっていると思います。
バージョン3.8.2では’26692’でした。
データベースに保存された値を確認してみてはどうでしょう。
Version 3.9 – WordPress Codex 日本語版
バージョン 3.9 ではデータベースバージョン (wp_options テーブルの db_version) が27916へ変更となり、Tracのリビジョンは r28154 となりました。
マルチサイトの場合、’wp_[ブログID]_options’テーブルの’db_version’と’wp_blog_versions’テーブルにもブログごとの’db_version’が保存されています。
テーブル名の’wp_’はプレフィックスです。
返信ありがとうございます。
ローカルでは、’wp_blog_versions’の値は全て’27916’で統一されていたのに対し、
本番環境ではバラバラになっていたことや、
ローカルでは’wp_[ブログID]_options’の’db_upgraded’が’1’であるのに対し本番ではNULLであったことが気になりました。しかし、いずれにしても
wp-admin/includes/upgrade.php 1353-1355行の
// 3.5
if ( $wp_current_db_version < 21823 )
update_site_option( ‘ms_files_rewriting’, ‘1’ );
にあたるような’21823’を下回るものはありませんでした。
また、本日再度この現象（ms_files_rewritingの書き換え）を確認しました。
正常に動作していた時点と発見までの時点で、WP及びプラグインの更新は行っていません。
現在は「update_site_option( ‘ms_files_rewriting’, ‘1’ );」をコメントアウトし、様子をみています。
