RewriteRule ^/(.*)$ /${lc:$1} !^(pdf|js|css|png|jpg|jpeg|webp)
You say this "doesn't have any effect", however, this is syntactically invalid ("bad flags argument") and should break with a 500 Internal Server Error!? If not then there maybe another more fundamental problem?
However, this has other issues:
- In
.htaccess
, the URL-path matched by the RewriteRule
pattern does not start with a slash.
- You should only lowercase the URL (ie. call the
lc
rewrite map) if the source request contains an uppercase letter, otherwise you will naturally get a redirect loop.
- The regex
^(pdf|js|css|png|jpg|jpeg|webp)
is matching a string that starts with those characters. You need to (negate) match a string that ends with dot + file extension.
Try the following instead:
RewriteCond %{REQUEST_URI} !\.(pdf|js|css|png|jpe?g|webp)$ [NC]
RewriteRule [A-Z] ${lc:%{REQUEST_URI}} [R=301,L]
Note that this must go near the top of the .htaccess
file before the WordPress code block. ie. Before the # BEGIN WordPress
comment marker.
The RewriteRule
pattern [A-Z]
simply tests that there is at least 1 uppercase letter in the URL-path.
The condition (RewriteCond
directive) excludes URLs that end with any of the stated file extensions (case-insensitive).
Note that the REQUEST_URI
server variable already includes the slash prefix, so this is omitted from the start of the substitution string.
NB: Test first with a 302 (temporary) redirect to avoid potential caching issues.
Instead of excluding a (ever growing) list of known file types, you could instead simply exclude any request that looks like it has a file-extension. (Assuming your WordPress page URLs don't have a file-extension.) eg. a dot followed by 2 to 4 letters/digits at the end of the URL-path. For example:
RewriteCond %{REQUEST_URI} !\.\w{2,4}$
:
The NC
flag is not necessary here since the \w
shorthand character class already contains both upper and lowercase letters.