I currently have a view setup that loops through a custom post type and displays a list of all the posts. A search/filter is used at the top. Each post in the list that is displayed has a link to the individual post. The individual post has been customized to display different content based on the logged in status of the user. Therefore, it is important that the view page and thus individual post entries as well do not cache at all, so that when the user is logged in the correct content is displayed. Currently, this is not working.
When a user is not logged in, and visits the view/listings page, the page is cached. If this user then clicks to view an individual post entry, this view also seems to get cached. Consequently, once the user logs in and returns to the page, this same cached version of the page loads. This is also true if the user tries to revisit the individual post he had previously visited when initially logged out (the same cached version loads, which is the logged out view, even after the user has logged in. However, once the view/listings page is refreshed once, then the correct logged in view displays and things then seem to be in order.
The problem is this is a very common pattern for users on the site so many will repeat their steps to visit the previously visited pages, expecting to see the logged in view. The contradicting logged in versus out views result in a great deal of frustration for them.
How can I ensure these pages do not get cached? This issue only occurs on these pages accessed within the Toolset view/post archive listings page, so I expect it has something to do with Toolset plugin.
Hi Shane, the shortcode being used already contains the cached="off" attribute. The shortcode used is: [wpv-view name="find-ancillary-search-filter-page" cached="off"]. I've reproduced the issue whether the attribute is added or not, it seems to make no difference.
DO you have a caching plugin installed? This could be why the values are not being regenerated. If you do have such a plugin installed, could you disable it and try again?
No caching plugin is installed. Only caching I've found is through Settings > General (see screenshot) which I believe is comes as part of our WordPress hosting plan/configuration with Bluehost. This is set to off.
To reproduce/check for the issue, you are welcome to sign up as a test user here (you can just select the free plan): hidden link
Feel free to refer to the videos again as needed.
It's a very specific pattern, but one that users seem to do frequently, and when they do it can be very confusing for them. Starting on the Search Ancillaries page (hidden link) and not logged in yet, click the "View/Add Ancillary Program" for any of the programs listed, let's say "Compound Pharmacy A" for this example. Once viewing the program page, in the "Ancillary Program Status" section a link prompts you to log in (note: the content on the restriction message may look a bit different than the video, as some content has been tweaked on production site and this is staging environment, but essentially you'll see a "must be logged in" link prompting you to login. Then, once you login, click in the top menu on "Search Ancillaries" to revisit the same listing page. You'll notice the top menu now shows the logged out view ("LOGIN" is in the menu now). If you click the same exact program ("Compound Pharmacy A" again) you get the logged out view still, which tells the user they "must be logged in" once again. When they click this time, they of course go to the login page and this time see that they are in fact "already logged in".
However, going back to the same "Search Ancillaries" page we clicked to view "Compound Pharmacy A" from, if we click another program (say "Allergy Testing and Sublingual Immunotherapy") then the logged in view (correct view) is shown. So, it's only the just visited program page that is impacted along with the actual "Search Ancillaries" page itself, which both show the logged out view.
Refreshing the "Search Ancillaries" pages fixes the issue, if that helps at all to understand what caching/mechanism might be doing this.
Please let me know what you find or any settings/adjustments you may make.
When we recently updated to WordPress 5.0 on our production/main site, it seems it may have done a hard clear of the server cache and the issue seems to have gone away based on some testing I just did. Maybe there is some caching happening that I wasn't able to clear through the Endurance Cache General > Settings cache settings? In any case, it seems the issue may be solved, however if you have any insight into certain caching that happens during regular WordPress updates or other cache settings I'm not aware of that could've helped me when troubleshooting, let me know! Thanks again.
Awesome, happy to see that the issue has been resolved.
Generally as I mentioned our views plugin doesn't have any caching ability. I know that bluehost has inbuilt caching ability so doing this could've cleared the cache.
I'm actually not aware of any definitive action that can be taken to prevent this.
