Jak wyświetlić minione wydarzenia w The Events Calendar
Jak pokazać minione wydarzenia w The Events Calendar bez kodu, shortcode’em lub przez bezpieczne nadpisanie widoku. Aktualizacja starego poradnika.
Najważniejsza informacja: kod z 2014 roku jest archiwalny
Minione wydarzenia w The Events Calendar najbezpieczniej wyświetlić przez wbudowany widok archiwum, link w menu albo aktualny shortcode dostępny w Events Calendar Pro. Nie należy dziś kopiować klasy widgetu i plików PHP z pierwotnej wersji tego artykułu.
Poradnik z 2014 roku rozszerzał klasy TribeEventsAdvancedListWidget, TribeEventsPro_Widgets oraz TribeEventsPro, a następnie dodawał własny widok administratora bezpośrednio do katalogu wtyczki. Współczesny The Events Calendar korzysta z innej architektury Views v2, bloków i innych ścieżek szablonów. Stary kod zawierał również encje HTML oraz typograficzne cudzysłowy zamiast poprawnej składni PHP.
Usunęliśmy go z artykułu, ponieważ samo „oczyszczenie” znaków stworzyłoby kod wyglądający wiarygodnie, lecz oparty na nieaktualnych interfejsach. Poniższe rozwiązania zostały sprawdzone z dokumentacją dostawcy 6 sierpnia 2026 roku. Przy późniejszym wdrożeniu ponownie porównaj instrukcję z wersją wtyczki działającą na stronie.
Wybierz rozwiązanie według potrzeby
| Potrzeba | Najprostsze rozwiązanie | Czy wymaga kodu? |
|---|---|---|
| Osobna strona ze wszystkimi minionymi wydarzeniami | Wbudowany widok eventDisplay=past | Nie |
| Link „Archiwum wydarzeń” w menu lub kolumnie | Własny link do widoku minionych wydarzeń | Nie |
| Osadzenie kalendarza dla wybranego minionego okresu | Shortcode [tribe_events] w wersji Pro | Nie, ale wymaga Pro |
| Najnowsze minione wydarzenia na początku | Oficjalny filtr producenta dla Views v2 | Tak |
| Zmiana HTML i wyglądu listy | CSS, hook albo nadpisanie szablonu w motywie potomnym | Zależnie od zakresu |
Nie zaczynaj od własnego widgetu PHP, jeśli celem jest tylko udostępnienie archiwum. Każda dodatkowa klasa zwiększa koszt aktualizacji, testów i reakcji na zmiany w API wtyczki.
Opcja 1. Link do wbudowanego archiwum minionych wydarzeń
The Events Calendar udostępnia widok przeszłych wydarzeń pod adresem z parametrem:
https://twoja-domena.pl/events/list/?eventDisplay=past
Fragment /events/ zależy od slugu skonfigurowanego na konkretnej stronie. Najpierw otwórz zwykły kalendarz, przełącz się na listę minionych wydarzeń i skopiuj działający adres. Nie wpisuj ścieżki na pamięć, jeśli serwis używa innego języka lub niestandardowego slugu.
Następnie dodaj odnośnik „Minione wydarzenia”, „Archiwum” albo „Zobacz relacje” w jednym z miejsc:
- menu głównym lub podrzędnym kalendarza;
- bloku na stronie wydarzeń;
- stopce;
- bocznej kolumnie jako blok przycisku lub nawigacji.
To rozwiązanie działa bez tworzenia nowego widgetu. Producent opisuje je w aktualnej dokumentacji Working with Past Events.
Przetestuj link po wylogowaniu i w trybie prywatnym. Jeśli strona zwraca błąd, sprawdź ustawienia bezpośrednich odnośników, slug archiwum i konflikt z istniejącą stroną WordPressa o tej samej nazwie.
Opcja 2. Blok lub widget jako wejście do archiwum
Wtyczka oferuje blok Events List oraz klasyczny widget listy wydarzeń. Według bieżącej dokumentacji bazowy widget należy do darmowego The Events Calendar, a wersja Pro dodaje filtry i dodatkowe pola. Standardowa lista jest jednak skoncentrowana na wydarzeniach nadchodzących.
Jeśli w bocznej kolumnie potrzebujesz jedynie wejścia do archiwum, użyj zwykłego bloku przycisku, akapitu lub nawigacji z adresem eventDisplay=past. Jest to prostsze i bardziej przewidywalne niż modyfikowanie zapytania całego widgetu.
W Site Editorze umieść taki blok bezpośrednio w szablonie strony albo stopki. W motywie klasycznym dodaj go w obszarze widgetów. Nadaj linkowi opisową nazwę; samo „Zobacz więcej” nie wyjaśnia, że prowadzi do zakończonych wydarzeń.
Gdy obok linku ma pojawić się kilka ręcznie wybranych relacji, można przygotować osobną listę kart lub zapytanie o wpisy podsumowujące. To często lepszy model marketingowy niż automatyczna lista wszystkich dat: pozwala pokazać zdjęcie, rezultat, materiały do pobrania i następne wydarzenie związane z tematem.
Opcja 3. Shortcode w Events Calendar Pro
Posiadacze wersji Pro mogą osadzać widoki kalendarza shortcode’em [tribe_events]. Dokumentacja producenta wskazuje, że miniony okres można pokazać przez wybór wcześniejszej daty, a parametr dotyczący przeszłych wydarzeń ma ograniczenie do widoku miesięcznego.
Nie kopiujemy tu pełnej składni, ponieważ obsługiwane argumenty i zachowanie widoków są zależne od wersji. Otwórz aktualną dokumentację shortcode’ów z panelu pomocy wtyczki, wybierz widok Month i ustaw datę, którą chcesz pokazać. Następnie sprawdź:
- czy na stronie istnieje tylko jedna główna nawigacja kalendarza;
- co widzi użytkownik po przejściu do kolejnego miesiąca;
- czy zakres dat rzeczywiście obejmuje potrzebne wydarzenia;
- jak zachowuje się widok na telefonie i bez JavaScriptu;
- czy strona nie powiela identycznej treści dostępnej pod innym adresem.
Shortcode ma sens, gdy archiwum stanowi część konkretnej strony, na przykład podsumowania sezonu. Jeśli potrzebujesz zwykłego, stałego archiwum, wbudowany adres jest łatwiejszy do utrzymania.
Jak ustawić najnowsze minione wydarzenia na początku
Widok listy może przedstawiać przeszłe wydarzenia chronologicznie od najstarszego. Dla archiwum relacji częściej użyteczna jest kolejność odwrotna: wydarzenie zakończone ostatnio pojawia się jako pierwsze.
Producent udostępnia aktualny snippet dla Views v2, oparty między innymi na filtrze tribe_events_views_v2_view_list_template_vars. Zamiast przepisywać go do artykułu, skorzystaj z wersji utrzymywanej w dokumentacji Showing Past Events in Reverse Order. Dzięki temu przed wdrożeniem zobaczysz ewentualną zmianę API.
Kod dodaj jako małą, opisaną wtyczkę funkcjonalną albo w zarządzanym mechanizmie snippetów. functions.php motywu potomnego jest dopuszczalny przy prostym wdrożeniu, ale po zmianie motywu funkcja zniknie. Nie wklejaj kodu do motywu nadrzędnego i nie edytuj plików The Events Calendar.
Przed aktywacją:
- wykonaj kopię bazy i plików;
- sprawdź zgodność używanych wersji WordPressa, PHP i wtyczki;
- przetestuj zmianę na środowisku stagingowym;
- ogranicz filtr wyłącznie do właściwego widoku;
- sprawdź brak wydarzeń, paginację, serie i wydarzenia wielodniowe;
- przygotuj prosty sposób wyłączenia snippetu.
Kiedy nadpisywać szablon widgetu?
Nadpisanie szablonu służy zmianie struktury HTML, nie powinno być pierwszym sposobem na zmianę zakresu danych. Aktualna dokumentacja wskazuje źródłowy plik listy pod ścieżką:
wp-content/plugins/the-events-calendar/src/views/v2/widgets/widget-events-list.php
Kopię umieszcza się w aktywnym motywie potomnym z zachowaniem katalogów:
wp-content/themes/twoj-motyw-potomny/tribe/events/v2/widgets/widget-events-list.php
Szczegóły i aktualne ścieżki opisuje dokumentacja Using the Events List Widget. Przed kopiowaniem porównaj ją z nagłówkiem pliku w zainstalowanej wersji. Wtyczka może rozdzielać widok na mniejsze części, a przykład dla starszej wersji nie musi pasować do obecnej.
Nadpisanie chroni plik przed bezpośrednim skasowaniem podczas aktualizacji wtyczki, ale nie zwalnia z utrzymania. Po większej aktualizacji porównaj własną kopię z nowym szablonem źródłowym. Inaczej można zachować nieaktualny markup, pominąć poprawkę dostępności albo wywoływać zmienną, której nowa wersja już nie przekazuje.
Jeśli zmiana dotyczy wyłącznie koloru, odstępu lub rozmiaru, najpierw użyj CSS. Jeśli trzeba dodać mały element, sprawdź dostępne hooki. Pełny override zwiększa swobodę, ale przejmuje odpowiedzialność za cały kopiowany fragment.
Czego nie robić przy modyfikacji wtyczki
Pierwotny poradnik polecał stworzenie pliku panelu administracyjnego wewnątrz wp-content/plugins/event-calendar-pro/admin-views/. To rozwiązanie nie było odporne na aktualizacje: pliki w katalogu wtyczki mogą zostać zastąpione, a prywatne klasy i widoki administratora nie stanowią stabilnego kontraktu dla własnego kodu.
Unikaj następujących działań:
- edycji plików w katalogu
plugins; - kopiowania klasy ze starego wydania bez sprawdzenia bieżącego API;
- wyłączania aktualizacji na stałe tylko po to, by zachować modyfikację;
- uruchamiania fragmentu z bloga bez stagingu i możliwości wycofania;
- wyświetlania niesanitowanych danych wydarzenia we własnym HTML;
- rejestrowania drugiego widgetu, gdy wystarcza link lub shortcode;
- ukrywania błędu PHP zamiast usunięcia jego przyczyny.
Jeżeli własne wymaganie jest krytyczne, zapisz dokładne wersje zależności i dodaj test dymny wykonywany po aktualizacji. Fragment działający dziś może przestać działać po zmianie hooka, struktury danych albo szablonu.
Jak zaprojektować dobre archiwum wydarzeń
Techniczna lista nie wystarcza, jeśli odbiorca ma zobaczyć doświadczenie organizatora. Dla każdego wydarzenia warto pokazać nazwę, datę, miejsce lub informację „online”, kategorię oraz obraz tylko wtedy, gdy wnosi znaczenie. Najnowsze pozycje zwykle powinny pojawić się pierwsze.
Rozważ połączenie wydarzenia z relacją:
- podsumowaniem i najważniejszym wnioskiem;
- zdjęciami z prawami do publikacji i opisami alternatywnymi;
- prezentacją, nagraniem lub materiałem do pobrania;
- informacją o kolejnej edycji;
- powiązaną usługą lub artykułem, jeśli jest naturalnym następnym krokiem.
Rozróżnij wyraźnie „nadchodzące” i „minione”. Nie pokazuj przy zakończonym wydarzeniu przycisku „Zapisz się”, jeśli rejestracja nie dotyczy kolejnej edycji. Stan pusty powinien wyjaśniać, że nie ma jeszcze archiwum i prowadzić do bieżącego kalendarza.
Przy dużej liczbie pozycji dodaj paginację lub filtry po roku i kategorii. Nie ładuj setek wydarzeń do jednego widgetu w stopce. Krótka lista może prowadzić do pełnego archiwum, które ma własny tytuł, opis i stabilny adres.
Test po wdrożeniu
Przejdź listę jako osoba wylogowana i sprawdź:
- wydarzenie zakończone wczoraj, wielodniowe i cykliczne;
- granicę strefy czasowej oraz zmianę dnia;
- kolejność, paginację i filtry;
- widok pusty oraz błędny parametr adresu;
- tytuł linku, fokus klawiatury i czytelność na telefonie;
- pamięć podręczną po zmianie daty wydarzenia;
- działanie po aktualizacji The Events Calendar i Events Calendar Pro.
Zapisz w dokumentacji projektu, dlaczego wybrano konkretną metodę, gdzie znajduje się kod i jak go wyłączyć. To szczególnie ważne w WordPressie, gdzie kolejny opiekun może znaleźć snippet dopiero podczas awarii.
Jeśli stary serwis zawiera wiele podobnych modyfikacji, pojedyncza naprawa może nie wystarczyć. Zobacz, jak zaplanować rozwój i modernizację strony WordPress albo zakres naszej opieki nad WordPressem.
Masz problem do rozwiązania?
Sprawdźmy, od czego warto zacząć
Opisz sytuację w kilku zdaniach. Wrócimy z pytaniami lub propozycją konkretnego następnego kroku.
