• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Input Static file handling, 404s & WordPress

In the default setup, WordPress will any 404 for static file extensions. e.g.
https://example.com/test.css (test.css doesn't exist, so the web server will pass it on to index.php i.e. WordPress).

Many times, due to some plugin like Autoptimize, WP Rocket, etc which change paths for css/js while minifying. When these plugins are disabled without clearing other caches. It leads to a lot of 404 errors which are then handled by WordPress. e.g. 1 Page visit links to 10 different css/js assets which do no exist now. This creates immense load on even websites with moderate traffic. Like in my case the a server with 0.2 (15min) load average spiked up to 2.0 (on a 2 core machine).

This can be easily avoided by not passing files with extensions which are static to WordPress.
For reference: How do I skip wordpress's 404 handling and redirect all 404 errors for static files to 404.html?

I tried to enable nginx handles static files but that didn't work as expected. Can this feature be added? Or at least someone please suggest how to implement this in Plesk. I tried to add the rules in .htaccess but it didn't work. The nginx (static) + apache (dynamic) setup is a bit confusing to grasp (due to missing knowledge) even if we understand what role they play in a setup.
 
Not really a Plesk issue - you want to be handling/fixing the 404 asset pointers via WP anyways, not leaving them be.

Anyways - it's because of how WordPress rewrite/permalinks work. The lines:

Code:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Check if a file exists, and if not, rewrite to WP (/index.php). Your assets don't exist, so they are rewriting to be handled via WP.

As fo NGINX - NGINX static processing adds this rule:

Code:
location ~ ^/(.*\.(ac3|atom|avi|bmp|bz2|css|csv|cue|dat|doc|docx|dts|eot|exe|flv|gif|gz|htm|html|ico|img|iso|jpeg|jpg|js|map|mid|midi|mkv|mp3|mp4|mpeg|mpg|m4a|ogg|ogv|otf|pdf|png|ppt|pptx|qt|rar|rm|rss|rtf|svg|svgz|swf|tar|tgz|ttf|txt|wav|webp|woff|woff2|xls|xlsx|zip))$ {
                try_files $uri @fallback;
}

If the requested file ($uri) doesn't exist, it gets passed to @fallback which is handled by Apache. [See part 1 for what happens there].

If you're using the NGINX process static files option, you can create a custom vhost conf template: Changing Virtual Hosts Settings Using Configuration Templates

And change the try_files to not fallback, and return a 404 instead. You'll also need to remove the WPPrettyPermalink rules WP Toolkit is adding, specifically:

Code:
error_page 404 = $sef_entry_point;
 
Back
Top