ry0ta.ma2da

質問させて頂いていた本問題ですが、(はっきりとした原因は不明のまま)一まず解決しましたので、記載させて頂きます。

▼対応
WPで作成したBlogサイトへのアクセスは、proxyを経由してWP設置サーバへ転送しているが、そのWP設置サーバを別のサーバにリプレースした。

▼結果
初回アクセス含め、表示もデータ登録・更新も全く問題ない表示速度になった。

▼原因
旧サーバの具体的にどこが悪かったのかは不明。ハードウェア障害？

▼判断の経緯

• proxy経由なしで、複数回に分け時間をおいて、直接WP設置サーバへアクセスしてみたが、表示速度はやはり遅かった。
• その旧サーバの管理者がサーバにSSHでログイン、確認作業でcdやlsといった大した負荷のないコマンドを入力したが、管理者の経験・感覚からして、その応答が帰ってくる速度が異常に遅かった。
• 一度リブートを実行したが、なかなか始まらない終わらないで、リブート作業も異常に時間がかかった。

などの事象が見られたため、WordPressとか、Proxy経由とかのアプリケーション・ネットワークの問題ではなく、サーバ筐体そのものが問題と判断し、サーバをリプレースした。

jim912さん、podspodさん
アドバイスなど、ありがとうございました。致命的な問題が(とりあえず)解決し、ようやくサービスが開始できそうです。

jim912さん

情報ありがとうございます！
「2.Debug Barのソースを一部書き換える」で表示されました！

ただ、複数ページにアクセス・Debugで「Queries」を確認していますが、同じページで同じクエリでも、複数回アクセスしていると、時間がかかっていたクエリが次第に速くなったり、そもそも発行されなくなったりと結果がまちまちで、まだ遅延の箇所や傾向がつかめていません。

※100ミリ秒以上かかっていたクエリの例：

↓は、作成した固定ページTOPにアクセスした際のクエリの1つ、2度目以降、このクエリは発行されなくなった？

UPDATE wp_options SET option_value = '1336700006' WHERE option_name = '_transient_doing_cron'
do_action, wp_cron, spawn_cron, set_transient, update_option #2 (278.3ms)

↓は、ダッシュボード内の[更新]にアクセスした際のクエリ2つ

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
wp_not_installed, is_blog_installed, wp_load_alloptions #1 (804.1ms)

UPDATE <code>wp_options</code> SET <code>option_value</code> = 'O:8:\"stdClass\":1:{s:12:\"last_checked\";i:1234567890;}' WHERE <code>option_name</code> = '_site_transient_update_themes'
do_action, wp_update_themes, set_site_transient, update_site_option, update_option #8 (269.3ms)

しばらくアクセスを止め、時間を置いて再度アクセスするなど、引き続き確認していきます。
Debugで確認するべきメニュー、ポイント、やり方などありましたら、教えて頂ければと思います。

ご報告が遅くなってしまいましたが、404エラーの件、解決しました。
そもそも最初に書いた私の情報に不足があったのですが、
今回設置したWPへのアクセスで以下のように1度リバースプロキシサーバを経由する、ということが漏れておりました。

このリバースプロキシサーバからの転送URLを以下のように修正することで404エラーが解消しました。

●修正前
以下URLでリバースプロキシサーバにアクセスし、
→ http://hogehoge.jp/eblog

そこから、WPを設置した別のサーバの仮想ホストに以下URLで転送。
→ http://hogehoge-virual.jp/

この転送形式では、$_SERVER[‘REQUEST_URI’] に以下のパスが取得されるため、404エラーとなっておりました。
※以下のパスは404発生箇所の一例で、ダッシュボードの一般設定の変更ボタンのPOST先のパス

$_SERVER[‘REQUEST_URI’] に取得されるパス
→ /wp-admin/options-general.php

○修正後
対策として、仮想ホストに転送するリクエストを以下のように「/eblog」を付けた形に変更すると、
正しくパスは取得され404エラーは解消しました。

変更後の仮想ホストへの転送URL
→ http://hogehoge-virual.jp/eblog

$_SERVER[‘REQUEST_URI’] に取得されるパス
→ /eblog/wp-admin/options-general.php

＞nobitaさん、CyberCypherさん、Hikari Aoiさん、
こちらの情報が不足していたために、お手間を取らせてしまい、申し訳ありませんでした。
多くのアドバイスを頂き、ありがとうございました。

Hikari Aoiさん
詳細な情報ありがとうございます。

参考リンク内「httpd -Mコマンドでmod_rewriteがHTTPDに読み込まれているか確認しよう。」
httpdはyumでインストールすると/usr/sbin/httpdにあります。

コマンドの詳細ありがとうございます。確認しました。
「rewrite_module (shared)」となっており、問題ないようです。

httpd.conf及び/etc/httpd/conf.dの中の設定ファイルに対してAllowOverrideで検索をかけてチェックされることをお勧めします。

どちらも問題ないようです。

wp-configでWP_DEBUGをtrueにしてデバッグ情報を確認する。

エラーや警告情報は表示されませんでした。

/var/log/httpdのApacheログ

確認しましたが、疑わしい不明なエラーなどはありませんでした。

皆さんの環境だと$_REQUEST[‘_wp_http_referer’]が
「http://example.com/wp-admin/」「http://example.com/wp/wp-admin/」のように
「httpからwp-admin」までのパスを取得できているようですが、
なぜ私の環境の場合、「/wp-admin/…….php?…」なのか。

nobitaさんに教えて頂いたリライトルールを調べる
「AskApache RewriteRules Viewer」をインストールしてみましたが、
あまり詳細に時間をかけて確認できてませんが、ちょっと使い方が分かりませんでした。

引き続き、確認してみます。

CyberCypherさん、nobitaさん
アドバイスありがとうございます。

一度プラグインをオフにしてみることをお勧めします

オフにしてみましたが、アクセスできませんでした。

admin_url()とnetwork_admin_url()のURLは正しく取得できていますか？

「admin_url()」「network_admin_url()」ともに
「http://hogehoge.jp/eblog/wp-admin/」が取得されていました。
これらは正しく動いている？と思われます。

今回問題箇所の一つの
一般設定画面(wp-admin/options-general.php)の変更を保存ボタンを押下すると、
まず「options.php」に対してPOST、更新処理を行い、
パラメータを付与して元の一般設定画面(wp-admin/options-general.php?settings-updated=true)に戻る流れのようですが、
この「options.php」内で

/**
 * Redirect back to the settings page that was submitted
 */
$goback = add_query_arg( 'settings-updated', 'true',  wp_get_referer() );
wp_redirect( $goback );
exit;

としている「$goback」を画面出力してみると
「/wp-admin/options-general.php?settings-updated=true」
が取得されていました。

現状、ここまでしかコードを追えていないため、
このadd_query_arg()の結果が正しいのか分かっていません。

この時点で$gobackはこの結果でよいのか、それとも
「http://hogehoge.jp/eblog/wp-admin/options-general.php?settings-updated=true」
のように、完全なURLとしてドメイン＋WPディレクトリ名まで取得できているべきなのか。

正しければ、次はwp_redirect()の処理内の問題なのか何なのか、引き続き確認しようと思っています。

もしお気づきの点がありましたら、ご指摘をお願いします。

nobitaさん、ご回答ありがとうございます。

.htaccessの更新を行っていますでしょうか？

更新ボタン押下後、画面下部に表示されるコードを.htaccessに追記しましたが、
同じメッセージが表示され、404も解消されず、変化なしでした。

この.htaccessの問題に関しては、「http://ja.forums.wordpress.org/topic/808」あたりを参考に
.htaccessのパーミッションを「644 → 666」に変更したところ、
メッセージは「パーマリンク構造を更新しました。」となりました。
ただ、他設定メニューの404エラーは変化無しでした。

現在404エラーが発生している設定メニュー系と投稿画面のメディアを追加のタブリンクでは、
以下のように、
http://hogehoge.jp/eblog/wp-admin/…..
となってほしいリンク先のURLが、リンク、ボタン押下前の画面のソース確認時点で
http://hogehoge.jp/wp-admin/…..
というようにWPソースを配置しているディレクトリ名部分のパスが
出力されていないことから、そんなパスは存在しない(＝404)となっており、
パーミッションは関係ないのかな、と今のところ考えています。

ただ、WPやパーミッションについて、まだよく分かっていないため確認・質問させて頂きたいのですが、
wp-adminディレクトリとその配下のファイル群のパーミッションはどのように設定されていることが望ましいのでしょうか？

現在は以下の状態です。

▼対象：パーミッション/所有者/グループ
ディレクトリ：drwxr-xr-x(766)/nobody/apache
ファイル：-rw-rw-r–(664)/nobody/apache

wp-adminディレクトリについて、WP CODEXのファイルパーミッションの変更の要件は満たしていると思っているのですが、、。
httpd.conf内のドキュメントルートの設定とか、そもそも全く別問題なのかもしれません。

度々で申し訳ありませんが、何かご存知の情報がありましたら、アドバイスをよろしくお願いします。