Skip to content
ThemesIonic — home
WordPress Tutorials

Adding Events to a WordPress Calendar

The calendar built into WordPress cannot show events, and no amount of settings will change that. Knowing what it actually does saves an afternoon of looking for an option that was never there.

4 min read beginner

The calendar that ships with WordPress is a post archive, not an event calendar. It draws a month grid, marks the days on which you published something, and links those days to date archives. If you have been hunting for the option to add an event to it, there isn't one, and there never was.

That is the whole confusion. Once you accept it, the job becomes choosing how to display real events, which is a different and much more answerable question.

What the built-in calendar is for

The core Calendar block exists in the block inserter and in widget areas. On a blog that publishes regularly it gives readers a sense of activity and a route into date archives. On a site that publishes twice a month it looks like a mostly empty grid, which is why it is rarely used.

To place it: in a classic theme, use the widgets screen under Appearance. In a block theme, edit the relevant template or template part in the Site Editor and insert the block there. Both routes insert the same block — the difference is only where widget areas live, which is worth understanding generally if blocks are new to you: see what a block is in WordPress.

People sometimes try to force it into service by publishing posts with future dates so days light up. Future-dated posts are scheduled, not published, so they do not appear until they go live — and the day it marks is the publish date, not the date of the thing being announced. It does not work.

Route one: an events plugin

This is the right answer for anything recurring or ongoing. An events plugin adds an event post type with start and end times, a venue, and calendar views that query by event date. It then supplies its own calendar block or widget, which is the thing you place in the sidebar.

The general shape of the work:

  1. Install the plugin on staging first if the site is live.
  2. Set the site timezone under the general settings before creating any events. Changing it later shifts existing event times.
  3. Create one event with a start time, an end time, a venue and a description.
  4. Add the plugin's calendar block or widget to the sidebar, footer or a dedicated page.
  5. Add a link to the events page in the site's menu.

When choosing between plugins, the questions that actually differentiate them are: whether recurring events can have a single occurrence edited without breaking the series; whether events can be imported and exported as iCal so an existing calendar stays in sync; what happens to an event after its date passes; and whether visitors can register or buy tickets. If registration and payment are involved, you are in booking-plugin territory rather than events — choosing a booking plugin sets out the difference and the criteria in detail.

Be wary of plugins that load a calendar library on every page of the site rather than only where the calendar appears. A sidebar calendar is not worth a site-wide script.

Route two: embed an external calendar

If the events already live in a shared calendar that someone maintains, embedding that calendar is often better than duplicating the data in WordPress. It stays current with no second workflow, and whoever owns the calendar keeps owning it.

Paste the provider's embed into a Custom HTML block, per adding code to a WordPress page. The trade-offs are real: the embed is an iframe, so the events are not your content, they will not appear in your site search or in search results, and the styling is largely the provider's. Reserve a fixed height for it so the page does not shift as it loads.

The two things that break event calendars

Caching. A calendar's output depends on today's date, so a cached copy goes stale without anything being edited. Exclude the calendar page and any calendar endpoints from the page cache, or give them a short lifetime — clearing the WordPress cache covers the layers involved when something looks out of date.

Timezones. Set the site timezone to a named city rather than a fixed offset, so daylight saving is handled automatically. A fixed offset means every event is an hour wrong for half the year.

What to do now

If you want a month grid showing when you published, the core Calendar block already does it. If you want events, install an events plugin and place its calendar — the core one will never do the job. And if a shared calendar already exists elsewhere, embed it and skip the second data entry entirely.

Frequently asked

No. The core calendar is an archive of publication dates: it highlights days on which posts were published and links to that day's archive. It has no concept of a future date, a start and end time or a venue, and there is no setting that adds one.
Either a plugin or an embedded calendar from an external service. Events need a custom post type with date fields and a query that sorts by event date rather than publish date, and that is functionality WordPress does not ship with.
Nearly always a page cache serving yesterday's rendered calendar, since a calendar page changes with the date even when nothing on the site has been edited. Exclude the calendar page from the cache or shorten its lifetime, and check the site timezone under the general settings.

Related guides