pinoooo
Forum Replies Created
-
Thanks for this additional explanation.
Despite having the File-based Caching option turned on, the advanced-cache.php file was missing. Disabling and enabling the File-based Caching option resolves the issue. Thank you!Thanks for your explanation. I was curious about this because somehow the advanced-cache.php drop-in disappeared for me. (probably when deactivating and activating the plugin)
I manually reinstalled SGO (upload sg-cachepress.zip), but this drop-in is not coming back either?
I also checked the folder /wp-content/ There is also no deactivated (renamed) drop-in present here.Same problem here. Deleting the sgs_encrypt_key.php file solved it.
Can I disable the Rest API for ‘for Non-Admins’ or even “Disable When Logged Out.”? Of does this also effects functions of SG plugins? See step 3: https://perfmatters.io/docs/disable-wordpress-rest-api/
I did not test it yet, but in new 7.1.3: ‘Improved Password Protected pages excluded from File-Based caching by default’
Correct, I got the same response from SG Support last March:
The cause of the issue is that after authenticating on ABC.com/DEF, the website loads the page with the exact same URL and no ‘no-cache’ headers are passed. Thus, the page with the password prompt is simply served again, from the cache.
In order to resolve the issue, we’ve excluded the URL from being cached by using the ‘Exclude URLs from Caching’ functionality of the SiteGround Optimizer plugin. You may need to flush your browser’s cache before testing the page on your end.
Generally, pages that should not be cached are serving a ‘no-cache’ header, which our plugin honors and does not cache the page. Another part of the issue is that both the password-protection page and the content page it shows, are using the exact same URL, which is generally not a good practice. If you add such a header to the password-protected page, you can then enable the file-based caching for it, however, it will still not be cached due to the ‘no-cache’ header.
Feel free to test out different password-protection plugins and features in order to find the one that best suits your needs.
- This reply was modified 2 years, 5 months ago by pinoooo.
Update for people following this topic:
The SiteGround Optimizer plugin was patched on the testing site and now the cache should be automatically purged shortly after a scheduled post goes live. The patch is expected to be included by default in one of the plugin’s next updates.
Thanks for looking at this problem. I use Custom Post Types.
I will contact customer service tomorrow. Are there any specific things you want to know? (Actually, the steps are no different than described above) Or to whom do I address the ticket?I am using WP 5.9.3 with SGO 7.0.9.
When I choose “Publish immediately”, everything is fine: The cache is purged and the new post is visible on the homepage.
When I schedule a new post, only 1 variable changes. I click next to ‘Publish immediately’ on the ‘edit’-button and select the desired time. When the desired time is reached, the new post is not immediately visible on the homepage. This can take up to 12 hours, when SGO flushes the cache again.
(In the meantime, the new post/page is visible when I’m logged in.)This has worked in the past. Unfortunately, I don’t know which version number.
Thank you!
Is it possible to send a PM? In some cases the password protected page will be accessible without a password. So I cannot post it in public.
I’ve been having the exact same problem for a few weeks now. Unfortunately, I haven’t had time to dig deeper into it yet. No major changes except turning on file based caching. Probably the same cause….
Thanks for your update. This works!
Maybe an idea to get an automatic notification when this occurs? I saw this now by accident.