hate to say this: **your plugin may’ve deleted my wp-content**

  • Resolved doctorproctor

    (@doctorproctor)


    2 months, 3 weeks ago

    I installed and did simple config with your plugin three of my nginx sites, and confirmed all was working well today.

    **Then, right when I installed a new plugin on the above site, **all** plugins vanished…the plugins subdirectory was totally gone from the wp-content directory.**

    I deactivated your plugin from another site, and THE SAME THING HAPPENED. On the third site I got smart, and turned purge OFF before deactivating. This one deactivated fine.

    How could this possibly be?? I did not edit any of your default settings, other than establishing nginx FastCGI cache directory.

    I’m shaken by this. Please clarify what happened; otherwise I will share a review.

    Jim P.

    The page I need help with: [log in to see the link]

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Hasan CALISIR

    (@psauxit)

    2 months, 3 weeks ago

    Hello @doctorproctor,

    Thank you for your reporting. Could you give me more info about your setup? Specially what did you set the Nginx Cache Directory in plugin settings. And when you faced this issue, on plugin deactivation or plugin deletion or random cache purging? Can you share Status Tab maybe we can get more info from your setup.

    As you read the Help tab you can see there is already a path restriction to prevent such issues.

    Why can’t I use my preferred path for the Nginx Cache Directory?

    The Nginx Cache Directory option has restrictions on the paths you can use to prevent accidental deletions or harm to critical system files. By default, certain paths, like ‘/home’ and other vital system directories, are blocked to safeguard your system’s stability and prevent data loss.

    While this might limit your options, it ensures your system’s security. Recommended directories to choose from, such as ‘/dev/shm/’ or ‘/var/cache/’, which are commonly used for caching purposes and are generally safer.Allowed Cache Paths:

    • For RAM-based: Use directories under /dev/, /tmp/, or /var/.
    • For persistent disk: Use directories under /opt/.
    • Important: Paths must be one level deeper (e.g., /var/cache).

    Best

    • This reply was modified 2 months, 3 weeks ago by Hasan CALISIR.
    Thread Starter doctorproctor

    (@doctorproctor)

    2 months, 3 weeks ago

    Thank you for your quick response. I faced the issue in two ways: (a) upon activating a new plugin, and (b) [on another site] upon deactivating NPP.

    I have reactivated it on another site that experienced the problem; here is a screenshot of your Status tab. [Note that in the above fatal cases, I had auto purge to ON; I learned in my case to first turn it OFF before deactivating the plugin to avoid the fatal error. This is not evident in the screenshot, but I currently have it off on the site where I reactivated it, to be safe.]

    Now thinking back on that site, I may’ve entered the cache path incorrectly, without the obvious [in our case] .cache final directory, i.e., I may’ve entered

    /var/www/webroot/ROOT

    which is indeed the root of the WP install as you warn against, instead of

    /var/www/webroot/ROOT/.cache

    But why is there no code to prevent such fatal deletion in such cases?

    Thank you,

    Jim P.

    Plugin Author Hasan CALISIR

    (@psauxit)

    2 months, 3 weeks ago

    You’re welcome — I understand the problem clearly.

    You can be sure that if this issue were directly caused deeply by the plugin and affected many people, I’d be ready to take it down immediately until it’s fixed. However, from what I can see, what you experienced is an extreme edge case related to the cache directory configuration.

    In short, while /var is an allowed cache path in the plugin, in your setup it also contained the root of the WordPress installation. Since that webroot was configured as the cache directory, the plugin effectively allowed the site’s webroot to be used as the cache directory as well — which ultimately led to the data loss.

    I’ve made an urgent fix for this case here If you’re able to apply the patch immediately, please let me know whether it resolves the issue.

    Thank you for your great contribution, will mention in v2.1.5

    Best

    Thread Starter doctorproctor

    (@doctorproctor)

    2 months, 3 weeks ago

    OK, I’ve deleted existing NPP, uploaded new from .zip and activated, set path to:

    /var/www/webroot/ROOT/.cache

    Turned auto purge to ON. Then installed a random plugin and activated, no issues. Then deactivated, no issues. So the terrible behavior of yesterday is possibly fixed. [And the path is fully specified.]

    I’ll continue to test, but we can mark as resolved for now.

    Thank you for your quick/thorough attention; yes, that directory setup is what my host did and what I am working with.

    Jim P.

    Plugin Author Hasan CALISIR

    (@psauxit)

    3 weeks, 1 day ago

    @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

Viewing 5 replies - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.