How to display past events in The Events Calendar

The key point: code from 2014 is archival

The safest way to display past events in The Events Calendar is to use its built-in archive view, a menu link, or the current shortcode available in Events Calendar Pro. Do not copy the widget class and PHP files from the original version of this article today.

The 2014 guide extended the TribeEventsAdvancedListWidget, TribeEventsPro_Widgets and TribeEventsPro classes, then added a custom admin view directly inside the plugin directory. Modern The Events Calendar uses a different Views v2 architecture, blocks and template paths. The old code also contained HTML entities and typographic quotation marks instead of valid PHP syntax.

We removed it from this article because merely “cleaning up” the characters would produce code that looks credible while relying on obsolete interfaces. The solutions below were checked against the vendor documentation on 6 August 2026. Before a later implementation, compare these instructions again with the plugin version running on your site.

Choose a solution by need

Need	Simplest solution	Does it require code?
A separate page with all past events	Built-in eventDisplay=past view	No
An “Event archive” link in a menu or sidebar	A custom link to the past-events view	No
An embedded calendar for a selected past period	The [tribe_events] shortcode in Pro	No, but it requires Pro
Most recent past events first	The vendor's official Views v2 filter	Yes
Different list HTML and styling	CSS, a hook or a child-theme template override	It depends

Do not start with a custom PHP widget when the only goal is to make the archive available. Every additional class increases the cost of updates, testing and responding to changes in the plugin API.

Option 1. Link to the built-in past-events archive

The Events Calendar exposes a view of past events at an address with this parameter:

https://twoja-domena.pl/events/list/?eventDisplay=past

The /events/ part depends on the slug configured for the particular website. First open the normal calendar, switch to the past-events list and copy the working address. Do not type the path from memory if the site uses another language or a custom slug.

Then add a “Past events”, “Archive” or “View reports” link in one of these places:

• the calendar's main or secondary menu;
• a block on the events page;
• the footer;
• the sidebar, as a button or navigation block.

This works without building a new widget. The vendor describes it in the current Working with Past Events documentation.

Test the link while signed out and in a private window. If the page returns an error, check the permalink settings, the archive slug and whether an existing WordPress page has the same name.

Option 2. A block or widget that leads to the archive

The plugin provides an Events List block and a classic event-list widget. According to the current documentation, the base widget belongs to the free version of The Events Calendar, while Pro adds filters and additional fields. The standard list is nevertheless focused on upcoming events.

If the sidebar only needs an entry point to the archive, use a regular button, paragraph or navigation block with the eventDisplay=past address. It is simpler and more predictable than changing the query for the entire widget.

In the Site Editor, place this block directly in the page or footer template. In a classic theme, add it to a widget area. Give the link a descriptive label; “See more” alone does not explain that it leads to completed events.

When the link should be accompanied by a few hand-picked reports, create a separate list of cards or a query for recap posts. This is often a better marketing model than an automatic list of every date: it lets you show a photo, outcome, downloads and the next event related to the topic.

Option 3. A shortcode in Events Calendar Pro

Events Calendar Pro owners can embed calendar views with the [tribe_events] shortcode. The vendor documentation says that a past period can be shown by selecting an earlier date, while the parameter for past events is limited to the monthly view.

We do not reproduce the complete syntax here because supported arguments and view behaviour depend on the version. Open the current shortcode documentation from the plugin help panel, choose the Month view and set the date you want to show. Then check:

• whether the page contains only one main calendar navigation;
• what the visitor sees after moving to the next month;
• whether the date range actually includes the required events;
• how the view behaves on a phone and without JavaScript;
• whether the page duplicates identical content available at another address.

A shortcode makes sense when the archive is part of a specific page, such as a season summary. When you need a normal permanent archive, the built-in address is easier to maintain.

How to put the newest past events first

A list view may present past events chronologically, with the oldest first. For an archive of reports, the reverse order is usually more useful: the event that ended most recently appears first.

The vendor provides a current Views v2 snippet based, among other things, on the tribe_events_views_v2_view_list_template_vars filter. Rather than transcribing it into this article, use the maintained version in Showing Past Events in Reverse Order. That way you can see any API change before implementation.

Add the code as a small, documented functionality plugin or through a managed snippets mechanism. A child theme's functions.php is acceptable for a simple implementation, but the function will disappear when the theme changes. Do not paste code into the parent theme or edit The Events Calendar files.

Before activating it:

1. back up the database and files;
2. check compatibility between the WordPress, PHP and plugin versions in use;
3. test the change in a staging environment;
4. limit the filter to the correct view only;
5. check empty states, pagination, series and multi-day events;
6. prepare a simple way to disable the snippet.

When should you override the widget template?

A template override changes HTML structure; it should not be the first way to change the data range. The current documentation identifies the source list file at:

wp-content/plugins/the-events-calendar/src/views/v2/widgets/widget-events-list.php

Place the copy in the active child theme while preserving the directories:

wp-content/themes/twoj-motyw-potomny/tribe/events/v2/widgets/widget-events-list.php

The Using the Events List Widget documentation describes the details and current paths. Before copying it, compare the instructions with the header of the file in your installed version. The plugin may split a view into smaller parts, and an example for an older version may not fit the current one.

An override protects the file from being directly deleted during a plugin update, but it does not remove the maintenance obligation. After a major update, compare your copy with the new source template. Otherwise you may retain outdated markup, miss an accessibility fix or call a variable that the new version no longer passes.

If the change concerns only colour, spacing or size, use CSS first. If a small element is needed, check the available hooks. A full override offers freedom, but it also takes responsibility for the whole copied fragment.

What not to do when modifying the plugin

The original guide recommended creating an admin-panel file inside wp-content/plugins/event-calendar-pro/admin-views/. That approach was not update-safe: files in the plugin directory can be replaced, and private admin classes and views are not a stable contract for custom code.

Avoid the following:

• editing files in the plugins directory;
• copying a class from an old release without checking the current API;
• disabling updates permanently just to preserve a modification;
• running a snippet from a blog without staging and a rollback option;
• displaying unsanitised event data in custom HTML;
• registering a second widget when a link or shortcode is enough;
• hiding a PHP error instead of removing its cause.

If a custom requirement is critical, record the exact dependency versions and add a smoke test to run after an update. A fragment that works today can stop working when a hook, data structure or template changes.

How to design a good event archive

A technical list is not enough if the visitor should see the organiser's experience. For every event, consider showing its name, date, venue or “online” label, category and an image only when it adds meaning. The newest items should usually appear first.

Consider connecting an event with a recap containing:

• a summary and its key takeaway;
• photos with publication rights and alternative text;
• a presentation, recording or download;
• information about the next edition;
• a related service or article, when it is a natural next step.

Clearly distinguish “upcoming” from “past”. Do not display a “Register” button on a completed event unless registration concerns the next edition. An empty state should explain that no archive exists yet and lead to the current calendar.

For many items, add pagination or filters by year and category. Do not load hundreds of events into a single footer widget. A short list can lead to a complete archive with its own title, description and stable address.

Test after implementation

Review the list as a signed-out visitor and check:

• an event that ended yesterday, a multi-day event and a recurring event;
• the time-zone boundary and a change of day;
• ordering, pagination and filters;
• the empty view and an invalid address parameter;
• the link label, keyboard focus and readability on a phone;
• cache behaviour after changing an event date;
• behaviour after updating The Events Calendar and Events Calendar Pro.

Document why a particular method was chosen, where the code is located and how to turn it off. This is especially important in WordPress, where the next maintainer may only discover a snippet during an outage.

If an older site contains many similar modifications, a single repair may not be enough. See how to plan WordPress development and modernisation or the scope of our WordPress maintenance.