Warum weichen meine .htaccess- und Rewrite-Regeln möglicherweise von der empfohlenen Konfiguration ab?

Question

Ich habe eine bestehende (und sehr problematische) Website von wordpress.org geerbt und es fällt mir schwer, die Entscheidungen/Regeln zu verstehen, die der Vorbesitzer in Bezug auf .htaccess-Dateien getroffen hat.

Ich habe versucht, verschiedene Teile davon zu googeln und mir verschiedene Dokumentationen anzusehen, aber auf einige Teile kann ich keine Antwort finden

Ich habe den htaccess-Tester verwendet und einige Regeln wurden erfüllt, viele jedoch nicht. Tester können „ifmodule“-Anweisungen nicht prüfen und CacheLookup on

nicht verstehen

# 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}/ [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

Erstens, was die Tester sagen

RewriteEngine on

Only the last RewriteEngine line is taken into account

Wenn ja, warum fügen Sie es für jedes markierte Teil hinzu? Kann ich das weglassen?

Außerdem werden viele der Litespeed-Regeln nicht eingehalten, aber ich erkenne auch, dass es einige Teile gibt, die es nicht verstehen/sehen kann

Es scheint, dass der Abschnitt „Beispielregeln“ fehlt und die auf litespeed .htaccess festgelegten Regeln neu geschrieben werden

Warum ändern sie möglicherweise einige Teile der „empfohlenen“ Beispielregeln? In meinem Dokument steht zum Beispiel

RewriteCond %{HTTP_ACCEPT} "image/webp"

(Der Tester kann nicht prüfen, da ihm die Variable unbekannt ist) Zu den Beispielregeln für das Umschreiben gehört jedoch [oder]

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

Außerdem bin ich mir nicht sicher, warum sie beschlossen haben, eine if-Anweisung einzufügen, um zu überprüfen, welches Modul? (Was sind die Vorteile davon oder können diese „ifmodule“-Tags entfernt werden?)

Abschließend könnte dies eine dumme Frage sein – ist „Really Simple SSL“ dasselbe wie/früher bekannt als „Really Simple Security“? Wenn ja, sollte ich meine .htaccess-Datei auf die sehr einfachen SSL-.htaccess-Richtlinien aktualisieren?

Ich hoffe, dieser Beitrag hilft auch anderen, die versuchen, ihre Website zu konfigurieren.

Answer 1

在我看来，他们决定安装许多不同的 WordPress 插件，每个插件都将自己的部分添加到 .htaccess 中。看起来没有人按照任何计划构建此配置。

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

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

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

我警告不要在 BEGIN 和 END 注释之间进行大量编辑。插件将这些标记放在那里，以便它们可以在升级过程中替换自己的规则。您所做的任何更改都可能在某个时刻被覆盖。

我建议查看该网站实际需要哪些 WordPress 插件。看起来可能安装了多个缓存插件，并且它们可能相互冲突。我首先会削减提供您所需功能的最少插件集。

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