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.
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.
La directiveRewriteEngine 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.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.