コアPHP(フレームワークは使用されていません)で開発された静的Webサイトがあり、同じドメインのサブディレクトリにwordpressを使用してブログをインストールしました。
Like : example.com/blog
メインサイトは静的なphpファイルを使用して構築されているため、SEOの推奨に従って、URLから.php拡張子を削除する簡単な書き換えルールを作成しました。
そう
http://example.com/abc.php will rewrite to http://example.com/abc
今、実際の問題になっています。
http://example.com/blog/wp-admin にログインしてユーザー名とパスワードを入力しようとすると、wp-login.phpがリダイレクトされますが、上記の書き換えルールにより、wp-loginに変更されます。メインサイトにリダイレクト404ページが見つかりません。
書き換えルールNginxvhost-confは次のとおりです。
location ~ \.php$ {
if ($request_uri ~ (.*)\.php$) {
return 301 $1;
}
try_files $uri =404;
expires off;
fastcgi_read_timeout 900s;
fastcgi_index index.php;
fastcgi_intercept_errors on;
fastcgi_pass 127.0.0.1:9001;
これを行うには最善の方法ではないかもしれませんが、stackexchangeでほぼすべての回答を何時間も試し、最終的に上記を使用してこれを機能させました。
私の質問は、どうすればそのようなリダイレクトからwp-adminを除外できますか?または、誰かがそのような衝突を回避するための代替の適切なリダイレクト/書き換えルールを提案できますか?
完全なNginx構成:
server {
listen 80; # Default listen port
if ($Host = www.example.com) {
rewrite ^/(.*)$ http://example.com/$1 permanent;
}
server_name example.com www.example.com;
root /home/example.com/public_html/;
index index.php index.html;
access_log /var/log/nginx/skpat77-access.log;
error_log /var/log/nginx/skpat77-error.log;
gzip on; # Turn on gZip
gzip_static on;
gzip_comp_level 9;
gzip_min_length 1400;
gzip_vary on;
gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;
try_files $uri $uri/ /index.php?$args;
#error 500 502 503
error_page 500 502 503 /500x.html;
location = /500x.html {
root /usr/share/nginx/html;
}
location ~ \.php$ {
if ($request_uri ~ (.*)\.php$) {
return 301 $1;
}
try_files $uri =404;
expires off;
fastcgi_read_timeout 900s;
fastcgi_index index.php;
fastcgi_intercept_errors on;
fastcgi_pass 127.0.0.1:9001;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}
location /blog/ {
index index.php index.html index.htm;
try_files $uri $uri/ /blog/index.php;
}
}
ありがとう!
私はこの問題を自分で調べています-それまでの間、/ blog/wp-admin /ではなく/blog/index.php/wp-admin/を使用してログインできることがわかりました。
これは解決策として意図されたものではなく、再構成プロセス中の緩和策です。