【问题标题】:.htaccess mod_rewrites on trailing slash.htaccess mod_rewrites 在斜杠上
【发布时间】:2017-10-16 20:15:37
【问题描述】:

对于多站点 WordPress 安装,我无法在我的 .htaccess 中找到这个看似 mod_rewrite 问题的来源。

问题是当我尝试直接在地址栏中输入页面时(例如example.com/page),它会将我重定向到wp-login.php 脚本/页面。

如果我先加载example.com,然后输入尾部斜杠和页面(例如,先输入example.com,然后添加/page 并按回车键),它可以工作。

我已将此问题移交给我的网络托管团队,但他们无法解决此问题。我之前也从事过网络托管工作。

该站点目前不是“主域”,但它的所有文件都位于主根目录的子目录中(例如parent/public_html/subdir),但它位于自己的域和文档根目录中。这是站点 1,博客 2(在 wp-config.php 和 DB 中)。

WordPress 多站点安装加载一切正常。

这是我的.htaccess

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"
</IfModule>
## EXPIRES CACHING ##


RewriteCond %{SERVER_PORT} 80
RewriteCond %{HTTP_HOST} ^domain\.tld$ [OR]
RewriteCond %{HTTP_HOST} ^www\.domain\.tld$
RewriteRule ^(.*)$ https://www.domain.tld/$1 [R,L]

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]


# Wordfence WAF
<Files ".user.ini">
<IfModule mod_authz_core.c>
    Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
    Order deny,allow
    Deny from all
</IfModule>
</Files>

# END Wordfence WAF

【问题讨论】:

  • 这个.htaccess 文件在哪里?你还有其他.htaccess 文件吗?这听起来不像是 mod_rewrite/.htaccess 问题。您发布的.htaccess 文件中肯定没有任何内容可以触发重定向到wp-login.php。这是 WordPress 会在应用程序代码中做的事情。
  • 在这个子目录中有一个.htaccess,在父目录中也有。父级主要处理过期和缓存。不过我是认真的,它只是让我在加载主页后直接输入页面的 URL,而无需再次输入完整的 URL(例如,仅通过添加到现有 URL)。
  • 如果您立即请求/anotherpage - 会发生什么?那样有用吗?在什么时候您需要返回请求裸域?请求中一定有一些不同的东西 - 检查正在发送的 HTTP 请求标头。在初始请求中可能没有会话/cookie,因此在访问example.com/ 后,会话将启动并返回 cookie。对/page 的请求可能取决于设置的会话/cookie(但这将是 WordPress,而不是 .htaccess)。
  • 所以,我将问题缩小到是 Wordpress 没有在目录末尾添加斜杠的问题。如果你手动添加它,它可以工作。
  • 是的,这只是子目录的问题。当我用斜杠(例如/page/)加载它们时,它可以工作;当我在菜单中加载它时,它会加载斜杠。当我只键入没有斜杠时,我会假设 .htaccess 会找到该页面并在最后将我重写为破折号。我读过最好在结尾处硬编码斜杠,因为它可以加快浏览器的速度。所以,我只需要知道如何修改它来添加它。

标签: wordpress apache .htaccess mod-rewrite


【解决方案1】:

当我用斜杠(例如/page/)加载它们时,它可以工作;当我在菜单中加载它时,它会加载斜杠。当我只键入不带斜杠时,[它不起作用]。

您错过了问题中的尾部斜杠,这使得这个问题更难理解。

要在所有 WordPress URL 上强制使用斜杠,您可以尝试在 WordPress 前端控制器之前立即添加以下指令。

RewriteRule !./$ %{REQUEST_URI}/ [R=302,L]

请注意,这是 302(临时)重定向。仅当您确定它工作正常时,才将其更改为 301(永久)重定向。 301 被浏览器硬缓存,因此可能会使测试出现问题。

这应该放在这里:

# Prevent further processing for existing files/directories
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]

# >>> HERE <<<

# Front controller
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

如果您只需要应用到特定主机然后添加一个条件来检查这一点。例如:

RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule !./$ %{REQUEST_URI}/ [R=302,L]

我已经读过最好将尾部斜杠硬编码,因为它可以加快浏览速度。

这仅适用于物理目录,不适用于 WordPress URL。对于 WP URL(或任何其他类型的 virtual URL),没有区别,这只是个人喜好。 (FWIW,我不喜欢尾部斜杠,除非直接链接到文件系统目录。)

对于物理目录,Apache (mod_dir) 将发出 301 重定向以附加尾部斜杠。这是必要的,以便能够从该目录提供目录索引(例如index.php)。因此,为了避免额外的重定向,您应该链接到带有尾部斜杠的目录。

【讨论】:

  • 虽然我没有特别提到(13 天前),但你是第一个提到任何事情的人。你明白我所说的整个声明的意思。接下来,我不喜欢尾部斜杠,但我更喜欢现在拥有它,因为如果没有,页面将无法正确加载。物理 URL 与 WordPress 是什么意思? wp-login.php 是物理服务器上物理目录中的物理文件;不?关于修改,它现在似乎正在工作;将继续测试。
  • “物理 URL 与 WordPress 是什么意思?” - 那是物理目录。换句话说,映射到文件系统上物理目录的 URL。 WordPress URL(到页面)是完全虚拟的——它们不映射到物理目录路径。只有当 URL 映射到物理目录路径时,必须才包含尾部斜杠(以“加速浏览器”)。 “wp-login.php 是物理服务器上物理目录中的物理文件;不是吗?”是的。但是像 /2017/10/17/some-page-slug 这样的 WordPress URL 不是。
  • 我很抱歉。我也将数据库写入视为磁盘上的物理写入,但我能理解您在说什么。我将您建议的行添加到 .htaccess 中,它似乎至少可以工作一次。但是,它现在不起作用。如何将此修复应用于虚拟/Wordpress 页面?我认为这可能是在数据库中格式化 URL 的方式,但很可能页面根本不会加载;没有?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-01-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多