Slava Shevchenko

Hi Hasan,

The fix works perfectly. After applying all 5 replacements, the following blocks are now showing correct data:

• Cache Status: 4,174 pages cached, 100% cache coverage (4,174 cached / 3,387 total sitemap URLs), cache dir size 545.26 MB
• Preload Progress: completed successfully 3,389 URLs processed in 19m 38s, status “Completed”
• Cache List: all entries are correctly listed with HIT status

Previously these blocks were either empty or showing incorrect data due to the $request_method not being part of the Engintron cache key, causing all entries to be skipped by the GET filter.

Happy to do end-to-end testing of v2.1.6 as well. Thank you for the quick diagnosis!

Hello @psauxit thanks for quick update, it works.

I’m running NPP on a server managed by Engintron. Everything works – purge, preload, auto-purge – but the Advanced tab always shows MISS for all cached pages, even when the cache is clearly populated.

After investigation I found the root cause: Engintron uses a non-standard fastcgi_cache_key format:

fastcgi_cache_key "$scheme$FIRST_FASTCGI_HOST$request_uri";

The resulting cache key stored in cache files looks like this:

KEY: httpswebsite.com/about-us

Note there is no :// between the scheme and the host – https is concatenated directly with the domain.

The Cache Key Regex correctly parses the host and URI from this format. However, when the plugin checks whether a cached file exists for a given URL, it computes the MD5 hash of https://website.com/about-us (with ://), while the actual file on disk was stored under the MD5 of httpswebsite.com/about-us (without ://). These produce different hashes, so the file is never found and the status always shows MISS.

Would it be possible to use the raw parsed cache key string (as matched by the regex) for the file lookup hash, rather than reconstructing the URL with ://? This would make the Advanced tab work correctly for non-standard cache key formats like Engintron’s.

Thank you for a great plugin!