Why might my .htaccess and rewrite rules differ from the recommended configuration?

Question

I inherited an existing (and very problematic) wordpress.org site, and I'm having a hard time understanding the choices/rules the previous owner decided to make regarding the .htaccess file.

I've been trying to google different parts of it and looking at different documentation, but there are some parts I can't find the answer to

I used the htaccess tester and some rules were met, but many rules were not. Testers cannot inspect the 'ifmodule' statement and cannot understand 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}/ [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

First, the testers say

RewriteEngine on

Only the last RewriteEngine line is taken into account

If so, why do you add it for every marked part? Can I omit this?

Also, many of the litespeed rules are not met, but I also recognize that there are some parts that it cannot understand/see

Seems to be missing the "Sample Rules" section and rewrite rules set on litespeed .htaccess

Why might they change some parts of the "suggested" example rules? For example my file says

RewriteCond %{HTTP_ACCEPT} "image/webp"

(Tester cannot check because the variable is unknown to them) But example rewrite rules include [or]

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

Also, I'm not sure why they decided to include an if statement to check which module? (What are the advantages of these, or can these "ifmodule" tags be removed?)

Finally, this might be a silly question - is "Really Simple SSL" the same as/formerly known as "Really Simple Security"? If so, should I update my .htaccess to the very simple SSL .htaccess guidelines?

I hope this post can also help others trying to configure their sites.

Answer 1

It seems to me that they decided to install many different WordPress plugins, each adding their own section to .htaccess. It looks like no one is following any plans to build this configuration.

RewriteEngine On is included multiple times because each plugin wants to make sure it is set. Having multiple such statements does no harm other than take up space and processing time.

The

IfModule directive is added by the plugin so that the site does not immediately receive a "500 Internal Server Error" if the required Apache module is not enabled. Rules have no effect without modules, so there is little point in adding checks for modules when you are implementing your own rules on a machine where you know which Apache modules are enabled.

My guess is that these rules were added by an older version of the plugin rather than manually edited. There may be attempts to customize the file, but this is not necessarily the case.

I warn against heavy editing between the BEGIN and END comments. Plugins put these tags there so that they can replace their own rules during the upgrade process. Any changes you make may be overwritten at some point.

I recommend checking out what WordPress plugins the website actually requires. It looks like there may be multiple caching plugins installed and they may be conflicting with each other. I would start by paring down the minimal set of plugins that provide the functionality you need.

You should upgrade all plugins to patch possible security vulnerabilities, and ensure that each plugin's rewrite rules are also updated to the latest.