Facebook
Twitter
G J Piper
Regular Pleskian
Username:
TITLE
WP Toolkit "Block access to .htaccess" measure breaks WP permalinks (404) under AllowOverride None
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE
Plesk Obsidian 18.0.78.3; WP Toolkit 6.11.0 (build 10571); AlmaLinux 8.10 x86_64
PROBLEM DESCRIPTION
Server setup: Apache 2.4.37 with nginx as reverse proxy, PHP 8.4 FastCGI served by Apache.
The WordPress docroot <Directory .../httpdocs> uses AllowOverride None (customer .htaccess files are intentionally not honored; the WordPress permalink rewrite is supplied via inline directives in the vhost configuration instead).
With the WP Toolkit security measure "Block access to .htaccess and .htpasswd" applied to a WordPress instance whose docroot uses AllowOverride None, all WordPress permalink URLs return HTTP 404 except the home page.
Reverting only that single security measure restores permalinks. Re-applying it reproduces the 404s. This is reproducible on demand.
The measure adds the following block to the generated Apache configuration for the docroot:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} /\.ht[^/]*$ [NC]
RewriteRule .* - [F,L]
</IfModule>
When the docroot's AllowOverride is set to FileInfo instead (so the WordPress .htaccess permalink rules are honored), the problem does not occur. It occurs only with AllowOverride None.
STEPS TO REPRODUCE
1. WordPress instance on an Apache-served Plesk vhost, with the docroot <Directory> set to AllowOverride None.
2. WordPress permalinks set to a non-Plain structure (e.g. Post name, etc).
3. In WP Toolkit > instance > Security, apply "Block access to .htaccess and .htpasswd."
4. Request any non-home permalink URL directly from Apache, with page caching bypassed.
ACTUAL RESULT
HTTP 404 on all URLs except the home page.
EXPECTED RESULT
Permalink URLs resolve normally, as they do when the specific WP Toolkit security measure is reverted.
ANY ADDITIONAL INFORMATION
Workaround: revert "Block access to .htaccess and .htpasswd" on affected instances, OR set the docroot to AllowOverride FileInfo. (which allows .htaccess files to be served)
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM
Confirm bug
TITLE
WP Toolkit "Block access to .htaccess" measure breaks WP permalinks (404) under AllowOverride None
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE
Plesk Obsidian 18.0.78.3; WP Toolkit 6.11.0 (build 10571); AlmaLinux 8.10 x86_64
PROBLEM DESCRIPTION
Server setup: Apache 2.4.37 with nginx as reverse proxy, PHP 8.4 FastCGI served by Apache.
The WordPress docroot <Directory .../httpdocs> uses AllowOverride None (customer .htaccess files are intentionally not honored; the WordPress permalink rewrite is supplied via inline directives in the vhost configuration instead).
With the WP Toolkit security measure "Block access to .htaccess and .htpasswd" applied to a WordPress instance whose docroot uses AllowOverride None, all WordPress permalink URLs return HTTP 404 except the home page.
Reverting only that single security measure restores permalinks. Re-applying it reproduces the 404s. This is reproducible on demand.
The measure adds the following block to the generated Apache configuration for the docroot:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} /\.ht[^/]*$ [NC]
RewriteRule .* - [F,L]
</IfModule>
When the docroot's AllowOverride is set to FileInfo instead (so the WordPress .htaccess permalink rules are honored), the problem does not occur. It occurs only with AllowOverride None.
STEPS TO REPRODUCE
1. WordPress instance on an Apache-served Plesk vhost, with the docroot <Directory> set to AllowOverride None.
2. WordPress permalinks set to a non-Plain structure (e.g. Post name, etc).
3. In WP Toolkit > instance > Security, apply "Block access to .htaccess and .htpasswd."
4. Request any non-home permalink URL directly from Apache, with page caching bypassed.
ACTUAL RESULT
HTTP 404 on all URLs except the home page.
EXPECTED RESULT
Permalink URLs resolve normally, as they do when the specific WP Toolkit security measure is reverted.
ANY ADDITIONAL INFORMATION
Workaround: revert "Block access to .htaccess and .htpasswd" on affected instances, OR set the docroot to AllowOverride FileInfo. (which allows .htaccess files to be served)
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM
Confirm bug
