• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Weird nginx directive by Plesk team?!?

Martin_Sauer

Regular Pleskian
In all due respect, what does Plesk dev team try to achieve with this snippet?
Code:
        set $no_cache "";
        set $cache_cookie $http_cookie;

        if ($cache_cookie !~ "^\s*$") {
                set $no_cache 1;
        }

Alot of plugins set cookies eg. with Wordpress and they have nothing to do with logged in users. Also Google Analytics sets cookies,...

So basically above snippet means: if there is a cookie, don't cache? Seriously? Either I simply don't understand it or someone was ... while adding that snippet? It bypasses the cache and drastically increases load time for nothing or just because of one simple reason: because... because.
 
afaik the trigger for this snippet is the setting in Plesk Panel > Domain > Apache & nginx Settings > Enable nginx caching or if the setiing is enabled via service plan
please see:

Yeah I am with you. My point yet is:

What is that snippet meant to do?

It stops caching, once a cookie is present. That is pointless! If it is meant to disable caching for logged in users, or for commentators, or... by then you need something completely different, like
Code:
        # POST requests and urls with a query string should always go to PHP
        if ($request_method = POST) {
                set $no_cache 1;
        }

        # Don't cache uris containing the following segments
        if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
                set $no_cache 1;
        }

        # Don't use the cache for logged in users or recent commenters
        if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
                set $no_cache 1;
        }
 
You are absolutely right Martin_Sauer, it is pointless and annoying.
As an solution you can create a custom template (like: /usr/local/psa/admin/conf/templates/custom/domain/service/) and create there a new nginxCache.php file with basically your code as replacement. Dont forget to run the command:


plesk repair web -domains-only

That will update all your sites, works like a charm....
 
Of course already done - thank you for the heads up.

Tbh: I was curious if I missed something, but I couldnt figure out any other use.
 
I also struggle with this default nginx caching settings. it is burdensome to catch cookies added by a new plugin on Wordpress. Some of them have dynamic naming, so good luck to white-list them, if you are not nginx savvy, like myself. Generally speaking, Plesk+nginx do not cache anything and it is complicated to make them work.
I would like to ask Plesk team to fix this behavior somehow.
Thank you!
 
Thank you for your prompt reply.
You are probably referring to this post - WordPress Toolkit - General Discussion.
I see what you mean. Probably, nobody is using nginx caching, since nobody has problems with it's functionality, so nothing's gonna change anytime soon.
Anyways, thank you for your clarification.

Err no. I use nginx caching as part of a 3-layered agent-based caching concept in front of Apache/pagespeed with a CDN at the edge, where my nginx cache settings are used as parameters for CDN caching ;) (meaning I set my cache directives in every header for each type optimized for this theme and configured the CDN to comply to my headers. As a result my nginx can configure the CDN dynamically as needed on the fly.)

While I optimized my setup, the initial question came up. In the end I plain wrote a new nginx conf file via custom config. The default Plesk config for nginx lacks a lot of functionality. Even some basic ones, which imho belong into the backend: expires settings, SSL encryption algorithms, additional cache control/options,...

Why would someone do that?
300-800ms worldwide to onload event with a complex theme (Avada) and slider (Slider Revolution).
 
Last edited:
Back
Top