在wp-admin或wp-login.php上的重定向循环 [英] Redirect loop on wp-admin or wp-login.php

查看:229
本文介绍了在wp-admin或wp-login.php上的重定向循环的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

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.

除了运行搜索并替换外,我没有进行任何更改工具(来自Interconnectit)脚本来更新服务器上数据库中站点的URL.

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

最初,我收到500个服务器错误.检查日志后,我发现此"SoftException"是因为index.php是按组可写的-权限为664.没问题-快速将权限更改为644可以对它进行排序.所以现在前端正在工作.

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

但是,奇怪的是,该网站的管理员方无法正常工作.它只是在所有浏览器中产生了一个无限的重定向循环.

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.

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

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

那是怎么回事?

推荐答案

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

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

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

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

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

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

修复它们导致下一行文件出现问题-仪表板很混乱.从664到644的一个接一个地纠正了该问题(/wp-admin/load-scripts.php、/wp-admin/load-styles.php).

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).

因此,很显然,递归更改权限是解决问题的唯一方法.

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

我的UNIX并非完全一流,但这似乎已经奏效(从Mac OS X Terminal运行).我从此WP安装的根目录中运行了它.

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.

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

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

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

它解决了我的问题.

这篇关于在wp-admin或wp-login.php上的重定向循环的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆