[BUG] Cache expiration header in additional Nginx directives does not get applied

Follow

Comments

16 comments

  • Avatar
    Unknown User

    What is the exact change because the current configuration is for a domain PHP handler is set as "FPM application served by Apache". And also the workaround states the same thing: 

    Change PHP handler to "FPM application served by Apache" in Domains > example.com > Hosting settings .

    0
    Comment actions Permalink
  • Avatar
    Lev Iurev

    Hi @gli Pançi, do you mean that handler is set to "FPM application served by Apache" and cache expiration is enabled in nginx  but cache expiration headers are not returned by server?

    0
    Comment actions Permalink
  • Avatar
    David McLaughlin

    I have FPM application served by Apache and nginx in proxy mode.

    Despite the change I never see the cache-control header.

    0
    Comment actions Permalink
  • Avatar
    Anna Morozyuk

    Hi @David,
    If expire headers are not working with Apache, another reason might be involved. Please submit request to a support in order to investigate it thoroughly: https://support.plesk.com/hc/en-us/articles/213608509-How-to-submit-a-request-to-Plesk-support- 

    0
    Comment actions Permalink
  • 0
    Comment actions Permalink
  • Avatar
    Nikita Nikushkin

    Hi @Matthias,

    Thank you for the provided way!

    I added a link to this article in the "Additional information" section in order to help others, who have the applied Hotlink protection security measure in WordPress as you, to resolve the issue

    0
    Comment actions Permalink
  • Avatar
    Mikhail K

    Looks like it works fine once "Hotlink protection" is disabled. Spent about 1 hour trying to fix it on a new domain - didn't suspect Plesk initated update. Just in case, I got 3.6.1-1603 of WP Toolkit and Version 17.8.11 Update #40 of Plesk.

    0
    Comment actions Permalink
  • Avatar
    Alexandr Redikultsev

    Hi @Mikhail Krivoshein,

    You hit another bug here that is documented on the following link: https://support.plesk.com/hc/en-us/articles/360014674853-Additional-nginx-directives-Leverage-browser-caching-are-ignored-for-WordPress-website

    its still not entirely fixed though, but will be fixed soon!

    0
    Comment actions Permalink
  • Avatar
    Rafal Kukla

    Hey guys, 

    Not sure if the fix has been released yet,

    I've got fresh version of Plesk, fully updated, and expiry headers are not being applied, not only in WordPress, but in any site, including static HTML. 

    If you could give me an update. 

     

    Thanks

    0
    Comment actions Permalink
  • Avatar
    Ivan Postnikov

    Hello @Rafal,

    Indeed, it is not fixed yet. It is planned to be fixed in the next major Plesk release.

    For now, please, use the workaround specified in this article.

    0
    Comment actions Permalink
  • Avatar
    Rafal Kukla

    I'm afraid this isn't possible, entire Hosting environment is configured for NGINX. 

    Any ETA on the next Plesk release? 

    0
    Comment actions Permalink
  • Avatar
    Ivan Postnikov

    @Rafal,

    Right now there is no precise ETA for the release.

    After the fix will be ready this article will be updated with the corresponding information.

    Additionally, the description of releases and fixed issues may be found here: https://docs.plesk.com/release-notes/onyx/change-log/

    0
    Comment actions Permalink
  • Avatar
    Tim Hosking

    Seriously, when is this going to be fixed? Serving the site from Apache behind nginx is not an option as we have quite a number of production sites being served directly by nginx that have been heavily optimised and tested using pagespeed. The work involved in reconfiguring and re-testing them to run Apache behind nginx is unthinkable.

    0
    Comment actions Permalink
  • Avatar
    Anton Maslov

    Hello Tim, we don't have ETA at this moment.

    0
    Comment actions Permalink
  • Avatar
    Adrian

    Anton Maslov Ivan Postnikov we desperately need this bug fixed, as it has a detrimental impact on the website performance scores. This bug has been going on for nearly 1 year now, why does it take so long to fix it for us using nginx?

    0
    Comment actions Permalink
  • Avatar
    Anton Maslov

    There are workarounds by using Apache as well as alternative Wordpress plugins/solutions to use cache, thus priority for this bug is low. We don't expect this bug to be fixed in nearest time.

    0
    Comment actions Permalink

Please sign in to leave a comment.

Have more questions? Submit a request