Configuring Caching

Configuring caching with Tickera matters because event pages, ticket-buy widgets, cart and checkout all need fresh data — a cached “X tickets left” displayed minutes after stock has actually run out is a recipe for double-bookings and angry customers. This guide covers which Tickera pages need to bypass your caching layer (WP Rocket, W3 Total Cache, LiteSpeed Cache, Cloudflare APO, server-level page caches), and the standard exclusion rules.

Caching is an excellent way to make your website faster and reduce server load. But when it comes to an event ticketing system like Tickera, caching needs a careful touch. Your cart, checkout, and ticket data are all dynamic – meaning they change constantly. If those pages get cached, your visitors may see outdated or completely wrong information.

In short: caching is your friend, but only when configured properly.

What can go wrong?

If caching is too aggressive or misconfigured, your website might start behaving in strange ways and you may experience things like:

• Cart not updating after adding tickets
• Checkout getting stuck or looping endlessly
• Wrong event or ticket information showing up
• Duplicate, missing, or unpaid orders
• Problems with logging in to Checkinera and ticket check-in

If this happens, caching is almost always the first suspect.

Pages that should never be cached

Regardless of whether you use a caching plugin or server-side caching, there are certain Tickera pages that must never be cached. Caching them can cause stale ticket data, failed checkouts, or even double bookings.

Make sure the following pages (and their URLs or slugs) are excluded from caching:

• Cart page
• Payment page
• Payment confirmation page
• Process payment page
• IPN (Instant Payment Notification) page
• Order details page
• Event pages
• Pages and posts that contain Tickera shortcodes and/or Gutenberg blocks

Additionally, if you’re using Seating Charts add-on you must exclude any pages that display a Pick your seats button. Caching these pages can lead to incorrect seat availability, unresponsive seat maps, or even allow customers to select seats that have already been reserved.

If you notice that the “Pick your seats” button fails to load or the seat chart appears blank, caching is almost always the reason.

Configuring plugin-based caching

If you’re using a WordPress caching plugin such as WP Rocket, W3 Total Cache, WP Super Cache, or a similar tool, open its settings and look for an option like “Never Cache URLs”, “Exclude Pages”, or “Cache Exclusions.”

Add the following slugs (adjust if your URLs differ):

/cart/
/payment/
/order-details/
/order-confirmation/
/process-payment/
/ipn/
/tc-api/*

Also, don’t forget to include event pages and pages that feature Pick your seats buttons or Seating Charts.

Some caching plugins also offer object caching or database caching. If so, exclude Tickera’s custom post types and tables – especially tc_events, tc_tickets_instances, and any _postmeta entries related to orders or attendees.

Configuring server-side caching

Many modern hosting providers use built-in caching solutions at the server level. Whether it’s NGINX FastCGI, Redis, LiteSpeed, Cloudflare APO, or a custom managed hosting setup, the principle is the same: you need to exclude the dynamic Tickera pages.

Examples

• NGINX FastCGI cache
  Exclude all URLs containing /cart, /payment, /order-details, /process-payment, /ipn, and any pages with seating charts.
• LiteSpeed or LSCache
  Use the “Do Not Cache URIs” field and add Tickera system pages and seat chart pages.
• Cloudflare or CDN-level caching
  Create a rule that sets Cache Level: Bypass for Tickera and event-related URLs.
• Redis object cache or Memcached
  If your host supports object caching, ensure that Tickera’s transients and session data aren’t cached indefinitely. Exclude Tickera’s post types and meta where possible.

Hosts with built-in caching you can’t control

Some hosting providers automatically apply caching at the server level, and you might not even know it’s active. Hosts like WP Engine, HostGator (on some plans), and several managed WordPress platforms use page caching systems that can’t be fully managed from your dashboard.

If you’re on one of these hosts and encounter issues with Tickera’s cart or checkout process, contact their support team and ask them to:

1. Exclude all Tickera system pages (listed above) from page caching.
2. Ensure the following cookies are not being cached:
   tc_cart_seats_COOKIEHASH
   tc_cart_COOKIEHASH
   tc_order_COOKIEHASH
   cart_info_COOKIEHASH
   tc_cart_seats_COOKIEHASH
   tc_discount_code_COOKIEHASH

Note: replace COOKIEHASH with your site’s unique cookie hash. You can find it under Tickera -> Settings -> System -> WordPress Environment 

Clearing cache after updates

It’s always a good idea to clear your cache whenever you:

• Install or update Tickera or its add-ons
• Change ticket or event details
• Modify checkout, cart, or payment pages

This ensures all scripts, templates, and shortcodes refresh immediately for visitors.

If you use Bridge for WooCommerce

If you’re running Tickera alongside WooCommerce using the Bridge for WooCommerce add-on, the same caching principles still apply. The difference is that WooCommerce manages the checkout process and most caching plugins and hosts already recognize and exclude WooCommerce pages automatically. Still, double-check that all Tickera-related shortcodes and event pages remain excluded.

Wrap up

A properly configured cache keeps your website lightning fast without breaking your ticketing system. Just remember one simple rule: cache your content, not your checkout.

If you’re unsure whether caching is causing problems, try disabling it temporarily and run through a full ticket purchase. If everything works fine afterward, you’ve found your culprit.

And as always, if you get stuck or aren’t sure how your hosting cache is set up, feel free to reach out to our support team.

Related questions

• Dashboard takes too long to load
• Shortcodes not loading content
• General settings