wordpress wp-admin 或 wp-login.php 上的重定向循环

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/14532520/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-08 19:09:06  来源:igfitidea点击:

Redirect loop on wp-admin or wp-login.php

wordpressredirectinfinite-loop

提问by raffjones

I put together a quick WordPress site locally using MAMP, then checked it into an SVN repo. I then checked it out on to my development server.

我使用 MAMP 在本地建立了一个快速的 WordPress 站点,然后将它签入一个 SVN 存储库。然后我将其检查到我的开发服务器上。

I didn't change anything except to run the search and replace toolscript from Interconnectit to updated the URL of the site in the database on the server.

除了从 Interconnectit运行搜索和替换工具脚本以更新服务器数据库中站点的 URL之外,我没有做任何更改。

Initially, I got a 500 server error. Checking the logs, I discovered that this "SoftException" was because index.phpwas writeable by group - the permissions were 664. No problem - a quick change of permissions to 644 sorted that. So now the frontside was working.

最初,我收到了 500 服务器错误。检查日志,我发现这个“SoftException”是因为可以index.php按组写入 - 权限是 664。没问题 - 将权限快速更改为 644 可以解决这个问题。所以现在前端正在工作。

However, strangely, the admin side of the site did not work. It just produced an endless redirect loop in all browsers.

然而,奇怪的是,该站点的管理端不起作用。它只是在所有浏览器中产生了无限的重定向循环。

Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.

Nothing has changed since the local development version. The htaccess file is just a standard WordPress one. Nothing weird... still working fine locally.

自本地开发版本以来没有任何变化。htaccess 文件只是一个标准的 WordPress 文件。没什么奇怪的......在本地仍然可以正常工作。

So what's going on?

发生什么了?

回答by GandalfTheWhite

For whatever reason /wp-admin/ path causes a redirect loop, but /wp-admin/index.php does not. As such, we can use .htaccess to redirect the /wp-admin/ path to /wp-admin/index.php by adding the following line to your .htaccess file after "RewriteBase /" line like this:

无论出于何种原因 /wp-admin/ 路径会导致重定向循环,但 /wp-admin/index.php 不会。因此,我们可以使用 .htaccess 将 /wp-admin/ 路径重定向到 /wp-admin/index.php,方法是将以下行添加到 .htaccess 文件中的“RewriteBase /”行之后,如下所示:

RewriteBase /
RewriteRule  /wp-admin/ /wp-admin/index\.php [L,P]

It worked for me like that. You final .htaccess would probably look like this:

它像那样对我有用。你最终的 .htaccess 可能看起来像这样:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule  /wp-admin/ /wp-admin/index\.php [L,P]
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

回答by raffjones

Checking the permissions of wp-login.phprevealed that they too had somehow been set to 664 - the same permissions that caused index.phpto fail and caused the 500 server error.

检查权限wp-login.php发现它们也以某种方式被设置为 664 - 导致index.php失败并导致 500 服务器错误的相同权限。

I changed the permissions of wp-login.phpto 644 and hey presto, the WordPress login page showed up.

我将权限更改wp-login.php为 644,嘿,很快,WordPress 登录页面出现了。

But on logging in, another redirect loop. So, once again, looking at /wp-admin/index.php, the permissions were 664 rather than 644.

但是在登录时,另一个重定向循环。因此,再一次查看/wp-admin/index.php,权限是 664 而不是 644。

Fixing them led to problems with the next files in line - the dashboard was a right mess. One by one, changing from 664 to 644 corrected the issues (/wp-admin/load-scripts.php, /wp-admin/load-styles.php).

修复它们会导致下一个文件出现问题 - 仪表板一团糟。从 664 改为 644 一一修正了问题(/wp-admin/load-scripts.php、/wp-admin/load-styles.php)。

So it became obvious that a recursive change of permissions was the only way to sort things out.

所以很明显,权限的递归更改是解决问题的唯一方法。

My UNIX isn't exactly top notch, but this appears to have worked (running from Mac OS X Terminal). I ran it from the root directory of this WP install.

我的 UNIX 并不是一流的,但这似乎有效(从 Mac OS X 终端运行)。我从这个 WP 安装的根目录运行它。

find . -type f -perm 664 -print -exec chmod 644 {} \;

There might be a better command, but I understand this to mean "find all files with 664 permissions and change them to 644".

可能有更好的命令,但我理解这意味着“找到所有具有 664 权限的文件并将它们更改为 644”。

It has fixed my problem.

它解决了我的问题。

回答by Caedmon

If you're using Cloudflare you might want to try adding this to the TOP of your wp-config.php file:

如果您使用 Cloudflare,您可能想尝试将其添加到 wp-config.php 文件的顶部:

define('WP_SITEURL', 'https://www.example.com');
define('WP_HOME', 'https://www.example.com');
define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true);
if(isset($_SERVER['HTTP_CF_VISITOR']) && strpos($_SERVER['HTTP_CF_VISITOR'], 'https')){
  $_SERVER['HTTPS']='on';
}

It's important that you add it to the top of the wp-config.php file or you'll end up with "Sorry, you are not allowed to access this page" error messages.

将它添加到 wp-config.php 文件的顶部很重要,否则最终会出现“对不起,您不能访问此页面”错误消息。

Credit: https://www.meltajon.com/dev/wordpress-wp-admin-redirect-loop-with-cloudflare-ssl

信用:https: //www.meltajon.com/dev/wordpress-wp-admin-redirect-loop-with-cloudflare-ssl

回答by oli

if your webserver is nginx,you may need check the configure file of your nginx. If there is

如果您的网络服务器是 nginx,您可能需要检查您的 nginx 的配置文件。如果有

if (!-f $request_filename){
    rewrite ^/(.+)$ /index.php?& last;
}

Replace these lines with

将这些行替换为

try_files $uri $uri/ /index.php?$args;

See also Nginx Pitfalls, WordPress wiki page on nginx

另请参阅Nginx 陷阱nginx 上的 WordPress wiki 页面

回答by mal

with nginx config I had originally only this line and experienced the same redirect issue:

使用 nginx 配置时,我最初只有这一行并遇到了相同的重定向问题:

location / {
    try_files   $uri /index.php$is_args$args;
}

after adding this everything was fine:

添加后一切都很好:

location /wp-admin/ {
    index index.php;
    try_files $uri $uri/ /index.php$args;
}

回答by Jakir Hossain

If you are useing Cloudflare, from SSL/TLS tab of your Cloudflare account, select Full encryption. It will solve the issue.  SSL/TLS settings

如果您使用 Cloudflare,请从 Cloudflare 帐户的 SSL/TLS 选项卡中选择完全加密。它将解决问题。  SSL/TLS 设置

回答by Shoshana Werbner

I was getting DoS pages when trying to publish in my WP site. I found advice that changing permissions in the function.php file to 600 could solve the issue, also to add to that file a script snippet . It was a WP help page. I was able to get to the publishing in a work-around way. Still have the DoS when I try to open the editor.

尝试在我的 WP 站点中发布时,我收到了 DoS 页面。我发现将 function.php 文件中的权限更改为 600 可以解决该问题的建议,还可以向该文件添加一个脚本片段。这是一个WP帮助页面。我能够以一种变通的方式进行出版。当我尝试打开编辑器时仍然有 DoS。

回答by Basil Abbas

In the sites-enabled folder you will need to edit the configuration for your site and add the multisite redirection rules. For Ubuntu 14.04 you will be able to find the path under /etc/nginx/sites-available

在启用站点的文件夹中,您需要编辑站点的配置并添加多站点重定向规则。对于 Ubuntu 14.04,您将能够在 /etc/nginx/sites-available 下找到路径

Add the following block in your server block and you should be able to avoid the infinite redirection loop.

在您的服务器块中添加以下块,您应该能够避免无限重定向循环。

#Rewrite multisite '.../wp-.*' and '.../*.php'.
if (!-e $request_filename) {
    rewrite /wp-admin$ $scheme://$host$uri/ permanent;
    rewrite ^/[_0-9a-zA-Z-]+(/wp-.*)  last;
    rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$  last;
}

回答by ggedde

I just had to flush my redirects. Since I couldn't access the Admin I added this to the top of my functions.php file:

我只需要刷新我的重定向。由于我无法访问管理员,我将其添加到我的 functions.php 文件的顶部:

flush_rewrite_rules(); exit;

flush_rewrite_rules(); exit;

Saved it and refreshed my site. Then remove the code from your functions.php file and then refresh again. That did it for me.

保存并刷新了我的网站。然后从您的functions.php 文件中删除代码,然后再次刷新。那是为我做的。

I also think it might be a good measure to resave your permalinks.

我也认为重新保存您的永久链接可能是一个很好的措施。

PS. I think the main issue came from theme-my-login as it was redirecting to /login.

附注。我认为主要问题来自 theme-my-login,因为它重定向到 /login。

回答by John

I had a similar issue in my case it was due to restoring a db script that was created with WP Migrate DB. The script had merge tags in like "## DEV URL ##" which i needed to fix before running the script on mysql and pointing the wp-config.php to the correct database.

在我的情况下,我遇到了类似的问题,这是由于恢复了使用 WP Migrate DB 创建的数据库脚本。该脚本具有像“## DEV URL ##”这样的合并标签,我需要在 mysql 上运行脚本并将 wp-config.php 指向正确的数据库之前修复它。