I think the directive in .htaccess is inherited by subfolder The mod_rewrite directives in the root .htaccess file are not inherited by the /blog/.htaccess file (by default). You would need to specifically enable mod_rewrite inheritance, however, this probably adds unnecessary complexity. I try to modify the .htaccess under /blogs/ by adding the above directive again. … Read more
Yes, basically debug.log, but without deny, with 404 Yes, that directive will serve a “404 Not Found” when attempting to request debug.log. |log? However, because of the ? in the above regex, it will also block debug.lo. Is that intentional? In fact, if that is intentional then you could simply remove the g? part – … Read more
The nginx equivalent of RewriteCond %{REQUEST_URI} ^.*wp-content/uploads/restricted/.* RewriteRule ^wp-content/uploads/(restricted/.*)$ dl.php?file=$1 [QSA,L] will be the location ~ ^/wp-content/uploads/(?<file>restricted/.*) { rewrite ^ /dl.php?file=$file last; } If you want to apply this to several folders under /wp-content/uploads, use location ~ ^/wp-content/uploads/(?<file>(?:restricted1|restricted2|restricted3)/.*) { rewrite ^ /dl.php?file=$file last; } I don’t think there can be any other solution for nginx … Read more
RewriteRule ^stores/(.*)/$ /stores/$1-coupon-codes [R=301,NC,L] You can perhaps use a negative lookahead assertion to exclude URLs that already contain -coupon-codes from being redirected again, thus preventing a redirect-loop (which I assume is what’s happening here). For example: RewriteRule ^stores/(?!.*-coupon-codes)(.+)/$ /stores/$1-coupon-codes [R=301,NC,L] The negative lookahead (?!…) causes the pattern match to fail when the URL already contains … Read more
Header unset Vary This is probably a workaround for a supposed bug in Apache (#58231)*1 that could prevent certain caching proxies from caching the response when the Vary: Host HTTP response header is set. Apache might be setting this automatically when querying the HTTP_HOST server variable in a mod_rewrite RewriteCond directive (or Apache Expression). *1 … Read more
After struggling with the issue for several days here are the steps that I took to finally overcome the problem: Reset the .htaccess to default values(no luck) Add above values to .htaccess in order to disable leverage browser caching(no luck) Contacted my hosting provider and asked them to disable any potential caching policy on my … Read more
You can add a rewrite rule to map to one of those pages with something like this: add_action( ‘init’, function() { add_rewrite_rule( ‘myparamname/([a-z0-9-]+)[/]?$’, ‘index.php?myparamname=$matches[1]’, ‘top’ ); } ); The first parameter of add_rewrite_rule is a regular expression to match a URL. The second parameter is an index.php non-pretty permalink URL, the URL parameters map directly … Read more
There are at aleast two ways you can block other user agents and allow only a few. This can be done by editing the .htaccess file in the root directory of your WordPress website. Option 1 Using mod_rewrite, add the code below at the top of your .htaccess file. <IfModule mod_rewrite.c> RewriteEngine on RewriteCond %{HTTP_USER_AGENT} … Read more
To effectively disable that condition for that one URL-path, you will need to add another rule immediately before the rule in question. ie. before the # Abuse Agent Blocking comment. For example: # Allow an empty User-Agent for requests that start “/wp-content/uploads/xmls” RewriteCond %{HTTP_USER_AGENT} ^$ RewriteRule ^wp-content/uploads/xmls – [S=1] # Abuse Agent Blocking RewriteCond %{HTTP_USER_AGENT} … Read more
I’m honestly struggling to comprehend this failure state – I believe I’ve reproduced the issue locally, and in my testing the RewriteRule directive hits but then WordPress processes the original input, resulting in a fairly catch-all attachment rewrite producing a query for a non-existent attachment. I may continue playing with it to try and figure … Read more