User Front End Editor Bar > Performance > Purge Current Page > Not Allowed

  • Resolved stevenwillett

    (@stevenwillett)


    6 years, 3 months ago

    Hi,

    With W3 Total Cache plugin we are seeing a scenario I am struggling to debug.

    Navigate to a page on the front end of the website as a logged in administrator, then using the editor bar shown along the top (when enabled) I navigate to Performance > Purge Current Page Cache and get the following notification:

    Sorry, you are not allowed to access this page.

    Issue 1)
    I initially suspected directory permission, however even after setting wp-content to 755 to try to resolve and then work back, I still get the same notice even after flushing all caches and removing all cookies for the active session.

    After logging back in and repeating the process i still see the same issue.

    Any other ideas to possible root cause?

    Issue 2)
    When i set page cache and others to use Memcached in general settings, it seems to save but when I refresh the page the settings revert back to use disk option?

    Tends to work for a couple of minutes as we have Memcache server all setup and running but unsure again as to why this is reverting on save each time?

    Environment:
    Environment is NGINX on Ubuntu 16.04 with WordPress 4.9.8

    Thanks in advance for any pointers.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Contributor Marko Vasiljevic

    (@vmarko)

    Hello @stevenwillett,

    Do you have Expires: header set for HTML? If so disable it and enable “Set cache control header” with Cache-Control policy: cache with validation (“public, must-revalidate, proxy-revalidate”
    Also, try in the new browser window with removed all caches there.
    I hope this helps.

    Are you using Content-Security Policy (CSP) rules? Just wondering if they might be misconfigured (too restricted). If its not enabled then disregard what i said.

    Thread Starter stevenwillett

    (@stevenwillett)

    Thank you both for your responses, after a quick check.

    @fistfullofcrisco
    No we are not using CSP rules.

    @vmarko
    Tried in a fresh alternative browser and flushed all cookies, session cookies and flushed the browsers cache fully to no avail.

    We are using expires config option with NGINX yes, see below, however this is not defined for the HTML? 

    
location ~*  \.(css|js)$ {
    expires 365d;
    access_log off;
    add_header Cache-Control "public, must-revalidate, proxy-revalidate";
}
location ~*  \.(jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
    expires 2w;
    access_log off;
    add_header Cache-Control "public, must-revalidate, proxy-revalidate";
}

    I notice when checking the headers you are right @vmarko we appear to have HTML header caching being set, but not at the NGINX level?

    
HTTP/1.1 200 OK => 
Date => Thu, 27 Dec 2018 08:43:11 GMT
Content-Type => text/html; charset=UTF-8
Connection => close
Set-Cookie => valid-token-goes-here; Expires=Thu, 03 Jan 2019 08:43:11 GMT; Path=/
Server => nginx
Vary => Accept-Encoding
Link => ; rel=shortlink
Last-Modified => Thu, 27 Dec 2018 08:38:03 GMT
Expires => Thu, 27 Dec 2018 09:38:03 GMT
Pragma => public
Cache-Control => max-age=3292, public
ETag => "8c35806851f38dac8c8b74a2639bdacc"
X-Powered-By => W3 Total Cache/0.9.7

    Clearly W3 Total Cache (plugin) managing this from the looks of it, I will check the settings int eh plugin.

    I will also look into Cache-control policies based on this pointer @vmarko, thanks again.

    • This reply was modified 6 years, 3 months ago by stevenwillett.
Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘User Front End Editor Bar > Performance > Purge Current Page > Not Allowed’ is closed to new replies.