Caching problem with Events Calendar

  • Resolved pascalkellenberg

    (@pascalkellenberg)


    3 weeks, 2 days ago

    Your plugin causes severe issues with website performance and a never ending build up of a cache. I have been using your plugin across multiple websites across 2 years and now I am about to get rid of your plugin in all instances unless a solution is available. Yes I only use the Free plugin to date but no I will not upgrade to a paid plugin if not even your free plugin works properly. It is possible that my clients would want to upgrade in the future to access things like recurring events but given your plugin crashes the websites its a hard sell. So please do not answer telling me I need to pay, its not going to happen unless this is fixed first.

    You would be very well aware of this issue but do not address it in your help forum. My guess is that this is your most common problem, yet you choose to not talk about it. Every time a website visitor looks at any one of the events created, a cache on that event starts to build and it just keeps building. The more events you have the more compounded the problem is. Websites like the one I copy in above for your reference have real life size of below 2 gigabytes. Thanks to the endless cache build up caused by your plugin the website bloats infinitely. I limit Cpanel sizes in this case to 12 gig and when it fills that, the website obviously stops functioning.

    I am now running a cron job deleting these unwanted cache buildups on a daily basis so at least I do not have to worry when the website will cease working again. But this only partially addresses the issue for the other result is that this plugin eats all your server performance. Unless your WHM has the ability to restrict I/O and other performance values on a particular Cpanel, your plugin will eat all resources your server has available until all your hosted websites are affected. If you can mange the performance indicators on a domain level, the website with your plugin will cease due to performance.

    This is hands down the most idiotic plugin I have ever come across and its only still on some of my websites due to client demand. So – do you have anything to say for yourself? How come you are even still in business given you are constantly undermining the functionality of all websites your plugin is on?

    The page I need help with: [log in to see the link]

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Support Darian

    (@d0153)

    2 weeks, 5 days ago

    Hi @pascalkellenberg

    Thank you for the detailed report — I understand how frustrating it is when a site grows in disk use, needs daily cleanup, and feels slow. We took a close look at how The Events Calendar and Event Tickets handle caching in the current free plugins, and I want to share what we found in plain terms.

    What the plugins actually cache

    The plugins do not store a separate “cache file” on the server for every time someone views a single event. Most caching goes into:

    • Your WordPress database (wp_options — rows named like <code class=””>_transient_tribe_…)
    • Server memory (object cache, if your host provides Redis/Memcached)

    Single event pages vs calendar pages

    When a visitor opens one event page, the plugin mainly reuses small, short-lived data (event details, prev/next links). It does not use the same large “save the whole calendar HTML” cache that applies to calendar views (especially the month view).

    The big HTML caches are aimed at calendar/list views (month view in particular), and only when “Enable Month View Cache” is turned on in Events → Settings → General. That setting is on by default, which can create large database entries — sometimes split across many rows — not unbounded files per event view.

    Why sites can still bloat and slow down

    Your experience (disk filling up, needing a daily cron, heavy server load) can still be real even if the “one cache per event view forever” description doesn’t match how the code works. Common contributors we see:

    1. Large calendar HTML transients in the database (month view cache)
    2. Many expired or leftover transient rows in wp_options (cleanup in the plugin focuses on names starting with tribe_; other names may linger until WordPress removes them)
    3. Calendar embeds that store settings in the database without a built-in expiry
    4. Other plugins or hosting tools (page cache, security logs, backups, debug logs) — often a large share of disk use

    So your daily cleanup may be helping with database transients, which fits what we see in the code, more than an endless pile of per-event files.

    What you can try (no paid upgrade required)

    1. Events → Settings → General — turn off “Enable Month View Cache” and test performance and disk growth.
    2. When you run cleanup, note what is deleted (e.g. <code class=””>_transient_tribe_% in wp_options vs files in <code class=””>uploads vs another plugin’s cache folder). That tells us the real source.

    What we’re not saying

    We’re not dismissing the problem. Heavy event calendars on shared hosting can be slow and can grow wp_options significantly. We also aren’t claiming every issue is caused only by our plugins — a full site audit (transients, uploads, logs, other plugins) is the fairest way to fix it for good.

    Thank you again for raising this — it’s a legitimate operational concern, and the steps above are the most direct ways to address it with the free plugins.

    Plugin Support Darian

    (@d0153)

    2 weeks, 3 days ago

    Hi @pascalkellenberg

    I hope you’re doing well. I just wanted to touch base and check in with you. It’s been a little while since we’ve heard from you. I was just curious if you had the chance to try out the recommendation provided above.

    Let us know if there’s anything we can assist you with.

    Plugin Support Darian

    (@d0153)

    1 week, 5 days ago

    Hi there,

    It looks like we haven’t heard back from you in a while, so I’ll go ahead and close this thread for now.

    If you still need assistance, feel free to reopen this thread or start a new one.

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.