Pourquoi mes règles .htaccess et de réécriture peuvent-elles différer de la configuration recommandée ?

Question

J'ai hérité d'un site wordpress.org existant (et très problématique), et j'ai du mal à comprendre les choix/règles que l'ancien propriétaire a décidé de faire concernant les fichiers .htaccess.

J'ai essayé de rechercher différentes parties sur Google et de consulter différentes documentations, mais il y a certaines parties auxquelles je ne trouve pas de réponse

J'ai utilisé le testeur htaccess et certaines règles ont été respectées, mais beaucoup ne l'ont pas été. Les testeurs ne peuvent pas inspecter les instructions "ifmodule" et ne peuvent pas comprendre CacheLookup sur

# 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

Tout d'abord, ce que disent les testeurs

RewriteEngine on

Only the last RewriteEngine line is taken into account

Si oui, pourquoi l'ajoutez-vous pour chaque pièce marquée ? Puis-je omettre cela ?

De plus, de nombreuses règles Litespeed ne sont pas respectées, mais je reconnais également qu'il y a certaines parties qu'il ne peut pas comprendre/voir

Il semble manquer la section "Exemples de règles" et les règles de réécriture définies sur litespeed .htaccess

Pourquoi pourraient-ils modifier certaines parties des exemples de règles « suggérées » ? Par exemple mon document dit

RewriteCond %{HTTP_ACCEPT} "image/webp"

(le testeur ne peut pas vérifier car la variable lui est inconnue) Mais des exemples de règles de réécriture incluent [ou]

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

De plus, je ne sais pas pourquoi ils ont décidé d'inclure une instruction if pour vérifier quel module ? (Quels en sont les avantages, ou ces balises "ifmodule" peuvent-elles être supprimées ?)

Enfin, cela pourrait être une question idiote : « Really Simple SSL » est-il le même que/anciennement connu sous le nom de « Really Simple Security » ? Si tel est le cas, dois-je mettre à jour mon .htaccess selon les directives très simples de SSL .htaccess ?

J'espère que cet article aidera également les autres personnes essayant de configurer leur site Web.

Answer 1

Il me semble qu'ils ont décidé d'installer de nombreux plugins WordPress différents, chacun ajoutant sa propre section à .htaccess. Il semble que personne ne suive aucun projet de création de cette configuration.

RewriteEngine On est inclus plusieurs fois car chaque plugin veut s'assurer qu'il est défini. Avoir plusieurs déclarations de ce type ne fait aucun mal autre que prendre de la place et du temps de traitement.

La directive

IfModule est ajoutée par le plugin afin que le site ne reçoive pas immédiatement une "500 Internal Server Error" lorsque les modules Apache requis ne sont pas activés. Les règles n'ont aucun effet sans modules, il est donc inutile d'ajouter des vérifications pour les modules lorsque vous implémentez vos propres règles sur une machine sur laquelle vous savez quels modules Apache sont activés.

Je suppose que ces règles ont été ajoutées par une ancienne version du plugin plutôt que modifiées manuellement. Il peut y avoir des tentatives de personnalisation du fichier, mais ce n'est pas nécessairement le cas.

Je mets en garde contre les modifications lourdes entre BEGIN 和 END commentaires. Les plugins y placent ces balises afin qu'ils puissent remplacer leurs propres règles pendant le processus de mise à niveau. Toutes les modifications que vous apportez peuvent être écrasées à un moment donné.

Je recommande de vérifier les plugins WordPress dont le site Web a réellement besoin. Il semble que plusieurs plugins de mise en cache soient installés et qu'ils soient en conflit les uns avec les autres. Je commencerais par réduire l’ensemble minimal de plugins qui fournissent les fonctionnalités dont vous avez besoin.

Vous devez mettre à niveau tous les plugins pour corriger les éventuelles vulnérabilités de sécurité et vous assurer que les règles de réécriture de chaque plugin sont également mises à jour à la dernière version.