Hi there Hristo,
Thanks for reaching out and our apologies for any disruption this has caused for your customers and indeed your team. Fixing this is a high priority to us and, all being well, we should have a solution available early next week ??
To give some background to the problem, we have a number of features that basically rely on batch processing (importing events is a great example: rather than force the user to keep a browser tab open while this happens, we offload it to a ‘background task’). Under the hood, this can be handled in one of two ways: either by using WP async requests or else by using more traditional scheduled events (WP cron).
What we’ve found, though, is that while in some hosting environments either method will work just fine, in others that may not be the case. To that end, we introduced a system that tries to determine if async requests (our preferred method) will work successfully and, if they do not, we fallback to scheduled events (WP cron).
Unfortunately, it seems that the code which handles this test is in some cases misfiring and triggering a larger number of requests that would be ideal. Again, we hope to provide a definitive fix as soon as possible.
As an interim solution, your customers can install and activate this plugin (it’s literally just a line of code – we wrapped it in a plugin simply to make it easier to share). This should have the effect of turning off the feature detection code and will force The Events Calendar to prefer WP cron over async requests.
I hope that explains things but please don’t hesitate to reach out should you need more information. Our sincere apologies for any frustration this has caused.
