Support #24812
closed"month" and "day" views stop working
0%
Description
Via, Keeping, Sammy Sharif asks:
I'm having a new issue where the "month" and "day" views stop working after the page is loaded. If you press CTRL+Shift+R and then try to view the month and day views, they'll work fine until the page is done loading, after which you'll only see a loading animation. I think it might be a caching issue on CUNY Academic Commons' end. The solution might be to exclude the /calendar/ path of our website from caching, although I'm not 100% sure that's the fix.
Files
Updated by Boone Gorges about 11 hours ago
I've spent some time and I'm close to having a solution for this. It has to do with some intricacies between the way the-events-calendar handles its REST permission checks and the way that we block REST checks on non-public sites using the rest_authentication_errors filter. I'll post more details later today.
Updated by Boone Gorges about 7 hours ago
- Category name set to WordPress Plugins
- Status changed from New to Resolved
- Assignee set to Boone Gorges
- Target version set to 2.7.1
The AJAX requests were failing because of a 403 response returned by WP on the calls to /wp-json/tribe/views/v2/html. After some investigation, I discovered that the problem is an interaction with the protections put in place in #19775, which are responsible for blocking access to REST endpoints on sites that have blog_public values powered by more-privacy-options. Briefly, we filter rest_authentication_errors to check for these custom values of 'blog_public', and to fail or succeed based on the status of the logged-in user. Critically, we do this at the default priority of 10. This leaves us in a sort of race condition with some of WP core's filters on rest_authentication_errors, specifically rest_cookie_check_errors(), which runs at 100. Under normal circumstances, this doesn't matter, because all rest_authentication_errors checks are complete by the time the endpoint's permission_callback is invoked. But in the case of the-events-calendar, they do something weird: https://github.com/cuny-academic-commons/cac/blob/7a5cbb8128152f346c04c9d4f2f4c68546dbb634/wp-content/plugins/the-events-calendar/src/Tribe/Views/V2/Rest_Endpoint.php#L158 In their permission_callback, they call rest_authentication_errors again. This double-call results in improperly cached values being returned in a way that tricks the-events-calendar into thinking that the REST request is coming from a logged-out user (ie, the cookie + nonce auth check has failed rather than not being run yet).
I'm not sure this explains the issue in a 100% clear way, but hopefully it's enough for anyone who runs into this in the future.
The solution is simple: to run our rest_authentication_errors callback later, after core's callbacks: https://github.com/cuny-academic-commons/cac/commit/922f3da683682e95d8534d8177422e89d53ab0ef
This has been deployed on the production site.
Updated by Raymond Hoh about 6 hours ago
But in the case of the-events-calendar, they do something weird: https://github.com/cuny-academic-commons/cac/blob/7a5cbb8128152f346c04c9d4f2f4c68546dbb634/wp-content/plugins/the-events-calendar/src/Tribe/Views/V2/Rest_Endpoint.php#L158 In their permission_callback, they call rest_authentication_errors again.
That explains things to me. I'm not sure why The Events Calendar needs to check the 'rest_authentication_errors' filter manually again, but I guess they have their reasons related to logged-out users that cannot be overcome in another way. Thanks for the write-up and finding the problem, Boone!