为什么我的 .htaccess 和重写规则可能与建议的配置不同？

Question

我继承了一个现有的（而且非常有问题的）wordpress.org 网站，我很难理解前任所有者决定在 .htaccess 文件上做出的选择/规则。

我一直在尝试用谷歌搜索它的不同部分并查看不同的文档，但有些部分我找不到答案

我使用了 htaccess 测试器并且满足了一些规则，但很多都不 测试人员无法检查“ifmodule”语句，也无法理解 CacheLookup on

# BEGIN LSCACHE
## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
<IfModule LiteSpeed>
RewriteEngine on
CacheLookup on
RewriteRule .* - [E=Cache-Control:no-autoflush]
RewriteRule \.litespeed_conf\.dat - [F,L]

### marker CACHE RESOURCE start ###
RewriteRule wp-content/.*/[^/]*(responsive|css|js|dynamic|loader|fonts)\.php - [E=cache-control:max-age=3600]
### marker CACHE RESOURCE end ###

### marker FAVICON start ###
RewriteRule favicon\.ico$ - [E=cache-control:max-age=86400]
### marker FAVICON end ###

### marker WEBP start ###
RewriteCond %{HTTP_ACCEPT} "image/webp"
RewriteRule .* - [E=Cache-Control:vary=%{ENV:LSCACHE_VARY_VALUE}+webp]
RewriteCond %{HTTP_USER_AGENT} iPhone.*Version/(\d{2}).*Safari
RewriteCond %1 >13
RewriteRule .* - [E=Cache-Control:vary=%{ENV:LSCACHE_VARY_VALUE}+webp]
### marker WEBP end ###

### marker DROPQS start ###
CacheKeyModify -qs:fbclid
CacheKeyModify -qs:gclid
CacheKeyModify -qs:utm*
CacheKeyModify -qs:_ga
### marker DROPQS end ###

</IfModule>
## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
# END LSCACHE
# BEGIN NON_LSCACHE
## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
## LITESPEED WP CACHE PLUGIN - Do not edit the contents of this block! ##
# END NON_LSCACHE


#Begin Really Simple Security
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

#End Really Simple Security
# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

首先，测试员说

RewriteEngine on

Only the last RewriteEngine line is taken into account

如果是这样，为什么要为每个标记的部分添加它？我可以省略这个吗？

此外，许多 litespeed 规则未得到满足，但我也认识到有些部分它无法理解/看到

它似乎缺少在 litespeed .htaccess 和重写规则上设置的“示例规则”的一部分

为什么他们可能会更改“建议”示例规则的某些部分？前我的文件说

RewriteCond %{HTTP_ACCEPT} "image/webp"

（测试人员无法检查，因为变量未知） 但示例重写规则包括 [or]

RewriteCond %{HTTP_ACCEPT} "image/webp" [or]

另外，我不确定他们为什么决定包含 if 语句来检查哪个模块？ （这些有什么优点，或者可以删除这些“ifmodule”标签吗？）

最后，这可能是一个愚蠢的问题——“really simple SSL”是否与/以前称为“really simple security”相同？ 如果是，我应该将我的 .htaccess 更新为真正简单的 SSLs .htaccess 指南吗？

我希望这个帖子也能帮助其他人尝试配置他们的网站。

Answer 1

在我看来，决定安装许多不同的 WordPress 插件，每个插件都将自己的部分添加到

.htaccess

。看起来没有任何人以任何计划构建此配置。

RewriteEngine On

包含多次，因为每个插件都想确保它已设置。拥有多个这样的语句除了占用空间和处理时间之外不会有任何伤害。

IfModule

指令由插件添加，因此如果未启用所需的 Apache 模块，站点不会立即收到“500 内部服务器错误”。没有模块，规则就没有任何效果，因此在您知道启用了哪些 Apache 模块的机器上实现您自己的规则时，添加模块检查几乎没有意义。

我的猜测是规则是由旧版本的插件添加的，而不是手动编辑的。可能有人试图自定义文件，但情况不一定如此。

我会警告不要在

BEGIN

和

END

评论之间做太多编辑。插件将这些标记放在那里，以便它们可以在升级期间替换自己的规则。您所做的任何更改都可能在某个时候被覆盖。

我建议查看网站实际需要哪些 WordPress 插件。看起来可能安装了多个缓存插件，它们可能相互冲突。我将从减少提供您所需功能的最小插件集开始。

您应该升级所有插件以修补可能的安全漏洞，并确保每个插件的重写规则也更新到最新版本。