Hasan CALISIR

Hi @marcoskito,

Just replace the single status guard line in the recipe:

Remove:

if ( $new !== 'publish' || $old !== 'publish' ) return;

Replace with:

if ( $new !== 'publish' ) return;

That’s it — the hook now fires on any transition to publish, covering new posts, drafts going live, and scheduled posts, in addition to the content updates it already handled.

Best~Hasan

nginx.conf (aaPanel): /www/server/nginx/conf/nginx.conf

Already covered with NPP.

https://github.com/psaux-it/nginx-fastcgi-cache-purge-and-preload/blob/d81c2c2e8e0307ed8086a5c95c7e9ebbaa42be84/includes/pre-checks.php#L272

The thing that you need to check are these included to main nginx.conf with wildcards. Becuse NPP follows included paths to parse vhost configs from main nginx.conf.

aaPanel Vhost Dir: /www/server/panel/vhost/nginx
Nginx Vhost Dir: /www/server/nginx/conf/vhost

Are these paths readable by your PHP process owner www?

Best~Hasan

• This reply was modified 1 month, 1 week ago by Hasan CALISIR.
• This reply was modified 1 month, 1 week ago by Hasan CALISIR.

Hello @neikoloves

Thank you for your feedback — I really appreciate it. Since the plugin is still used by a relatively small number of users, feedback and bug reports are limited, so development tends to move a bit slower.

I always follow the development roadmap based on user feedback. Honestly, I haven’t received much feedback from panel-based setups, as many panels and managed hosting providers already include their own built-in solutions for Nginx cache management, and some even implement custom Nginx modules.

NPP is primarily designed for pure VPS-based, self-hosted, and self-managed Linux environments, aimed at system administrators and intermediate-to-advanced technical users.

Regarding the issues you reported on aaPanel: there is nothing architecturally broken on the NPP side. These are related to panel-specific overrides and aaPanel’s own internal design, and can be adjusted accordingly.

As an open-source plugin developer, this is where the challenge begins. There are many environments—open-source panels, paid panels, and managed hosting platforms—and NPP is a completely free core plugin. Ensuring full compatibility across all of them is nearly impossible in practice, as it would require significant ongoing time, resources, and sponsorship.

However, if I choose to focus deep support on a specific panel, I would prefer it to be a fully open-source solution rather than paid or commercial platforms. From a philosophical standpoint, aligning a free open-source plugin with paid services is not the direction I want to take.

To move in that direction, I would likely need to turn the NPP into a commercial or paid product, which is not something I want. As I mentioned, I believe the best approach is to rely on contributions from technically skilled panel teams or users, through GitHub pull requests, all contributions are welcome and appreciated.

P.S: Honestly I don’t know the plugin you mention in bold. If it works for you please continue to use it.

Best~Hasan

sudo chmod 644 /etc/nginx/nginx.conf
sudo -u www-data cat /etc/nginx/nginx.conf | head -n 10

Ok, you just need to keep your live nginx.conf accessible so the plugin can reach it. If you are in a containerized environment and Nginx runs in a separate container, you need to make nginx.conf accessible to the WordPress container. For now just copy live nginx.conf to wordpress container as /etc/nginx/nginx.conf then plugin automatically disable Assume Nginx mode.

To diagnose this further, we need to try some technical workarounds. Since I don’t have access to your environment, it’s difficult to reproduce the issue you’re facing. I can guide you through the steps.

php -r "echo function_exists('proc_open') ? 'enabled' : 'disabled';"

If proc_open enabled on your php env. the error messages produced by nppp_detect_premature_process() in preload.php. We need to bypass this function before assigning any blame.

In preload.php

Find line number 480 and 707

if (function_exists('proc_open') && is_callable('proc_open')) {

And replace to bypass this check temporarily:

if (function_exists('proc_open_fake') && is_callable('proc_open_fake')) {

Now you can try again, assuming you have the technical background to edit the plugin’s core files directly.

Best~Hasan

Hello @kaganvmz

You are welcome. According to your cache_key :

fastcgi_cache_key "$scheme$FIRST_FASTCGI_HOST$request_uri";

The real problem is the $request_method filter.
The plugin has a guard in place to skip non-GET entries (POST, HEAD, etc.) to avoid operating on cache files that shouldn’t be there. These are not represent Nginx cache.

I think the below fix will be enough. Cause, the default NPP Cache Key Regex correctly parsing your key, you don’t need any adjustment in regex, but since $request_method is missing in your key, you need to find and replace all occurrences.

Find (all 5 occurrences):

includes/purge.php
includes/advanced.php
includes/advanced.php
includes/status.php
includes/related.php

// FIND: (breaks Engintron)
if (strpos($key_line, 'GET') === false) {
    continue;
}

// REPLACE: FIXED
if (strpos($key_line, 'POST') !== false ||
    strpos($key_line, 'HEAD') !== false ||
    strpos($key_line, 'PUT') !== false ||
    strpos($key_line, 'DELETE') !== false ||
    strpos($key_line, 'PATCH') !== false ||
    strpos($key_line, 'OPTIONS') !== false) {
    continue;
}

Please let me know fixed now, maybe I miss something else. If works for you I will commit it.

Meanwhile, if you have time to do an end-to-end test of the v2.1.5, I would greatly appreciate it.

Best~Hasan

@doctorproctor

v2.1.5 is out — if you’ve been using a direct download from the GitHub branch, please do a clean reinstall from the official WordPress repository to avoid any potential naming issues.

Best~Hasan