Resources · Help & diagnostics

Troubleshooting hub

When something isn't working as expected, start here. This page collects the most common Site Calendar issues with a verified fix for each. About 80% of support requests come down to one of four root causes — cache, theme/plugin conflict, missing Pro licence, or stale permalinks — all covered in the five-minute fixes below. Work top to bottom; you'll usually find your answer within the first few sections.

Before you start — the four universal fixes

These four steps resolve the large majority of Site Calendar issues. Run all four before diving into the specific sections below — you'll save yourself a lot of time.

  1. Flush permalinks. Go to Settings → Permalinks and click Save Changes without changing anything. This rebuilds WordPress's URL rewrite rules, which is required after activating Site Calendar or any update that touches URL structure. About a third of "the calendar disappeared" reports are solved by this single step.
  2. Clear all caches. Page cache (SiteGround Optimizer, WP Rocket, W3 Total Cache, LiteSpeed Cache), object cache (Redis or Memcached if your host runs one), and your browser cache. The quickest way to bypass browser cache is to open the page in an incognito/private window — if the issue disappears there, it was a browser cache problem.
  3. Check the WordPress error log. Open wp-content/debug.log. If it doesn't exist, enable it temporarily by setting WP_DEBUG and WP_DEBUG_LOG to true in wp-config.php, reload the broken page, then read the last few entries. PHP errors point at the exact file and line causing the problem.
  4. Test with plugins deactivated. If the previous three fixes haven't helped, deactivate other plugins one by one (caching plugins first, then security plugins, then anything that filters page content). When the issue disappears, the last plugin you deactivated is the conflict.
Most issues are root-causable in under 10 minutes. The single most useful diagnostic is the error log — if you're stuck, paste the last 20 lines of debug.log into your support email and we can usually identify the cause without further back-and-forth.

The calendar isn't appearing on my events page

Symptoms: the page where you placed [pro_calendar] shows nothing, or shows the shortcode as literal text instead of rendering a calendar grid.

Likely causes and fixes

  • Permalinks need flushing — see universal fix #1. This is by far the most common cause.
  • The shortcode is wrapped in a block that escapes it. In the Gutenberg editor, use a Shortcode block rather than a Paragraph block. Paragraph blocks sometimes encode the square brackets as HTML entities, which kills the shortcode.
  • A caching plugin is serving an old version of the page. Purge the cache specifically for the events page URL, or temporarily put the cache plugin into bypass mode and test.
  • Your theme strips shortcodes from page content. Some heavily customised themes filter content before WordPress's shortcode processor runs. Test by switching to Twenty Twenty-Four temporarily — if the calendar appears, your theme is the culprit. See Theme compatibility for theme-specific workarounds.
  • The events page is set as your front page with a custom theme template. Some page-builder themes use templates that don't render the_content() — meaning shortcodes inside the page body never run. Switch the page template to "Default" or "Full width" temporarily to test.

The Subscribe or Add-to-Calendar button is missing

Symptoms: the calendar grid renders correctly, but the "📥 Subscribe to calendar" button below the archive view (or the Google/Outlook/.ics buttons on single-event pages) doesn't appear.

Fix

This was a regression in version 1.1.1.12 only. Upgrade Site Calendar Lite to 1.1.1.13 or later (we recommend 1.1.1.15, which contains additional code-quality improvements). After upgrading, hard-refresh the page and clear your cache plugin.

If the button still doesn't appear after upgrading and clearing cache:

  • Open browser DevTools → Network tab → reload the page → look for a file called ical-injector.js.
  • If it returns HTTP 200, the script loaded — check the Console tab for JavaScript errors.
  • If it returns HTTP 404, a security plugin or .htaccess rule is blocking access to /wp-content/plugins/getsitecalendar-lite/assets/js/. Add an exception in the security plugin, or temporarily disable it to confirm.

"Powered by Site Calendar" credit isn't appearing

This is by design as of version 1.1.1.14. WordPress.org's plugin directory guidelines require attribution credits to be opt-in rather than displayed by default, so the credit no longer appears automatically.

How to enable the credit

Go to Site Calendar → Settings → Appearance, find the Plugin credit checkbox, tick it, and click Save. The credit will then appear below the Subscribe button on archive views. The checkbox is unchecked by default on fresh installs and on upgraded installs alike.


Recurring events don't expand or the recurrence meta box has disappeared

As of Lite 1.1.1.14, the recurrence engine lives exclusively in Site Calendar Pro. If you're running Lite-only, the recurrence meta box won't appear in the event editor, and any recurring events created in older versions will display as a single occurrence on the front-end (their recurrence data is preserved safely in the database but isn't expanded).

What to do

  • You want recurring events back: install Site Calendar Pro 1.1.5 or later. Existing recurrence data will activate immediately — no migration needed, no data lost.
  • You already run Pro but the meta box is missing: check both versions. Pro 1.1.5 requires Lite 1.1.1.14 or later. If the versions don't match, an admin notice appears at the top of the admin and recurrence stays disabled until both are updated. Updating both together via Plugins → Updates resolves the mismatch.
  • You don't need recurring events: nothing to do. Lite handles single events natively and the missing meta box won't affect anything else.

RSVP and ticket issues

"Security check failed" appears when someone submits the RSVP form

The form's nonce token has expired. Nonces last 24 hours by default; this happens when an event page is left open in a browser tab overnight, or — more commonly — when a page cache served a stale version of the form. Reload the event page in a fresh browser tab and the form should work.

If you see this regularly, your cache plugin is too aggressive. Exclude single-event URLs (typically /event/*) from page caching, or set the cache lifetime to under 12 hours.

Confirmation emails aren't arriving

  1. Ask the recipient to check their spam folder first.
  2. Install an SMTP plugin — WP Mail SMTP or Fluent SMTP are both reliable. WordPress's built-in wp_mail() often fails silently on shared hosting because outbound mail from PHP frequently lands in spam or is rejected outright by recipient mail servers.
  3. Once SMTP is configured, send a test email from the SMTP plugin's own test page. If that fails, it's an SMTP/hosting issue, not a Site Calendar issue.
  4. If test emails work but RSVP confirmations don't, check wp-content/debug.log for wp_mail() errors when an RSVP is submitted.

"Sold out" appears when there's still capacity available

Open the event in the editor and look at the Tickets meta box. Each ticket shows current capacity and registered count. If those numbers are wrong (e.g. registered shows higher than reality), it's usually because attendee records were edited or deleted directly in the database, or a payment-gateway race condition created phantom registrations. Re-saving the ticket forces a fresh count from the actual attendee records. As a last resort, manually adjust the capacity number upward to compensate.

Payment fails or buyer is redirected to an error page

First, verify your Stripe or WooCommerce credentials at Site Calendar → Settings → Tickets. The most common cause is test-mode keys in a live environment (or vice-versa). Then check the Stripe dashboard's Developers → Logs section — Stripe records every failed PaymentIntent with a much clearer error message than the redirect target shows.


Brand colours aren't applying to the front-end

You've saved new colours at Settings → Appearance, but the calendar still shows the defaults on the front-end.

Fix sequence

  1. Hard-refresh the page: Ctrl+Shift+R on Windows/Linux, Cmd+Shift+R on Mac.
  2. Purge any CSS optimiser cache — Autoptimize, WP Rocket's "Minify CSS", SiteGround Optimizer's CSS optimisation. CSS optimisers often combine and minify stylesheets, which can strip out the dynamic colour variables.
  3. In DevTools, inspect any element on the calendar and look at the computed CSS. You should see custom properties like --pcal-primary with your saved colour value. If the variable is missing entirely, the dynamic colour stylesheet isn't loading — check Network tab for a 404 on the inline style or a related .css file.
  4. Confirm your theme doesn't have hardcoded calendar colours overriding the variables. Some themes ship with custom calendar CSS that uses fixed hex codes rather than the plugin's variables. See Match your brand colours for the variable reference and theme override guidance.

Venue map iframe is blank or shows "for development purposes only"

Google Maps embeds work without an API key for low-volume use, but Google may rate-limit or watermark them on high-traffic sites.

Diagnostic checklist

  • The venue must have a complete address — street, city, postcode. Incomplete addresses produce a blank embed.
  • Some browsers and ad blockers strip third-party iframes. Test in a clean browser profile or a different browser entirely.
  • If the "for development purposes only" watermark appears, your site has exceeded Google's free embed quota. You'll need to register an API key at the Google Cloud Console. Google's free tier covers most small-to-medium sites; you'll only see charges if you're embedding tens of thousands of map views per month.

Site Calendar Pro won't activate

When you click Activate on Site Calendar Pro and it refuses to activate, displaying a notice about minimum Lite version or missing dependencies, you've hit the version guard.

What's happening

Pro 1.1.5+ requires Lite 1.1.1.14+ because the recurrence engine moved from Lite into Pro in that release. Pro refuses to boot against an incompatible Lite version rather than risk a class-redeclaration fatal error.

Fix

  1. Update Lite first via Plugins → Updates.
  2. Confirm Lite is active.
  3. Then activate Pro.

If the admin notice mentions Lite is missing entirely, install GetSiteCalendar Lite from Plugins → Add New first. Pro depends on Lite for the events post type, settings infrastructure, and shared utility classes — it can't run standalone.


Pro auto-updates aren't appearing

Pro is distributed via your own site rather than WordPress.org, so updates use a custom update channel. When updates don't appear at Plugins → Updates:

  1. Confirm your licence key is entered and active at Site Calendar → Settings → Licence.
  2. Force WordPress to check for updates: Dashboard → Updates → Check Again.
  3. If your host restricts outbound HTTPS requests, whitelist getsitecalendar.com in your firewall or hosting control panel.
  4. Visit Tools → Site Health → Info and look for failed external HTTP requests in the WordPress section. If WordPress can't reach external servers at all, your host has blocked outbound HTTP — contact them to whitelist update servers.
How Pro updates work. When WordPress checks for plugin updates, Pro queries getsitecalendar.com/wp-content/scp-releases/ for a JSON metadata file, compares the published version to your installed version, and surfaces the update in your admin if newer. The actual upgrade uses WordPress's standard zip-replace flow — no special permissions, no FTP credentials, no manual download.

Diagnostic information to include with support requests

When emailing support@getsitecalendar.com, including the following details cuts our response time roughly in half:

  • WordPress version
  • PHP version
  • Site Calendar Lite version, and Pro version if installed
  • Active theme name and version
  • List of active plugins (or a Site Health export)
  • URL of the page where the issue occurs
  • Screenshot or screen recording of the problem
  • The last 20–50 lines of wp-content/debug.log
  • Steps to reproduce — what you clicked, what you expected, what actually happened

The fastest way to gather most of this is Tools → Site Health → Info → Copy site info to clipboard. Paste the result into your email and we'll have everything we need to start diagnosing.


When to email support

Get in touch at support@getsitecalendar.com when:

  • You've worked through the universal fixes and the section above relevant to your issue, and the problem persists.
  • You see a fatal error — white screen of death, "There has been a critical error on this website", or a PHP fatal in debug.log.
  • You suspect a security issue. Mark the subject line SECURITY and we triage it within hours rather than days.
  • You need help migrating event data from another events plugin (Events Calendar, EventOn, etc.).

For licence keys, billing questions, or refund requests, use billing@getsitecalendar.com instead — those go to a different inbox and get answered faster than via the general support channel.

Pro licence holders get priority response. Support emails from sites with an active Pro licence are answered within one business day; Lite-only support is best-effort but typically answered within 3–5 days.

What's next

Still stuck? Email support@getsitecalendar.com and we'll help directly. Include the diagnostic information from the section above.