DEV Community: Jeffrey Inman

Show a Google Calendar on WordPress without the iframe

Jeffrey Inman — Sun, 27 Sep 2026 22:01:58 +0000

A lot of club, church and studio websites show their events with Google Calendar's embed code. It works, and it's free, but it's also why the events page looks like a different website. Here's what the embed gives you, the other way to put a Google Calendar on a WordPress site, and what to check before you trust a plugin with it.

Disclosure: I build Beacon Events, a WordPress events plugin that syncs calendar feeds. The checklist below applies to whatever you use.

What the embed gives you

Google's embed code is an iframe with a fixed width and height (its customize page asks for at least 500 by 500). Inside it, everything is Google's page:

It doesn't fit. A fixed-size box needs extra CSS before it behaves on a phone.
It doesn't match. You can pick colours and hide a few tabs, but not your theme's fonts or layout.
Your site gets nothing for search. The events live on Google's page, so your site has no page per event and no Event markup for search results.

The other way: sync the feed

Every Google Calendar has an iCal (ICS) address. A plugin can read that address on a schedule and turn each event into a real post on your site. You keep editing in Google Calendar, as you do now, and the website follows.

To get the address: open Google Calendar on a computer, go to Settings, click your calendar on the left, and click "Integrate calendar". The "Public address in iCal format" only works if the calendar is shared publicly ("Make available to public" under access permissions). If you'd rather not make it public, the "Secret address in iCal format" works too. Treat it like a password: anyone who has it can read the whole calendar.

What to check in a plugin that syncs

Google's feed has a few habits that trip up sync code. Try these with a test calendar before you point a plugin at the real one.

A repeating event stays one event. A weekly service should arrive as one event with a rule, not 52 separate posts.
One changed date doesn't break the series. When you move or cancel a single date of a repeating event, Google sends that date as a separate entry with the same ID as the series. Sync code that matches on the ID alone overwrites the whole series with that one date.
Old series still show upcoming dates. A weekly event that started years ago should still show next week. Some plugins only work out dates for a fixed period from the first one.
Skipped dates all stay skipped. Google writes one line per skipped date. Code that keeps only the last one brings the others back.
Evening events land on the right day. Some feeds write times in UTC, where 7:30 pm in Chicago is already Wednesday. The weekday has to be moved back.
Deleted events are handled in a way you can live with. Removed from the site, hidden, or kept: know which before it happens to a real event.
You know how often it syncs. WordPress's scheduled tasks run when someone visits the site, so an "hourly" sync on a quiet site can run late unless the host runs a real cron job.

One more thing that's true of any sync: edits you make on the WordPress side get overwritten on the next run, because the feed is the source. Change events in Google Calendar, not in WordPress.

If you want to try Beacon Events

The calendar is free on wordpress.org. Paste the feed address under Events → Settings, optionally followed by a category, and it syncs hourly with a log of what was created, updated or removed each time. A repeating event stays one event, and a moved or cancelled date shows as moved or cancelled on the series. Events that disappear from the feed become drafts rather than being deleted. It shows month, list and day views as blocks or shortcodes in your theme's fonts, and every event gets its own page with Event markup for search.

https://wordpress.org/plugins/beacon-events/

If your calendar does something odd in any plugin, describe it in the comments and I'll look at the feed.

Moving off Event Tickets Plus: what your WooCommerce ticket data looks like

Jeffrey Inman — Sun, 27 Sep 2026 19:22:35 +0000

Event Tickets Plus sells your event tickets through WooCommerce. If you're moving off it, whether because of the Liquid Web changes or because you're leaving The Events Calendar altogether, the tickets and attendees are the part that's easy to get wrong. Here's what that data looks like in your database and where a migration usually breaks.

Disclosure: I build Beacon Events, a WordPress events plugin, and I wrote an importer for this data this week. The details below apply whatever you move to.

What's in your database

The field names below come from the free Event Tickets plugin's own code, which maps every ticket provider it supports.

Each ticket is a WooCommerce product. It carries _tribe_wooticket_for_event with the event's post ID, and _tribe_ticket_capacity with the ticket's capacity (-1 means unlimited). The price is the product's price.
Each attendee is a tribe_wooticket post, one per ticket sold, so an order for three tickets makes three attendees. It points back with _tribe_wooticket_event (the event), _tribe_wooticket_product (which ticket), _tribe_wooticket_order (the WooCommerce order) and _tribe_wooticket_order_item (the line in that order). _paid_price holds what was paid.
Whether someone actually paid lives in WooCommerce, in the order's status, not in the attendee record.

Where migrations go wrong

Unpaid orders become attendees. Orders that are pending or on hold still have attendee posts. Only completed and processing orders are paid, so leave the rest out, and drop refunded, cancelled and failed ones too.
Newer stores keep orders out of wp_posts. With WooCommerce's High-Performance Order Storage (HPOS), orders live in their own wc_orders table. A query that joins attendees to shop_order posts finds nothing on those sites. Ask WooCommerce for the order (wc_get_order()) instead, which works either way.
The buyer isn't always the guest. One person can buy tickets for three people. Use the name and email stored on each attendee first, and fall back to the order's billing details only when those are empty.
Ticket types collapse into one price. An event with early bird, general and VIP tickets is three products. If your new plugin only has one price per event, you lose that, and your existing attendees lose the record of what they bought.
The import sends emails. A migration shouldn't send everyone a fresh confirmation. Check that the importer is silent before you run it on real data.

A checklist that holds up

Back up the database, including the WooCommerce order tables.
Count your paid attendees in WooCommerce before you start, so you have a number to compare against.
Run the import with Event Tickets Plus still active, and check one event with several ticket types and one order that was refunded.
Make sure capacity still counts the people you imported, so nobody can buy a seat that's already taken.
Only then switch the old plugins off.

If you want to try Beacon Events

The calendar is free on wordpress.org. Its paid add-on, Beacon Events Pro, imports Event Tickets Plus data when you move from The Events Calendar. That covers each ticket as its own ticket type with its price and capacity, and every attendee of a completed or processing order under their own name, with the WooCommerce order linked. Unpaid orders are listed in the report, and no emails go out. New tickets then sell through your WooCommerce checkout or your own Stripe account with no per-ticket fee from us. It also has check-in at the door and a printable door list. It's $49 a year for one site, with a 14-day free trial that needs no card.

https://wordpress.org/plugins/beacon-events/

If your Tickets Plus setup has something this doesn't cover, say so in the comments and I'll look at it.

Eventbrite fees vs selling tickets on your own WordPress site, with the actual numbers

Jeffrey Inman — Sun, 27 Sep 2026 16:50:14 +0000

If you sell tickets for small events (a class, a workshop, a club night, a fundraiser), the ticketing platform's cut adds up fast. Here are the actual numbers for Eventbrite against taking payments on your own WordPress site, and what you give up if you switch.

Disclosure: I build Beacon Events, a WordPress calendar plugin whose paid add-on sells tickets. The arithmetic below holds whatever you use.

What Eventbrite charges

From Eventbrite's US pricing page:

Free events: no fees.
Paid tickets: "3.7% + $1.79 service fee per ticket".
On top of that: "2.9% payment processing fee per order".
Buyers pay these fees by default, or you can absorb them.

What selling on your own site costs

If the payment goes straight through your own Stripe account, Stripe's US price is "2.9% + 30¢ per successful transaction for domestic cards", plus 1.5% for international cards. The ticketing software is a flat yearly fee or free.

The 2.9% shows up on both sides, so the real difference is Eventbrite's service fee against Stripe's 30¢.

Per ticket

Service fee on Eventbrite against Stripe's fixed fee, one ticket per order:

Ticket price	Eventbrite service fee	Stripe fixed fee	Difference per ticket
$10	$2.16	$0.30	$1.86
$20	$2.53	$0.30	$2.23
$50	$3.64	$0.30	$3.34

When buyers pay the fees, the 2.9% processing is charged on the service fee too, so a $20 ticket comes to about $23.18 at checkout.

Over a year

A studio running 40 classes a year with 25 people at $20 sells 1,000 tickets. That's about $2,530 in Eventbrite service fees, against about $300 in Stripe's fixed fees. Whether your attendees pay that difference or you do, it's roughly $2,200 a year.

What you give up

Being fair to Eventbrite, it does a few things your own site won't:

Discovery. People browse Eventbrite for things to do. Your own site only sells to people who already found you.
Check-in and seating. Its organizer app scans tickets at the door, and it handles reserved seating.
Refunds and payouts. It handles refund requests and chargebacks and pays you out on its schedule. With your own Stripe account, that's between you and Stripe.

If most of your buyers find you through Eventbrite, the fee may be worth it. If they come from your own site, your newsletter or your regulars, you're paying a marketplace fee for a marketplace you don't use.

Checklist before you switch

Open a Stripe account and send one real test payment to yourself.
Decide your refund policy and write it on the event page.
Make sure buyers get a confirmation email with a calendar file.
Set a capacity for each date so you never oversell.
Keep a printable attendee list for the door.

If you want to try Beacon Events

The calendar is free on wordpress.org, including recurring events and Google Calendar sync. The paid add-on, Beacon Events Pro, is $49 a year for one site, with a 14-day free trial that needs no card. It takes RSVPs and sells tickets through your own Stripe account or your WooCommerce checkout, with no per-ticket fee from us. It includes a capacity per date, a waitlist, reminder emails and an attendee list you can export. Each event can have several ticket types, like early bird, general and VIP, with their own prices and capacities. There's no reserved seating and no scanning app yet, so it fits classes and small events better than festivals.

Demo site: https://store-safety.duckdns.org/demo/

https://wordpress.org/plugins/beacon-events/

If your numbers look different, say, a country with other fees, post them in the comments.

All-in-One Event Calendar is gone from wordpress.org: getting your events out

Jeffrey Inman — Sat, 26 Sep 2026 23:59:46 +0000

Timely closed All-in-One Event Calendar on wordpress.org in August 2025, at their own request. Sites that still run it get no more updates from there. The last release still bundles an iCal library that calls create_function(), which PHP 8 removed, and on a fresh install version 3 gives you Timely's hosted calendar instead of the local one.

Your events never left your database, though. Here's what's in there and what goes wrong when you move it, whichever calendar you pick next.

Disclosure: I build Beacon Events, a free calendar plugin, and this week I wrote an importer for this data. Everything below applies to any migration.

What's in your database

Each event is a post of type ai1ec_event. The dates and the rest live in a table of their own, wp_ai1ec_events, one row per event:

start and end are Unix timestamps in UTC. timezone_name says which zone the event was entered in, and sys.default means the site's zone.
recurrence_rules holds an iCalendar RRULE. Rules written by its editor look like FREQ=WEEKLY;WKST=MO;BYday=TU,TH; with a lower-case "day", and end dates come out as UNTIL=20261231T235959Z.
exception_dates is a comma-separated list of skipped dates. exception_rules can hold a whole rule of excluded dates.
Venue, address, city, contact, cost and ticket link are plain columns, except cost, which is a serialized PHP array.
Events pulled in from a calendar feed carry ical_feed_url and the feed's own ical_uid. Moved single dates get that UID with a prefix.

Categories and tags are the events_categories and events_tags taxonomies, and category colours sit in wp_ai1ec_event_category_meta. Expanded dates are cached in wp_ai1ec_event_instances, which you can ignore because it's rebuilt from the rules.

Where migrations go wrong

The calendar page goes blank. It drew the calendar into an empty page you picked in its settings, with no shortcode or block in the content. Once the plugin is off, that page shows nothing, so put your new calendar on it.
Times shift by hours. The timestamps are UTC. Convert them in the event's own zone, not the server's, or an evening class starts at midnight.
Rule end dates drift by a day. UNTIL is a moment in UTC, not a date. In a zone ahead of UTC, 20261115T235959Z is already November 16, so read it as the last date whose start still comes before that moment.
Feed events get duplicated. If you import them and then subscribe to the same feed again, you get two copies unless the importer keeps the feed's UIDs.
Exclusion rules disappear. Few calendars understand EXRULE at all. "Every day except weekends" only survives if it becomes a weekly rule on the remaining days.
Old links 404. Calendar views live at URLs like /calendar/action~month/… and categories at /events_categories/your-category/. Search engines and bookmarks still have those.

Where to go

Open Source Event Calendar is a GPL fork of All-in-One Event Calendar by digitaldonkey and looks the most like it. Its readme says the database isn't fully compatible with All-in-One Event Calendar 2.3.4 and that moving existing events may take manual work.
Timely's hosted calendar is their own service, embedded into your site.
Beacon Events is the one I build. It reads the tables above directly, with the old plugin active or already switched off.

A checklist that holds up

Back up the database.
Install the new calendar and run its import while All-in-One Event Calendar is still active. Don't delete anything yet.
Spot-check a recurring event, an all-day event and one that came from a feed.
Deactivate the old plugin, put the calendar on the old calendar page, and click a few old links.

If you want to try Beacon Events

It's free on wordpress.org. Events → Import / Export shows what it found and imports it in one click: rules and skipped dates, category colours, venues, contacts, images and feed UIDs. The old category, calendar-view and event links redirect once the old plugin is gone, and the report names the page that used to show the calendar. Recurring events are free, and so is Google Calendar or ICS sync.

Demo site: https://store-safety.duckdns.org/demo/

https://wordpress.org/plugins/beacon-events/

If your old calendar has something this doesn't cover, tell me in the comments.

Moving off The Events Calendar: what has to come across, and what breaks

Jeffrey Inman — Sat, 26 Sep 2026 22:37:12 +0000

The Events Calendar Pro now starts at $259 a year after the Liquid Web consolidation, and plenty of sites that only use it for a calendar with a few recurring events are looking at the renewal and wondering if it's worth it. I spent this week writing an importer for TEC data, so here's what that data looks like and where a migration goes wrong, whichever plugin you end up on.

Disclosure: the importer is part of Beacon Events, a free calendar plugin I built. Everything below applies no matter what you switch to.

What's in your database

Events are regular posts (tribe_events) with the dates in post meta: _EventStartDate, _EventEndDate, _EventTimezone, _EventAllDay. Venues and organizers are their own post types (tribe_venue, tribe_organizer), linked from the event through _EventVenueID and _EventOrganizerID. Categories are the tribe_events_cat taxonomy.

Recurring events are the part that bites. On TEC 6 with Pro, the rule is stored in TEC's custom wp_tec_events table as an iCalendar rule set, not in post meta. Older TEC 5 sites kept a serialized _EventRecurrence array, and some still have one generated child post per occurrence sitting next to the parent event.

If you sell tickets with Event Tickets, those are post types too: tribe_rsvp_tickets and tec_tc_ticket, with attendees in tribe_rsvp_attendees and tec_tc_attendee. A paid attendee points to its order through post_parent, and the order's status is the order post's status (tec-tc-completed, tec-tc-pending and so on).

Where migrations go wrong

A recurring series becomes hundreds of events. If you move data through a generic export, check whether a weekly class arrives as one rule or as 52 separate posts. The second one is miserable to edit later.
Time zones stored as offsets. If the site time zone was ever set to something like UTC+2 instead of a city, event times can end up stored that way. An offset knows nothing about daylight saving, so a 6pm class drifts to 7pm for half the year. Map offsets to a named zone.
Leftover shortcodes and blocks. Event content often contains [tribe_events] shortcodes and tribe/* blocks. Once TEC is deactivated, the shortcodes print as raw text and the blocks render nothing. Strip them.
Old URLs. Single events usually keep /event/slug/, but category pages and calendar views live under /events/category/... and /events/month/. Those 404 after the switch unless something redirects them, and that's search traffic you worked for.
Unpaid orders counted as seats. If you bring attendees along, leave out pending and failed orders. Those people never paid.

A checklist that holds up

Back up the database. Actually do it.
Install the new plugin with TEC still active and run the import. Nothing in TEC should be deleted while you check.
Spot-check one recurring series, one event in a different time zone, and one event with tickets.
Deactivate TEC and click through a few old URLs, including a category page.
Only then cancel the renewal.

If you want to try Beacon Events

It's free on wordpress.org. Recurring events are free, including cancelling or moving a single date of a series. Events → Import / Export reads the TEC data described above in one click (events, venues, organizers, categories, images, recurring rules), strips the TEC shortcodes and blocks, and redirects the old category and view URLs. It also imports from Events Manager and CSV. The paid add-on ($49 a year, with a 14-day free trial that needs no card) does RSVP and tickets and brings Event Tickets attendees across: RSVP, Tickets Commerce, and Event Tickets Plus orders paid through WooCommerce.

Short video tour (1:39):

Live demo on a stock Twenty Twenty-Five site: https://store-safety.duckdns.org/demo/

https://wordpress.org/plugins/beacon-events/

If your TEC data has something this doesn't cover, tell me in the comments.