Bookly Advanced Google Calendar 3.1 (Add-on)

Bookly Advanced Google Calendar Add-on is the piece I install when Bookly’s built‑in scheduling is fine, but the business runs its day around Google Calendar. The job is simple: appointments created/updated in Bookly should land in the right Google calendar (and, depending on your setup, changes from Google should push back).

I use it for teams where each staff member needs their own calendar mapping, plus real “busy time” blocking. Without that, Bookly happily offers slots that Google already filled with meetings, travel, or “busy” placeholders.

What it actually changes in WordPress (and where)

This add‑on lives inside the Bookly ecosystem, so you manage it from WP Admin → Bookly → Settings (Google Calendar section) and typically per‑staff mapping in Bookly → Staff Members (each staff profile binds to a Google account/calendar). Nothing “theme-related” here; it’s admin logic + background sync.

Under the hood it’s standard WordPress plugin behavior:

• Credentials/tokens end up stored in WP (usually in wp_options and/or Bookly’s own tables alongside staff records). That’s why moving domains breaks auth: tokens are tied to the Google OAuth app + redirect URI.
• Appointments are Bookly DB records first; the add‑on turns them into Google Calendar events (event IDs get stored so updates can target the same event).
• Sync timing relies on WordPress cron mechanics (WP‑Cron) or server cron calling wp-cron.php. If WP‑Cron is disabled and you don’t run a real cron, events won’t sync “later”; they just… won’t.
• Frontend assets usually remain Bookly’s own handles (booking form JS/CSS). The Google part is mostly server-side, except the OAuth authorization flow.

What’s editable: settings in Bookly screens, staff→calendar mapping, and Google Cloud configuration. What’s not: the actual sync logic/event payload is plugin code; you don’t “template override” it like a theme.

Where it breaks in real projects (and the fastest fixes)

1) “redirect_uri_mismatch” / OAuth consent errors
I see this after domain changes, staging clones, or switching between www/non‑www.

• Fix: in Google Cloud Console → APIs & Services → Credentials, update Authorized redirect URIs to match the exact Bookly callback URL on the live domain (protocol + host + path).
• Quick confirmation: DevTools Network on the auth step shows a 302 to Google, then a Google error page; the page text usually names the mismatched redirect.

2) Events create, but updates/cancellations don’t reflect (duplicates happen)
Root cause is often lost/stale event IDs, or staff calendar mapping changed after events were created.

• Fix: re-check Bookly → Staff Members → Google Calendar mapping for the affected staff. Then run a manual resync (if your build includes it) or re-authorize that staff account so a fresh token is stored.

3) Busy time not blocking slots
Usually it’s not “broken,” it’s pointing at the wrong calendar (or the calendar has “Free” events).

• Fix: select the correct calendar per staff, and ensure Google events are actually marked Busy. If the add‑on reads free/busy, it won’t block “Free” events.

4) Sync randomly stops
This is almost always cron.

• Fix A (WordPress-side): verify DISABLE_WP_CRON in wp-config.php.
• Fix B (server-side): add a real cron hitting https://your-site.com/wp-cron.php?doing_wp_cron=1 every 5 minutes.
• Quick confirmation: check whether wp-cron.php is blocked by security rules/CDN, and whether appointments created minutes ago ever appear in Google.

Timezone mistakes deserve their own line: set WP Admin → Settings → General → Timezone to a real city (not UTC offset), then align Bookly/Google timezones. A 1–3 hour drift is always this.

You can find detailed instructions on how to update a theme or plugin on this page.

FAQs (the stuff people actually trip over)