Hasan CALISIR

I’m closing this issue now as it has been inactive for a while.

I’m closing this issue now as it has been inactive for a while.

Hello @danrancan NPP supports fastcgi_cache_key "$scheme$request_method$host$request_uri"; in default. The default regex will work for you.

Hello @danrancan please send me the screenshot of Status tab.

Hello @tsbega

preg_match('/^KEY:\s+https?(?:GET)?([^\/]+)(?:DESKTOP|MOBILE)(\/[^\s]*)/', $input_line, 

$output_array);
array(3
0	=>	KEY: httpsGETevoarmg.xxxxxx.netDESKTOP/a-escola/
1	=>	evoarmg.xxxxxx.net
2	=>	/a-escola/
)
array(3
0	=>	KEY: httpsGETevoarmg.xxxxxx.netMOBILE/a-escola/
1	=>	evoarmg.xxxxxx.net
2	=>	/a-escola/
)

@tsbega could you send me one of the KEY: lines from the cached content that includes the request_uri?

KEY: httpsGETevoarmg.xxxxxx.netDESKTOP/

KEY: httpsGETevoarmg.xxxxxx.netDESKTOP/request_uri

Hello @coldrealms65

I just wanted to let you know that I’ve released version 2.0.9, which includes important improvements to the cache key regex and other fixes. I’d really appreciate it if you could give it another try and let me know what you think. Your feedback is super valuable.

Thanks so much for your time.

Best~Hasan

Thanks a lot for your awesome review @mrj0b ! I’m so glad the plugin is working well for you. If you ever need help or have any questions, feel free to reach out me. Appreciate your support!

Best~Hasan

@mrj0b

Thank you for confirming that the issue is resolved! I truly appreciate your kind words. If you have a moment, I would be grateful if you could leave an honest review about NPP. Your feedback helps us improve and assist other users. Thanks again for your support!

Hello @tsbega

v2.0.9 live now ! Thank you for your feedback again.

• Relaxed cache key regex options to allow parsing into two capture groups for increased flexibility (Tiago Bega)

my?fastcgi_cache_key?is?$scheme$request_method$host$device$request_uri
My keys looks like this
KEY: httpsGETevoarmg.xxxxxx.netDESKTOP/
KEY: httpsGETevoarmg.xxxxxx.netMOBILE/

Please use the regex below for your custom fastcgi_cache_key to ensure the full functionality of NPP !

/^KEY:\s+https?(?:GET)?([^\/]+)(?:DESKTOP|MOBILE)(\/[^\s]*)/

Let me know if the regex works for you !

Best~Hasan

Hello @mrj0b

I confirm that the long-standing issue prior to version 2.0.5, where users encountered a ‘Not a valid JSON response‘ error, has been completely resolved in v2.0.9

Please update to the latest version to ensure the issue is resolved.

Best~Hasan

Hello @tsbega

The current cache key regex option is restrictive because it expects the $host$request_uri to be returned in a single capture group matches[1]. To improve flexibility and user experience, I will implement an update to version 2.0.9 that will allow users to separate the host and request_uri into two distinct capture groups.

This enhancement will make it easier for users to parse complex cache keys like $scheme$request_method$host$device$request_uri without having to condense everything into one capture group.

With v2.0.9 plugin will:

1. Accept regex patterns that capture the $host in group 1 and the $request_uri in group 2.
2. Automatically concatenate these two groups internally to form the full URL.

Please stay tuned for the next update—thank you for your feedback!

This is weird and I can not re-produce the issue on my environment. To resolve the issue, could you please connect with me via email at [email protected]? This will allow me to get the necessary details and assist you directly with accessing your server and WordPress dashboard to troubleshoot the configuration.

Once I have the required access, I can investigate the issue and provide a solution.

Looking forward to hearing from you.

Best regards,

Hello @mrj0b,

I’ve released version?v2.0.8, Please let me know if it resolves the issues you’re facing.

Best~Hasan

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 3 months, 1 week ago by Hasan CALISIR. Reason: typo
• This reply was modified 3 months, 1 week ago by Hasan CALISIR.