Title: SDAweb Calendar Sync for Google Calendar Author: rstake Published: 15. 5. 2026 Last modified: 25. 5. 2026 --- Prohledat pluginy ![](https://ps.w.org/sdaweb-gcal-sync/assets/icon.svg?rev=3533428) # SDAweb Calendar Sync for Google Calendar Autor: [rstake](https://profiles.wordpress.org/rstake/) [Stáhnout](https://downloads.wordpress.org/plugin/sdaweb-gcal-sync.0.13.4.zip) * [Podrobnosti](https://cs.wordpress.org/plugins/sdaweb-gcal-sync/#description) * [Hodnocení](https://cs.wordpress.org/plugins/sdaweb-gcal-sync/#reviews) * [Instalace](https://cs.wordpress.org/plugins/sdaweb-gcal-sync/#installation) * [Vývojáři](https://cs.wordpress.org/plugins/sdaweb-gcal-sync/#developers) [Podpora](https://wordpress.org/support/plugin/sdaweb-gcal-sync/) ## Popis SDAweb Calendar Sync pulls events directly from the Google Calendar API and renders them on your site through a Gutenberg block, a shortcode, or a classic widget. All three share one render pipeline so output is identical regardless of how you insert a calendar. #### Six views, one render pipeline * **List / Agenda** — chronological, optionally grouped by day, week, or month * **Month grid** — classic 7×6 calendar with multi-day event ribbons spanning across cells, today highlight (cell or whole-column style), optional ISO 8601 week-number column, and per-feed pastel chips * **Card grid** — upcoming events as styled cards, responsive * **Week** — 7 day columns, today highlighted * **Day** — single-day agenda * **Mini-month** — compact dot-density grid for sidebars and widgets, with a tap- to-expand event panel showing today + next upcoming events and a „Load more“ button All views share the same data layer, the same CSS-variable system, and the same accessibility baseline. Switch between them with one setting, or expose a visitor- facing view-toggle pill so visitors can switch themselves. #### Smart UX out of the box * **Hover popover on event chips** (Month, Week, Mini) — a floating card with date, time, location, calendar, recurrence summary, and a click-through link. Desktop hover + keyboard focus only; touch users keep direct click-through. * **Mobile auto-degrade Month Mini** — the full grid is hidden under ~600px and replaced with the compact Mini-month view; one wrapper, two layouts, no JS swap. * **ICS subscribe dropdown** — one-click hand-offs to Google Calendar (web), Apple Calendar / Outlook (webcal), Android Google Calendar app (intent), and Copy-link with toast confirmation. Mobile becomes a bottom sheet. * **Live search** + **jump-to-date picker** — optional chrome controls for visitors who want to filter or navigate quickly. * **Multi-day event ribbons** — week-spanning bars with arrow indicators when an event continues beyond the visible row. * **Recurring event indicator** — small ↻ icon with cadence summary in the tooltip(„ Repeats weekly until 31 December 2026“). * **Per-display locale override** — render the calendar in a specific language ( e.g. nb_NO) even when the site language is English. #### Two authentication paths * **API key** — for calendars marked „Make available to public“ in Google Calendar. One field, paste, done. * **Service Account JSON** — for **private** calendars without per-user OAuth. Upload the JSON, share the calendar with the service-account email, you’re set. Credentials are encrypted at rest using a key derived from your site’s authentication salt. They are never echoed back into the admin UI — only the masked value and ( for service accounts) the public service-account email are shown. #### Theme-aware out of the box The plugin reads your active theme’s `theme.json` color palette and uses your `primary`,` accent`, `foreground`, and `background` colors automatically. Per-display overrides let you set custom primary, accent, today-highlight, and link colors and force light/ dark mode without touching code. Every design token is exposed as a CSS custom property so a developer can fully restyle the calendar from their theme stylesheet. #### Five built-in theme presets One-click coordinated colour bundles: **Default** (clean blue), **Warm earth** ( cream + deep red), **High contrast** (solid black on white for AAA-stricter sites),** Forest** (deep green), **Sunset** (warm coral + amber). #### Accessibility built in WCAG 2.2 AA baseline with several AAA touches: * Live contrast warnings on every colour picker — the admin UI shows the WCAG ratio against both light and dark surfaces with pass/fail markers as you choose colours * Automatic high-contrast overlay via `prefers-contrast: more` * Focus-visible halo: a 4px white ring behind the primary outline so focus stays visible against any chip background * `prefers-reduced-motion` honored everywhere * ARIA roles and labels on the month grid, navigation, popovers, and view-toggle * Semantic HTML throughout * RTL-aware via CSS logical properties * Tabular numerals for day numbers and time labels so single- and double-digit values don’t drift #### Built for the WordPress.org standard * Block editor first-class — server-side rendered, ServerSideRender preview, all the standard `InspectorControls` * Shortcode and classic widget on the same render pipeline * No bundled core libraries (no jQuery on front-end, no Guzzle, no Carbon, no Monolog) * No third-party authentication relay — your credentials only ever talk directly to googleapis.com * Translation ready via translate.wordpress.org once the plugin is published and indexed (no bundled `.po`/`.mo` — WordPress auto-loads locale files into `wp- content/languages/plugins/` per the WP Plugin Handbook), plurals via `_n()`, JS strings via `wp_localize_script` * Free and GPLv2 #### For developers Extension hooks are documented in `docs/hooks.md` inside the plugin folder. The first-release set includes filters for event data, event URLs, query args, cache TTL, render output, palette resolution, plus actions for refresh and uninstall lifecycle. ### Third-Party Services This plugin connects to the Google Calendar API to retrieve events from calendars you configure. * Service: Google Calendar API v3 * Website: https://developers.google.com/calendar * Terms of Service: https://developers.google.com/terms * Privacy Policy: https://policies.google.com/privacy Data sent: the calendar ID(s) you configure, plus either your API key or a JSON Web Token signed with your service account credentials. Event data is returned to your server and cached locally as WordPress transients. No event data is sent to any third party. The ICS subscribe feature, when enabled, links visitors directly to Google’s public iCal feed (`calendar.google.com/calendar/ical/.../public/basic.ics`) — the plugin does not proxy or store that data. ## Bloky Tento plugin poskytuje 1 blok. * SDAweb Calendar Display events from one or more Google Calendars. Choose a saved display or configure inline. ## Instalace 1. Upload the plugin to your `/wp-content/plugins/` directory, or install it from the Plugins screen in WordPress. 2. Activate the plugin. 3. Go to **Settings SDAweb Calendar Sync** to add your first calendar. 4. Choose API key (public calendars) or Service Account (private calendars), follow the in-app setup guide, save. 5. Create a display, choose a view, and copy its shortcode — or insert the **SDAweb Calendar** block in a page. ## Nejčastější dotazy ### Do I need a Google account to use this plugin? You need a Google Cloud project to generate either an API key (for public calendars) or a service account (for private calendars). The plugin’s Help tab walks you through both setups in 7–8 steps each. Setup is one-time per site. ### Does this plugin send my data anywhere other than Google? No. Calendar data is fetched directly from `googleapis.com` using the Google Calendar API. The plugin does not contact any SDAweb-controlled servers, analytics endpoints, or third-party relays. There is no telemetry. ### Can I display a private (non-public) calendar? Yes. Use the Service Account authentication option. The plugin shows you the service account email; share your private calendar with that email in Google Calendar’s sharing settings, and the plugin can read it. ### How often does the plugin refresh events? A WP-Cron job refreshes registered calendars in the background every 15 minutes. Cache lifetime is configurable upward in the plugin settings (15 minutes is the enforced minimum). You can also click „Refresh now“ on any calendar in the admin to fetch immediately. ### Does it work with caching plugins? Yes — the calendar HTML is part of the page output, so any page-cache plugin caches it like any other content. The cache will refresh on its own schedule. If you need immediate refresh after a calendar change, purge the page cache. ### Can I add multiple calendars to one display? Yes. Each display picks one or more registered calendars and merges them. Events are color-coded by calendar. A multi-feed legend strip can be enabled above the events; chips can be styled solid (single-feed) or pastel (multi-feed legibility). ### Will it work with my theme? The plugin reads your active theme’s `theme.json` color palette automatically, so calendar colors match the site by default with zero configuration. If you use a classic theme without `theme.json` (or want to override), every color is exposed as a CSS variable that you can override from your theme stylesheet. Five built-in theme presets give you coordinated palettes with one click. ### Is the plugin accessible? Yes — built-in. WCAG 2.2 AA baseline includes `prefers-reduced-motion` and `prefers- contrast: more` support, `:focus-visible` outlines with a white halo (visible on any background), ARIA labelling on the month grid, navigation, popovers, and view- toggle, semantic HTML throughout, RTL-aware via CSS logical properties, and live contrast warnings in the colour-picker UI as you choose values. ### Can I show the calendar in a different language than the rest of the site? Yes. Each display has an optional Locale override field — set it to `nb_NO`, `sv_SE`, etc. and that calendar renders weekday names, month names, and built-in labels in that language regardless of the site’s language. Useful when an English site hosts Norwegian-audience content. ### Where are the extension hooks documented? In `docs/hooks.md` inside the plugin folder. The plugin commits to keeping documented hooks stable within a major version. ## Recenze Pro tento plugin nejsou žádné recenze. ## Autoři SDAweb Calendar Sync for Google Calendar je otevřený software. Následující lidé přispěli k vývoji tohoto pluginu. Spolupracovníci * [ rstake ](https://profiles.wordpress.org/rstake/) * [ sdaweb ](https://profiles.wordpress.org/sdaweb/) [Přeložte “SDAweb Calendar Sync for Google Calendar” do svého jazyka.](https://translate.wordpress.org/projects/wp-plugins/sdaweb-gcal-sync) ### Zajímá vás vývoj? [Prohledejte kód](https://plugins.trac.wordpress.org/browser/sdaweb-gcal-sync/), podívejte se do [SVN repozitáře](https://plugins.svn.wordpress.org/sdaweb-gcal-sync/), nebo se přihlaste k[ odběru protokolu vývoje](https://plugins.trac.wordpress.org/log/sdaweb-gcal-sync/) pomocí [RSS](https://plugins.trac.wordpress.org/log/sdaweb-gcal-sync/?limit=100&mode=stop_on_copy&format=rss). ## Přehled změn The most recent releases are listed here. The complete history is in docs/CHANGELOG. md bundled with the plugin. #### 0.13.4 * Fixed: per-display custom colors still reverted to the front.css default blue on the Month view when `mobile_degrade=auto` (the default) — on mobile screens( below 600px) and on swap responses. Cause: Month view’s mobile-fallback path wraps its output in `
` (note the hyphen — not a class on `.sdaweb-gcal`), which `extract_inner_html()`‚s regex doesn’t recognise, so the full nested wrapper landed inside the existing root and the per-display palette inherited from the outer wrapper got overridden by the unscoped `[data-sdaweb-gcal-id]` default rule. Fix: `build_display_id()` now uses a stable slug-based id (`sdaweb-gcal-`) for saved displays instead of `md5(json_encode(config))`, so every wrapper at every nesting level matches the same inline-CSS scope regardless of how the swap response is structured. A version-bump migration (`Installer::maybe_upgrade()`) flushes the render cache once on upgrade so cached HTML with the old md5 ids doesn’t keep producing the bug. #### 0.13.3 * Fixed: the 0.13.2 fix didn’t actually work on browsers that support the View Transitions API (Chrome 111+, Safari 18+, mobile Chrome, mobile Safari). `swap. js` called `document.startViewTransition(apply)` and then dispatched the `sdaweb- gcal:viewchanged` event immediately, but the apply callback runs asynchronously— so the event fired against the OLD DOM, listener scripts re-bound to the about- to-be-destroyed wrapper, and the new wrapper got no listeners. Now `swap.js` awaits the transition’s `updateCallbackDone` promise so the DOM is guaranteed updated before dispatchEvent + screen-reader announce + focus move run. Symptom on affected browsers: Subscribe button (and search box, date-jump, hover popovers, mini-month panel, Month overflow popover) stopped responding after a tab click. #### 0.13.2 * Fixed: interactive widgets inside the calendar (Subscribe button, search box, date-jump picker, event-hover popovers, mini-month panel, Month „+N more“ overflow popover) stopped responding to clicks/hovers after using the instant view switcher. Five JS modules attached their listeners on DOMContentLoaded but never re-bound after swap.js replaced the inner HTML; now each module listens for the existing` sdaweb-gcal:viewchanged` event and re-engages. #### 0.13.1 * Fixed: per-display custom colors reverted to the front.css default blue after the first instant-view-switch on any display. Cause: the REST `/render` endpoint’s` extract_inner_html()` regex required the rendered HTML to start exactly with ` page_url`. No more undefined-variable reference. #### 0.12.6 * Fix: view-toggle and prev/next anchor hrefs inside the REST-rendered partial were being built against the REST endpoint URL (`/wp-json/sdaweb-gcal/v1/render`) instead of the page URL, because `add_query_arg()` with no explicit base falls back to `$_SERVER['REQUEST_URI']`. Invisible to JS users (the swap module parses params from the href query string and ignores the pathname), but would have broken any non-JS path through the swapped HTML and produced incorrect URLs in any context that read raw hrefs (e.g. RSS-style aggregators, accessibility tools that surface link targets). Client now sends `page_url=window.location.href` as a REST param; server validates same-origin and uses it as the base for all toggle/nav anchor URLs. Per-page-URL cache partitioning added to the render cache + ETag so cached responses don’t cross-contaminate across host pages. #### 0.12.5 * **Fix: instant view-swap now works end-to-end.** Three issues from the 0.12.4 verification: (1) `parseLinkIntent` was reading the saved-display slug from ` root.dataset.sdawebGcalId`, which actually holds the synthesised DOM identifier(` sdaweb-gcal-`), not the saved-display slug — REST endpoint correctly rejected it as unknown 400 swap fell back to native nav. Now reads `sdaweb_gcal_id` from the link’s query string (the authoritative source) with the root dataset as a fallback. (2) Hover/focus prefetch’s `.catch()` was returning `null`, which leaked through to `applySwap()` and crashed on `data.html`. Now re-throws so swap()’s own catch handles the fallback cleanly. (3) `applySwap` and `announceToScreenReader` gained null guards as defense-in-depth so any future malformed payload bails gracefully instead of throwing. The `pushState` URL is now also correct (it uses` params.slug`, which is now the proper value). #### 0.12.4 * **Fix: instant view-swap now actually works.** Root cause was MIME-type — LiteSpeed( and many other hosts without `.mjs` in their MIME map) served the script module as `application/octet-stream`, and browsers silently refuse to execute modules whose Content-Type isn’t a JavaScript MIME type. No error logged (the refusal happens before any module code runs), so symptoms were „module file present, all bytes correct, zero console errors, no click interception.“ Renamed `swap. mjs` `swap.js`. WordPress’s script-modules API adds `type="module"` regardless of file extension; the `.js` extension is universally JS-MIME-mapped on every host. Diagnosed via Claude-for-Chrome inspection of the live response headers on stavdal.me. * Also in 0.12.4 (rolled forward from a 0.12.3 test build that never shipped to wp.org): view-toggle anchors now carry `data-sdaweb-gcal-view-toggle=""` in addition to the existing BEM class. Swap module’s click delegate matches by either — defense in depth against future class refactors or theme-side class manipulation. Diagnostic logs from 0.12.2 remain gated by `?sdaweb_gcal_swap_debug =1`. #### 0.12.2 * Diagnostic: instant view-swap module now emits gated console logs at every decision point (boot, target query, listener attachment, click match, intercept). Enable by appending `?sdaweb_gcal_swap_debug=1` to the URL, or by setting `window.SdawebGcalSwap. debug = true` before the module loads. Silent by default — no production impact. Surfaces the cause of „module loads but clicks fall through to full-page navigation“ reports without requiring code changes for diagnosis. #### 0.12.1 * Closing v0.12.0 gaps against the brief: REST response now includes `cache: { hit, age_seconds }` field derived from Render_Cache hit/miss state; `Link: ; rel="canonical"` header so caching layers indexing the JSON point back to the human site; `swap:render:abort` diagnostics event via `connection_aborted()` on client disconnect. * Help tab gains „Instant view switching“ section explaining the feature, how to enable per display, when to disable for caching-plugin compatibility, and how to debug via `window.SdawebGcalSwap.debug` + the Diagnostics activity log. * Feature flag default refined to match the brief: **on for new displays, off for existing** (the v0.12.0 release set both to off uniformly). Existing displays preserve their pre-0.12.0 full-page navigation behaviour on upgrade; new displays created post-upgrade have instant view swap pre-enabled. * New: `wp sdaweb-gcal rest-render ` CLI command for dispatching the REST endpoint internally + dumping JSON response to stdout — drives the new REST snapshot tests. * New: `wp sdaweb-gcal architecture-check --fixture=` CLI command — assert REST inner-HTML normalises to shortcode-pipeline inner-HTML for the same display config. Catches future drift between the two render paths. * New: 3 REST snapshot fixtures (`rest-list-grouped-by-day`, `rest-month-grid`,` rest-cards-anchor`) + shared events fixture. Test runner extended to handle both HTML and JSON snapshots and to run the architecture regression check as a final pass. * New: `tests/boot-regression.html` — browser-runnable assertion that swap.mjs’s boot path attaches its click listener correctly regardless of when DOMContentLoaded fires. Catches the bug class where a deferred ES module misses the DOMContentLoaded event and silently leaves the click delegate unwired. #### 0.12.0 * **New: Instant view switching.** Clicking the view toggle (List/Month/Card/Week/ Day/Mini/Upcoming) or prev/next navigation now replaces only the calendar fragment— no page reload — with a smooth crossfade on supporting browsers via the View Transitions API. Falls back gracefully to full-page navigation when JavaScript is unavailable or the feature flag is off. * **New: REST endpoint** `/wp-json/sdaweb-gcal/v1/render` for fetching individual view fragments. Public read; returns JSON with inner HTML + ETag + Cache-Control headers. 304 Not Modified support saves bandwidth on repeat navigations. * **New: Per-display feature flag** „Enable instant view swap“ in the View section. Defaults **off** for safety — admin opts in per display after confirming compatibility with the site’s caching plugins. Dimmed (per v0.11.0 #6 pattern) when „Show view toggle“ is off. * **New: Hover/focus prefetch.** Hovering or tab-focusing a view toggle speculatively fetches the target view; the subsequent click commits against a warm cache. Respects` Save-Data` and runs in `requestIdleCallback` so it never competes with user-driven work. Per-root LRU(6). * **New: Accessibility for AJAX swaps** — `aria-busy` during fetch, screen-reader announcement after swap via a per-root live region, focus moves to the new view’s primary heading, `prefers-reduced-motion` skips the transition animation. * **New: Diagnostics integration.** Every swap fires `swap:render:ok/304/fail` events into the v0.11.0 #12 ring buffer. Set `window.SdawebGcalSwap.debug = true` from the browser console for client-side timing logs. * **Bumped: Minimum WordPress version is now 6.5** (was 6.0) — required for the WP-native script-modules API the swap module uses. #### 0.11.1 * Compliance: silence 12 Plugin Check (PCP) false-positive errors from 0.11.0 — 9 OutputNotEscaped at the new Link_Target helper call sites (the helper returns a hardcoded attribute string, never visitor input — phpcs can’t trace escaping across function boundaries), 1 OutputNotEscaped on the CLI render command’s raw stdout echo (intentional for snapshot capture), and 2 MissingTranslatorsComment on the relative-time formatter (translator comments now sit on the line immediately preceding each `__()` call as the sniff requires). No runtime behavior change. #### 0.11.0 * **New (#8): Centralised link-target helper.** Every outbound link across every view now routes through `View_Footer_Link`-sibling helper `Link_Target::attrs()`, so the display’s „Open links in“ setting governs all link surfaces consistently. Mini-month full-link and Upcoming top-row „See all“ now also honour the setting( previously hardcoded to same-window). Footer link remains decoupled per 0.10.1. * **New (#1): Per-display render cache + cascade invalidation.** Rendered HTML is now cached (15-minute floor TTL). Calendar „Refresh now“ cascades into every display containing the calendar, busting their render caches; the success notice surfaces the dependent-display count. New per-display „Refresh render cache“ row action on the Displays tab. Display form save and delete also bust automatically. * **New (#6): Consistent inactive-field dimming.** Five conditional field groups in the display edit form now visibly dim with an inline „inactive — needs X“ badge when their master switch is off: Footer link 4 fields (gated by Show „See all“ link), Upcoming title cluster (gated by Show title row), Upcoming „See all“ URL (doubly gated), Mini-month link label (gated by URL non-empty), View toggle 2 fields (gated by Show view toggle). Dimmed fields stay interactive and persist values to the DB. * **New (#12): Diagnostics sub-panel in the Tools tab.** Read-only introspection: per-calendar fetch state, per-display render cache hit/miss counters, environment summary, last-50 events ring buffer. Three action buttons: re-fetch all calendars, bust all render caches, download diagnostics JSON. Replaces the save reload guess debugging loop. * **New (#19, partial): WP-CLI commands.** New `wp sdaweb-gcal render ` for rendering a saved display to stdout, and `wp sdaweb-gcal cache:bust []` for cache utilities. `--fixture=` and `--events=` flags enable deterministic snapshot testing via the new `sdaweb_gcal_pre_fetch_events` filter. Test fixture + bash runner + README under `tests/` (not shipped in the wp.org zip). Snapshot- test feature is intentionally focused — `--now` flag, more fixtures, and CI wiring deferred to v0.12.0. #### 0.10.1 * Change: Footer link („See all “) always opens in the same window now, decoupled from the display’s „Open links in“ (`link_target`) setting. Footer links are sibling-site navigation; event-row links continue to honour `link_target` for external Google Calendar event detail pages. #### 0.10.0 * New: **Footer link** („See all “) on the bottom of List, Upcoming, and Card views. Five new admin fields under a „Footer link“ subsection in the View tab: show toggle, URL, label override, style (Quiet / Underline), and alignment (Auto / Start / Center / End). Auto resolves per-view: End for Upcoming, Center for List, Start for Card. Color follows the display’s Link color override (single source of truth across chips, top-row „See all“, and the new footer link). Empty URL hard-suppresses render. Coexists with the existing Upcoming top-row „See all“— both can be enabled. #### 0.9.5 * Fix: Upcoming view — **Title size**, **Title weight**, and **Uppercase title text** settings actually take effect now. `Shortcode::defaults()` was missing the three keys, so `shortcode_atts()` was silently stripping them out of the config before it reached the view layer. The 0.9.4 patch (passing the keys through` Display_Renderer::build_view_context`) and the 0.9.3 CSS scoping change were both correct, but a third upstream layer needed the same keys to be added too. With the input gate now opened, all three controls work end-to-end. #### 0.9.4 * Fix: Upcoming view — **Title size**, **Title weight**, and **Uppercase title text** settings now actually take effect. The display orchestrator (`Display_Renderer:: build_view_context()`) was missing the three keys from the options array it builds for the view, so the renderer always read empty values and fell back to its built- in defaults (`15px` / `500` / no transform). The renderer itself was correct; the upstream `Display_Renderer` is now passing the keys through. Visible only on `title_uppercase` until now — `title_size` and `title_weight` defaults coincidentally matched the renderer fallbacks, hiding the bug. 0.9.3’s CSS scoping change remains in place as defense-in-depth against themes that override `text-transform` directly on `` elements. #### 0.9.3 * Fix: „Uppercase title text“ setting now applies correctly on the Upcoming view when the active theme has its own `text-transform` rule on `` elements. Scoped the rule to `.sdaweb-gcal-upcoming__title-text` directly instead of relying on inheritance from the parent. #### 0.9.2 * Compatibility: Tested with WordPress 7.0. * Cleanup: Suppressed a Plugin Check warning on the `WP_DEBUG`-gated `error_log()` diagnostic added in 0.9.1 (recurrence canary for the 0.9.0 native-color-picker swap bug). No behaviour change. #### 0.9.1 * Fix: Per-calendar Text color save bug introduced in 0.9.0. On the Calendars edit form, saving a Text color caused that value to land in the calendar’s main Color field instead, wiping the original Color value and leaving Text color blank. Root suspected in the interaction between the new wpColorPicker Text color field and the existing native `` Calendar Color field (likely via the OS-level recent-colors memory the native picker exposes). 0.9.1 replaces the native picker on the Calendars tab with the same wpColorPicker control the Text color field uses — both fields now share the plumbing that the Displays- tab color fields have used for years without incident. If you saved a calendar in 0.9.0 with a Text color and find the swatch flipped to the value you picked: re-edit the calendar, restore the original Color, set the Text color again, and save. #### 0.9.0 * New: **Tinted** option added to **Chip text color (Solid & Pastel)** on the display edit screen. Derives a deep tint of the feed color in OKLCh that passes WCAG ≥ 4.5:1 against the actual chip background (raw feed for Solid, the pastel-tinted mix for Pastel). For light feeds (yellows, limes, cyans, light pinks), tinted text would be visually indistinguishable from black; the resolver detects that perceptual collapse and falls back to the Auto dark color automatically so authors don’t end up with a fourth option that’s secretly the third one. Pastel chips have more contrast headroom than Solid, so Tinted works on more feeds in Pastel. * New: **Per-calendar Text color** picker on the Calendars tab (Color row). When set, this color is used as the chip text color for every event from that calendar, on every display, regardless of the display’s Chip text color setting. Live contrast badge in the picker checks against the calendar’s own background (Solid worst case); Pastel renders the same text on a softer tint and has additional headroom. Leave blank to let each display’s Chip text color setting decide. * Change: **Solid chip text color** field renamed to **Chip text color (Solid & Pastel)** — Pastel chip titles now consume the same resolved text color as Solid through the shared `--sdaweb-gcal-event-text` custom property, so a single field governs both styles. Existing displays render unchanged when chip_text_mode is` auto`; Pastel chips opt in to the resolved color when chip_text_mode is `light`,` dark`, or `tinted`, or when the per-calendar Text color override is set. * Fix: `chip_text_mode` (added in 0.8.3 as `Solid chip text color`) was not being copied from the saved display record into the render context, so every display rendered as if the mode were `auto` regardless of what the admin had selected.` Always light` and `Always dark` have been silent no-ops since 0.8.3; they now work as advertised. * Fix: Visited chip and ribbon links lost their resolved chip text color. The global`. sdaweb-gcal a:visited` rule (specificity 0,2,1) out-specified the resting chip- anchor rule (0,2,0), so once a visitor clicked a chip link and returned the chip title flipped to the link color, undoing the Auto-mode WCAG choice and the new per-calendar override. Chip and ribbon anchor rules now list `:link` / `:visited` explicitly to bump specificity past the global rule. * Fallback aggregator: when Tinted is selected and one or more selected feeds collapse to the Auto target, the display editor shows a single quiet note („N of M selected feeds fall back…“) under the field after save — no per-feed wall of warnings. #### 0.8.6 * Fix: Service-account token-exchange success no longer writes to the PHP error log unconditionally. The success path is now gated on `WP_DEBUG`; on busy sites this was logging one line every ~55 minutes even when everything was working correctly. Token-exchange failures and API errors continue to log unconditionally so real problems are always surfaced. * Fix: Upgrade notice for 0.8.3 in `readme.txt` exceeded WordPress.org’s 300-character limit (Plugin Check `upgrade_notice_limit` warning). No code change. #### 0.8.5 * New: **Delete** button on each row in Tools Backups. Snapshots could previously only be removed by capturing three new ones to push them out of the retention window — fine for routine pruning, awkward when a single test snapshot wanted to go. The Delete button now removes one specific snapshot immediately (confirm dialog first; record is gone from the `sdaweb_gcal_backups` option). Frees a retention slot so the next pre-import/manual snapshot won’t prune a newer one to make room. #### 0.8.4 * Fix: Solid Month chips lost their auto-resolved text color on hover. The general`. sdaweb-gcal a:hover` rule in front.css set a hover color that cascaded into the chip’s `` because the more specific `.sdaweb-gcal-month__event a:hover` rule only set `text-decoration` — same specificity, no `color` reset, so the general rule’s color property won by cascade. Result: a chip whose Auto mode picked dark text correctly would flip to the link/accent color on hover, often dropping back below the WCAG threshold the Auto mode was protecting. Fix pins the hover color to `inherit` and adds a subtle `text-underline-offset: 2px` for breathing room. Week/Day chips deliberately keep their primary-color hover (different chip design— surface backgrounds, hover affordance comes from the color change). #### 0.8.3 * New: **Solid chip text color** option on the display edit screen (Appearance Event chip style Solid chip text color). Three modes: `Auto` (default) computes the WCAG relative-luminance contrast for white vs dark text against each chip background and picks the higher-contrast side; `Always light (white)` preserves the pre-0.8.3 behaviour; `Always dark` forces dark text. Fixes a long-standing readability issue where Solid chips with mid-luminance feed colors (greens like`# 16a34a`, yellows, mints) rendered as white text on a too-light background and the title „faded into“ the chip in the tiny month-grid footprint. Existing displays render unchanged on first load (Auto picks white for the same dark reds/blues/ teals that white was already being used on); only chips whose feed color previously failed AA against white will switch to dark text. #### 0.8.2 * New: Upcoming view exposes three new per-display title appearance controls — ** Title size** (Small / Medium / Large / X-Large), **Title weight** (Normal / Medium/ Semi-bold / Bold), and an **Uppercase title** toggle. Useful when the surrounding container’s headings (sidebar widget titles, footer column headers) use a different weight/case than the plugin’s default `15px / 500`, so the „Fra kalenderen“-style title can be tuned to blend in without site CSS overrides. Existing displays render unchanged — defaults match the previous hard-coded values. * Change: The Upcoming view’s „See all “ link now always opens in the same window, regardless of the display’s Link target setting. The link points to the site’s own calendar page; opening a same-site link in a new tab is a UX anti-pattern( breaks the back button, loses navigation context). Per-event URLs (typically off-site) continue to honour the Link target setting. #### 0.8.1 * Fix: View-toggle / focus-date / „+N more“ / date-jump URLs are now scoped to the calendar instance whose control was used — they no longer bleed into every other calendar on the page. Previously, switching the main calendar to Month or Day view also flipped any other calendar instance on the page (footer widgets, sidebar instances) into the same view. A footer „Upcoming“ widget on the same page as a Month-view calendar would render as a cramped Month grid in the narrow footer column, and looked broken. Same root issue for `?sdaweb_gcal_focus=` — every calendar on the page jumped to the same date. Fix: every navigation URL now carries `sdaweb_gcal_id=` and the renderer ignores the override unless the URL’s id matches the current display. #### 0.8.0 * New: Month-view „+N more“ indicator is now interactive (was a non-clickable `
  • ` — a real a11y gap; keyboard users and screen readers couldn’t reach it). New per-display option **Day overflow („+N more“)** under „Month view options“ with two modes: `popover` (default) opens an in-place panel listing the day’s full event list; `day` turns „+N more“ into a link that loads the Day view for that date. Popover ships with focus management (Esc, click-outside, focus restoration),` aria-haspopup`/`aria-expanded`, and `role="dialog"`. Day-link mode ships zero JS. * New `month_overflow_action` shortcode attribute / `monthOverflowAction` block attribute (values: `popover` | `day`). #### 0.7.4 * Fix: Multi-day events in the Cards view now render with a date range in the date column („4–8 / MAI / man–fre“ for same-month, stacked „30 APR 5 MAI“ for cross- month) instead of showing only the start day. Previously a 5-day event like „ Class trip Monday–Friday“ looked indistinguishable from a single-day event in cards. * Fix: Cards view with `card_grouping = day` now expands multi-day events into every day they cover, matching Week and Mini view behaviour. Previously a Monday– Friday event only appeared under Monday’s section. Week and month grouping keep the simpler „appear once at the start group“ behaviour — the new date-range badge signals the span without multiplying cards across groups. * All-day handling honours Google Calendar’s exclusive-end-date convention (a „ Mar 5–7“ event arriving as end=Mar 8 is correctly bucketed and labelled as Mar 5–7 inclusive). #### 0.7.3 * Docs: Moved `CHANGELOG.md` from the plugin root to `docs/CHANGELOG.md`. Plugin Check’s `unexpected_markdown_file` rule (severity 9 WARNING) flags any non-readme`. md` file at the plugin root. * Docs: Trimmed this Changelog section (per Plugin Check’s 5000-character cap). Full history is in `docs/CHANGELOG.md`. #### 0.7.1 * Admin: Edit Display form fields no longer overflow under the sticky Live preview pane on the right. `