• Resolved Jeroen O.

    (@persuader69)


    To change the expiry time of browser caching we added the code to Nginx.
    But in the WP plugin settings we see no changes.
    How can we fix this?
    Thx

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

Viewing 15 replies - 1 through 15 (of 17 total)
  • Plugin Support Kris – WPMU DEV Support

    (@wpmudevsupport13)

    Hi @persuader69

    I hope you are doing good today.

    Could you restart Nginx and see if that helps? Also, can you ask your hosting if there any server-side layer browser caching which does not allow Hummingbird to take over those rules?

    Let us know about the results.

    Kind Regards,
    Kris

    Plugin Support Patrick – WPMU DEV Support

    (@wpmudevsupport12)

    Hi @persuader69

    I hope you are doing well and safe!

    We haven’t heard from you in a while, I’ll mark this thread as resolved.

    Feel free to let us know if you have any additional question or problem.

    Best Regards
    Patrick Freitas

    Thread Starter Jeroen O.

    (@persuader69)

    Hi Patrick,

    It is not resolved yet.

    I will get back to you.

    Bye,
    Jeroen

    Thread Starter Jeroen O.

    (@persuader69)

    Hi Patrick,

    Here is the current code:

    #Force https
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
    # Browser cache
    location ~* ^.+\.(css|js|gif|jpg|png|ico)$ {
        expires max;
    }
    # Rewrite
    if (!-e $request_filename) {
        rewrite ^(.+)$ /index.php?$query_string last;
    }
    
    #klantcontent
    
    location ~* \.(txt|xml|js)$ {
        expires 1y;
    }
    
    location ~* \.(css)$ {
        expires 1y;
    }
    
    location ~* \.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav|mp4|m4v|ogg|webm|aac|eot|ttf|otf|woff|woff2|svg)$ {
        expires 1y;
    }
    
    location ~* \.(jpg|jpeg|png|gif|swf|webp)$ {
        expires 1y;
    }
    
    #klantcontent
    
    # Block abusive requests
    location ~ /\. { return 404; }
    location ~ ^/wp-includes/ {
        location ~ \.php$ {
            return 403;
        }
        try_files $uri $uri/ =404;
        expires 30d;
    }
    location ~ ^/wp-content/uploads/ {
        location ~ \.php$ {
            return 403;
        }
        try_files $uri $uri/ =404;
        expires 30d;
    }

    Is this correct?

    Thx,
    Jeroen

    Plugin Support Patrick – WPMU DEV Support

    (@wpmudevsupport12)

    Hi @persuader69

    This sounds fine,

    Had you restart the Nginx after adding the code?

    Could you let us know which is your hosting provider or is it a self managed server?

    The rule may be correct but sometimes not the location:
    https://www.digitalocean.com/community/questions/leverage-browser-caching-for-nginx
    https://www.digitalocean.com/community/tutorials/how-to-implement-browser-caching-with-nginx-s-header-module-on-ubuntu-16-04

    Best Regards
    Patrick Freitas

    Thread Starter Jeroen O.

    (@persuader69)

    Hi Patrick,

    I will check this with the hosting provider.

    Will get back to you.

    Bye,
    Jeroen

    Plugin Support Patrick – WPMU DEV Support

    (@wpmudevsupport12)

    Hi @persuader69

    Sure, feel free to keep us posted.

    Best Regards
    Patrick Freitas

    Thread Starter Jeroen O.

    (@persuader69)

    Hi Patrick,

    We placed the code in Plesk in de Additional Nginx settings.

    Is this correct?

    Thx,
    Jeroen

    Plugin Support Adam – WPMU DEV Support

    (@wpmudev-support8)

    Hi @persuader69

    We placed the code in Plesk in de Additional Nginx settings.

    It should be fine in most cases but since my colleague already asked: did you also made sure to restart nginx after adding the rules? If it’s Plesk-powered hosting, there should be an option to do this and it’s necessary for nginx to re-read and apply the rules.

    Also, what is the host (or are you running your own VPS/dedicated server or similar) and have you actually contacted them and asked to check if this code in that location is fine?

    It’s always recommended to consult with hosting support because while the code provided by Hummingbird is pretty “universal” and generic, for some hosts it has to be specifically altered and there are also cases when these settings actually cannot be changed at all due to either restrictions on server or specific configuration (e.g. fully integrated custom CDN from the host).

    Best regards,
    Adam

    Thread Starter Jeroen O.

    (@persuader69)

    Hi Adam,

    Thanks for your message.

    We asked our hosting provider to add the code and they did.

    Also they restarted NGINX.

    The code used is in an earlier message above and you confirmed it to be correct.

    What is the next step we can take to fix this?

    Thx,
    Jeroen

    Plugin Support Kris – WPMU DEV Support

    (@wpmudevsupport13)

    Hi @persuader69

    I’m afraid you will need to speak with your hosting is there any other hosting modules or rules which could affect this. Also what Adam asked above:
    What is the host (or are you running your own VPS/dedicated server or similar)?

    Kind Regards,
    Kris

    Thread Starter Jeroen O.

    (@persuader69)

    Hi,

    The website runs on its own server with Plesk 18.0.35 on CentOS 7.9 with currently PHP 7.3.28 as active version.
    Under water this works with httpd as web server, with nginx as reverse proxy server in between, these settings are made there.

    How can we fix this?

    Thx,
    Jeroen

    Plugin Support Predrag – WPMU DEV Support

    (@wpmudev-support1)

    Hi @persuader69,

    Browser Caching is a server side thing and Hummingbird tries to apply the .htaccess rules for Apache servers or provides code needed for NGINX server.
    However, it’s up to the server settings to allow these changes to be made via these rules which is, unfortunately, not always the case.

    There’s not much else we could do from our end I’m afraid, your hosting provider should be able to give you more information about this and if their server requires some unique rules in order to enable Browser Caching.

    Cheers,
    Predrag

    Thread Starter Jeroen O.

    (@persuader69)

    Hi Again,

    The problem is not solved at this time.

    This is the code but is not working. (Code is below message)

    Do we need the change the order of the code?

    The provider has done everything they can do.

    What problems or disadvantages does the currently active cache setting have?

    Thx,
    Jeroen

    #Force https
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
    # Browser cache
    location ~* ^.+\.(css|js|gif|jpg|png|ico)$ {
        expires max;
    }
    # Rewrite
    if (!-e $request_filename) {
        rewrite ^(.+)$ /index.php?$query_string last;
    }
    
    #klantcontent
    
    location ~* \.(txt|xml|js)$ {
        expires 1y;
    }
    
    location ~* \.(css)$ {
        expires 1y;
    }
    
    location ~* \.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav|mp4|m4v|ogg|webm|aac|eot|ttf|otf|woff|woff2|svg)$ {
        expires 1y;
    }
    
    location ~* \.(jpg|jpeg|png|gif|swf|webp)$ {
        expires 1y;
    }
    
    #klantcontent
    
    # Block abusive requests
    location ~ /\. { return 404; }
    location ~ ^/wp-includes/ {
        location ~ \.php$ {
            return 403;
        }
        try_files $uri $uri/ =404;
        expires 30d;
    }
    location ~ ^/wp-content/uploads/ {
        location ~ \.php$ {
            return 403;
        }
        try_files $uri $uri/ =404;
        expires 30d;
    }
    Plugin Support Patrick – WPMU DEV Support

    (@wpmudevsupport12)

    Hi @persuader69

    The code looks correct,

    You can try to move the expiration date to the top of your code to make sure it will apply before anything.

    Another workaround is using Cloudflare that has a Free plan, once connecting to Cloudflare you can connect the plugin to this service and set the expiration date at the Cloudflare level.

    https://wpmudev.com/blog/hummingbird-cloudflare-integration/

    The only issue not using 1Y is Google or Performance tests complaining about the time.

    Most of the files are set correct to 365 days https://www.giftofspeed.com/cache-checker/ some external files not but this is because we can’t control them, so you should be good too.

    Best Regards
    Patrick Freitas

Viewing 15 replies - 1 through 15 (of 17 total)
  • The topic ‘Browser caching code added but no change?’ is closed to new replies.