Resources · Feature guides

Match your brand colours

Site Calendar's default green palette looks clean, but the moment you drop it into a real client site it sticks out. Five minutes in the Appearance tab and your calendar reads as a built-in part of the design — month grid, event chips, list view, ticket buttons, the branded confirmation email, all matching your existing palette.

Why this matters

A calendar that doesn't match the rest of the site looks bolted on. Visitors notice immediately — colours that fight the navigation bar, buttons that don't match the rest of the page, headers in a different style than the body. It's a subconscious signal that the calendar is third-party. On agency-built sites it's worse: every mismatched colour is a deduction from the polish the client paid for.

Site Calendar exposes four colour controls — primary, accent, event-link, and week-view chip — that together govern every visual element of the calendar. Set them once in Site Calendar → Settings → Appearance, and every view (month, week, day, list, photo), every ticket form, every category badge, and the branded confirmation email picks up your palette automatically.

How it works under the hood. Site Calendar emits a small CSS variables block at runtime: :root { --pcal-primary: #...; --pcal-accent: #...; ... }. Every styled element in the calendar references those variables rather than hard-coded colours. Change one variable, and every element using it updates instantly. The same variables are inlined into the HTML emails so confirmation messages match the site.

Before you start

Make sure each of the following is true. If any item fails, fix it before continuing.

  • Site Calendar Lite 1.1.0 or later is active (the Appearance tab was added in 1.1.0).
  • For email colour integration, Site Calendar Pro 1.1.2 or later is also active. Earlier Pro versions ship a fixed dark-green / amber email palette.
  • You have the hex codes for your brand's primary and accent colours to hand. If you don't, grab them from your theme's customizer (Appearance → Customize → Colors) or from your brand guidelines.
No brand guidelines? A two-colour palette is enough — a darker primary for headers and active states, a brighter accent for links and CTAs. Tools like coolors.co generate balanced palettes in seconds if you're starting from scratch.

Step 1 — Open the Appearance tab

In your WordPress admin, go to Site Calendar → Settings → Appearance.

[Screenshot: Settings → Appearance tab showing four colour pickers (Primary, Accent, Event link, Week view chip) with their current hex codes]
Four colour pickers. That's the whole interface — most sites change two, sometimes three, of them.

The four controls each have a colour-picker widget — click the swatch to open WordPress's standard wpColorPicker, type a hex code directly into the field, or pick from the colour wheel. The change is previewed live in the picker, but doesn't save until you click Save Settings at the bottom.


Step 2 — Set the primary colour

Primary is the dominant colour across the calendar. It controls:

  • The month-view header bar (Mon, Tue, Wed... row)
  • The "Today" highlight pill on the current date
  • Active view-switcher tab (the Month/Week/Day toggle at the top)
  • The Subscribe to calendar button
  • Primary buttons throughout the ticket-purchase flow
  • The header bar of the branded confirmation email (Pro 1.1.2+)
  • The Add to calendar buttons on single event pages

Set this to your brand's dominant colour — typically the same hue your site uses for its main navigation, footer, or primary call-to-action buttons. A darker, more saturated value works best because it appears as headers and on coloured backgrounds where contrast matters.

If your brand colour is very light or pastel, set Primary to a darker variant of it (e.g. if your accent is #ffdcdc, set Primary to #b54848). White text on a pale-pink header is unreadable. Aim for at least a 4.5:1 contrast ratio against white — tools like WebAIM's contrast checker verify this in seconds.

Step 3 — Set the accent colour

Accent is the secondary highlight. It controls:

  • Event-link hover states
  • The progress bar on the Attendees capacity gauge
  • Section dividers and subtle UI rules in the admin and front-end
  • The accent rule under the confirmation email header (Pro 1.1.2+)
  • QR-code box border on the branded email (Pro 1.1.2+)

Accent should complement (not match) Primary. Common patterns:

  • Same hue, different lightness — primary #0f4c3a (dark green), accent #3a9d7b (mid green). Conservative, professional.
  • Complementary hues — primary #0f4c3a (green), accent #d4a017 (amber). High contrast, modern.
  • Brand accent — primary is your main brand colour, accent is your call-to-action colour (typically orange, red, or yellow on most modern sites).

Step 4 — Set the event link colour

Event link controls the colour of clickable event titles inside the month-grid cells. By default these inherit your theme's link colour, but you can override here if the calendar needs a different colour from the rest of your site.

Most sites leave this empty (inherit from theme), or set it to the same value as Primary for visual consistency. If you have a very busy theme link colour (bright blue, for example) and want the calendar links to read more subtly, set this to a darker, less saturated variant.


Step 5 — Set the Week view chip colour

Week view chip is the most specific control — it sets the background colour of the small event "chips" that appear in the Week view's time grid. The Week view (Pro only) shows events as coloured blocks pinned to specific hours of the day, similar to Google Calendar's week layout.

If you've added category colours to your events (see Creating your first event step 6), each chip uses its category's colour and the Week view chip setting becomes the fallback for uncategorised events. Most sites leave this as a neutral mid-tone and let category colours do the lifting.


Step 6 — Save and verify

Click Save Settings at the bottom of the Appearance tab. The page reloads and the new palette is live immediately — no cache flush needed on most hosts.

Verify each surface:

  1. Reload the front-end calendar page. Confirm the month-view header row, "Today" pill, and active view-switcher tab all show the new Primary colour.
  2. If you have Pro, switch to Week view and confirm event chips use the configured chip colour (or their category colour where assigned).
  3. Click on an event with tickets attached. The Buy / Register button should use the new Primary colour.
  4. Switch to List view. Event title links should use the Event link colour (or your theme's link colour if Event link is empty).
  5. If you have Pro 1.1.2+ and have configured the confirmation email, trigger a test booking — the email's header bar should match Primary, with accent rules underneath.
You're done. Every calendar view now reads as part of your site. New events, new ticket forms, future confirmation emails — all inherit the palette automatically. No further per-event styling needed.

Category colours (Lite and Pro)

The four Appearance colours govern the calendar's structural elements. To colour individual events differently — e.g. all "Music" events in purple, all "Workshop" events in orange — use the category colour picker instead.

  1. Go to Site Calendar → Events → Categories.
  2. Edit any category (or create a new one).
  3. Scroll to the Colour field and pick the colour.
  4. Update.

Every event assigned to that category now uses its category colour in:

  • The leading dot before event titles in the Month view
  • The chip background in the Week view
  • The fallback tile colour in the List view (for events without a featured image)
  • The filter pill colour on category-filter UI (Pro only)

Category colours stack with the Appearance settings — Primary still controls headers and active states; category colours apply to the individual event records.


Custom CSS for unusual themes

The Appearance tab covers about 95% of theming needs. The remaining 5% is usually a theme that wraps the calendar in unexpected ways — for example, a parent container with an inverted dark background, or a CSS framework that forces all buttons to a specific style.

For those cases, all calendar elements use CSS variables and stable class names. Add custom CSS via Appearance → Customize → Additional CSS. Common overrides:

/* Force calendar text to white on a dark theme background */
.pcal-archive-wrap { color: #fff; }

/* Override the Subscribe button colour entirely */
.pcal-subscribe__btn { background: #ff4081 !important; }

/* Add a subtle box-shadow to event chips */
.pcal-event-chip { box-shadow: 0 1px 3px rgba(0,0,0,0.08); }

/* Hide the Powered by Site Calendar credit (or use the Pro white-label setting) */
.pcal-credit { display: none; }

Use sparingly — the more custom CSS you write, the more you risk breaking when the plugin updates. The Appearance tab values are the supported, upgrade-safe theming surface.


Troubleshooting

"I changed a colour but the calendar still shows the old one"

Hard-refresh the page (Ctrl/Cmd + Shift + R) — calendar pages are aggressively cached on most hosts. If you have a caching plugin (WP Rocket, SG Optimizer, LiteSpeed Cache, W3 Total Cache), purge its cache too. The colour change applies on the server immediately; the delay you're seeing is page-level cache.

"The colour picker won't open / shows as a plain text input"

The wpColorPicker script failed to load. Two common causes: (1) a plugin conflict — try deactivating other admin plugins one at a time to identify the culprit; (2) your admin uses a heavily customised theme that strips default WordPress admin scripts. Switch back to the default admin colour scheme via Users → Profile → Admin Colour Scheme and retry.

"Confirmation email still uses the old green and amber, not my brand colours"

Three checks. First, confirm Pro is on 1.1.2 or later (Plugins → Installed Plugins). Earlier Pro versions ship a fixed email palette. Second, confirm Primary and Accent are saved with hex values (not blank). Third, the change applies to future emails — emails already sent retain their original colours.

"Week view chip colour isn't applying"

If you've assigned category colours to your events, those override the Week view chip setting on a per-event basis. The chip setting only applies to events with no category, or events whose assigned categories have no colour set. Check the events' Categories meta box and the category colour fields.

"Hex code 'invalid' error when saving"

The colour fields accept 3-digit and 6-digit hex codes prefixed with # (e.g. #fff or #0f4c3a). RGB and HSL formats aren't supported. If you've copied a colour from a design tool that outputs rgb(15, 76, 58), convert it to hex first (most browsers' DevTools colour picker shows both formats; or use rapidtables.com/convert/color/rgb-to-hex).

"Calendar text is unreadable on the new Primary colour"

Contrast issue — the Primary colour is too light for white text on top of it. Either darken the Primary colour or, if you must use a pale brand colour, add custom CSS to force header text to a dark value: .pcal-archive-wrap .pcal-cal__head th { color: #1d2327; }. Aim for at least a 4.5:1 contrast ratio.

"I want a different colour per event, not per category"

Not supported in the standard UI — Site Calendar is opinionated about category-based colouring to keep the calendar visually coherent. For one-off accent events, the workaround is to create a dedicated category with the colour you want (e.g. "Featured", "Special"), and assign that category to just the one event. The single-event page can also include a Custom Fields override for advanced uses.


What's next

Stuck? Email support@getsitecalendar.com and we'll help directly. Pro licence holders get priority response.