Project

General

Profile

Actions

Support #24812

closed

"month" and "day" views stop working

Added by Marilyn Weber 1 day ago. Updated about 6 hours ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
WordPress Plugins
Target version:
Start date:
2026-04-09
Due date:
% Done:

0%

Estimated time:
Deployment actions:

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

Actions #1

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.

Actions #2

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.

Actions #3

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!

Actions

Also available in: Atom PDF