High-traffic event pages create two different workloads: live listings repeatedly request Ticketmaster data, while imported listings repeatedly query WordPress and render the same cards. PI Event Master caches those workloads separately, so performance can improve without forcing every type of content to use the same freshness window.
What PI Event Master caches
Under Caching, version 1.8.14 provides independent controls for:
- Live API events: cached Ticketmaster API results. Each unique query combination has its own transient.
- Imported events: cached rendered HTML for listings built from WordPress event posts.
A city grid, a sports widget, and a postcode search therefore do not overwrite one another. Their parameters produce separate cache entries.
Choose a live-cache expiry based on volatility
The available expiry choices range from 5 minutes to 24 hours. A useful starting matrix is:
| Listing type | Starting expiry | Reason |
|---|---|---|
| Major onsale or fast-changing event | 5–15 minutes | Prioritises freshness during a short, active window. |
| Normal city or category listing | 1 hour | Good balance between freshness, API use, and page speed. |
| Broad discovery or low-change archive | 6–12 hours | Reduces repeated calls where small delays are acceptable. |
| Low-traffic informational page | 24 hours | Suitable only when daily refreshes meet the editorial need. |
Do not set every query to five minutes “just in case.” On a site with many city, genre, and radius combinations, a short TTL can multiply outbound requests quickly.
Imported listings can usually cache longer
Imported events live in your own database and change when posts or settings change. Start at 6 or 12 hours for a busy directory, or 24 hours for relatively static collections. The plugin automatically clears imported listing caches when relevant event posts or display settings change, which reduces the need for extremely short expiries.
Use the transient manager before guessing
The Caching tab lists active piwpt_ transients, their remaining lifetime, and an individual Delete action. It also provides:
- Flush Live Cache for Ticketmaster query caches;
- Flush Imported Cache for rendered WordPress listings;
- Flush All when a complete reset is justified.
Flush only the affected cache type. Clearing everything after every edit destroys useful warm caches and can cause a burst of requests as popular pages rebuild.
When should you flush?
- Flush live cache after changing location, category, affiliate, or live field settings when the old result persists.
- Flush imported cache after a bulk editorial change if automatic invalidation has not refreshed the visible output.
- Flush all after a major configuration migration, not as routine maintenance.
- Delete one transient while diagnosing one specific query.
Administrators can append ?piwpt_nocache=1 to a listing URL to bypass cache during testing. This is safer than clearing every visitor’s cached output just to inspect one query.
Do not confuse listing cache with Developer API cache
Developer licence users have a separate REST API response cache under Developer Settings. It uses its own TTL, supports an administrator cache bypass, and can be flushed independently. Saving or deleting imported events invalidates REST responses so clients do not keep stale data.
A practical high-traffic baseline
- Enable live caching at 1 hour.
- Enable imported-listing caching at 12 hours.
- Use a CDN or full-page cache for complete page responses, but exclude personalised or administrator-only URLs.
- Warm important city pages after a full cache flush.
- Monitor API errors, page response time, transient count, and editorial freshness for a week.
- Shorten only the listings that genuinely require fresher data.
The best cache policy is not the shortest or longest possible setting. It is the longest expiry that still meets the visitor’s expectation for that particular page.
