Hello @coldrealms65,
And I notice in the Status page there is this section:
FastCGI Cache Keys
Found Unsupported
Lists this as a specific unsupported type over and over again:
$scheme$request_method$host$request_uri$mobile_device_type
Even though, for this test, my key is verified as the default:
fastcgi_cache_key "$scheme$request_method$host$request_uri";
So something is odd….
The “FastCGI Cache Keys” section on the Status page reflects cache keys detected across all instances on the server, not just the specific WordPress installation you’re currently managing. This means if other sites or configurations on the same server use a different FastCGI cache key format, they will also appear in this section. Same true for Nginx Cache Paths section.
The Status page aggregates data server-wide, so it lists all FastCGI cache keys it finds, even if they are not relevant to your current WordPress instance. This ensures a comprehensive overview of all detected cache types across your environment.
Multiple Instances: If you have multiple WordPress instances with Nginx virtual hosts on the same server, each can have different FastCGI cache setups. The Status page aggregates all detected keys from these instances.
Tip:
You can safely ignore entries for unsupported keys if they are not relevant to your specific site configuration. For each WordPress instance on the server, ensure you set the corresponding Nginx Cache Path and configure a compatible regex that matches the fastcgi_cache_key
used for that instance.
I will note, that the default test works and shows the cached page, but the dd thing is the “found unsupported” even when things appear to work normally with the default
As mentioned earlier, the “Found Unsupported” entries are part of the server-wide status check. These entries might reflect configurations from other WordPress instances or Nginx virtual hosts on the same server, each with different FastCGI cache setups. This does not affect the functionality of your current instance if it’s properly configured.
I ended up deactivating the plugin for now.
I realized where it was getting the erroneous information, It was reading from another site hosted on my server.
Executing at a level that can see other information not limited by the php user (most likely due to shell_exec) makes this whole system far far to insecure to be used in its current state so I removed it.
Have you tested this on a multi-tenent nginx system?
Sorry to hear that! I understand your concern about security in multi-tenant environments but this depend your actual web server setup.
Ensuring a secure and efficient multi-tenant environment requires correctly isolating PHP-FPM (PHP process owner or website user) and Webserver user. Ultimately, it’s in the user’s hands and depends on how the web server is configured.
- Webserver Access Control:
The webserver user should only have read-only access to files.
- Isolation Per Instance:
Run each site under its own PHP-FPM user for complete isolation between WordPress instances.
Please re-consider to read;
Plugin Help tab section for What is the proper PHP-FPM Nginx setup?
Main Development repostitory for Here is the short explanation of proper php-fpm nginx setup
In the NPP Status tab, there is a check for server permission isolation status to warn about current configuration.
Permission Isolation (Optional): Isolated
❗️About shell_exec
While I appreciate your feedback, it’s important to note that NPP architecture currently depends on shell_exec
for efficiency. Rewriting the same functionality in pure PHP would require significant effort and time, and frankly, creating a PHP-based website crawler or bot is not on my agenda right now, especially considering there are already many plugins available for that purpose. If you have serious concerns about using shell_exec
, I would recommend the Nginx Helper plugin, which is incredibly well known and easy to use.
Best~Hasan
-
This reply was modified 4 months, 1 week ago by
Hasan CALISIR. Reason: typo
-
This reply was modified 4 months, 1 week ago by
Hasan CALISIR.