System rezerwacji dla TYPO3: Rezerwacja terminów i rezerwacje online

Rezerwacja terminów na stronie internetowej w TYPO3 często zawodzi z powodu niedojrzałości rozszerzeń

Firmy oferujące konsultacje, wynajem sal czy kursy chcą zintegrować rezerwację online bezpośrednio w swojej witrynie TYPO3. Oczekiwanie: kalendarz, sprawdzanie dostępności, płatność, e-mail potwierdzający - wszystko w jednym. Rzeczywistość: w TYPO3 Extension Repository (TER) nie ma pojedynczego rozszerzenia rezerwacyjnego, które pokrywałoby wszystkie te wymagania na poziomie produkcyjnym. Dostępne rozwiązania (jcc_appointment, cab_single_booking, różne własne rozwiązania) obsługują przypadki niszowe lub nie są aktywnie utrzymywane.

Dlatego system rezerwacji TYPO3 to prawie zawsze hybryda: bazowe rozszerzenie lub rozwój niestandardowy dla logiki podstawowej, w połączeniu z providerami płatności (Stripe, PayPal, Mollie) i interfejsami kalendarza (iCal, Google Calendar API). Gosign wdrożył to podejście w ponad 15 projektach.

Typowe scenariusze zastosowań

Firmy doradcze z rezerwacją terminów. Doradcy podatkowi, prawnicy, konsultanci biznesowi potrzebują systemu, w którym klienci widzą i rezerwują wolne sloty. Kalendarz synchronizuje się z Outlook lub Google Calendar doradcy. Płatność jest opcjonalna (często rozliczenie następuje po konsultacji), ale muszą być odwzorowywalne terminy anulowania i opłaty za niestawiennictwo. Typowa konfiguracja: 3 doradców, 4 rodzaje usług, sloty 30-minutowe, 2 lokalizacje.

Organizatorzy szkoleń i kursów. Ośrodki edukacyjne, szkoły policealne, kluby sportowe oferują kursy z ograniczoną liczbą miejsc. System rezerwacji potrzebuje list uczestników, list oczekujących, cen grupowych, zniżek za wczesną rezerwację i terminów seryjnych (np. 10 lekcji jogi jako pakiet). Płatność następuje przy rezerwacji, anulowanie z częściowym zwrotem musi być zautomatyzowane.

Wynajem pomieszczeń i zarządzanie zasobami. Przestrzenie coworkingowe, hotele konferencyjne, obiekty sportowe wynajmują sale lub miejsca godzinowo. Tu liczy się wyświetlanie dostępności w czasie rzeczywistym: żadne pomieszczenie nie może być podwójnie zarezerwowane, nawet gdy dwóch użytkowników jednocześnie kliknie “Rezerwuj”. Ochrona przed race conditions na poziomie bazy danych to nie nice-to-have, lecz wymóg.

Architektura techniczna

Produkcyjny system rezerwacji w TYPO3 składa się z czterech warstw. Warstwa bazy danych zarządza zasobami (sale, osoby, urządzenia), dostępnościami (okna czasowe, blokady, święta) i rezerwacjami (ze statusem: zapytanie, potwierdzona, anulowana, zakończona). Warstwa logiki sprawdza dostępność, zapobiega podwójnym rezerwacjom i oblicza ceny. Warstwa płatności komunikuje się z zewnętrznymi dostawcami płatności przez ich API. Warstwa powiadomień wysyła potwierdzenia, przypomnienia i e-maile o anulowaniu.

Do zapobiegania podwójnym rezerwacjom istnieją trzy podejścia: blokowanie pesymistyczne (SELECT … FOR UPDATE), blokowanie optymistyczne (numer wersji w tabeli rezerwacji) lub oparte na kolejce (żądania rezerwacji przetwarzane sekwencyjnie). Wybór zależy od oczekiwanego obciążenia. Przy mniej niż 100 rezerwacjach dziennie wystarczy blokowanie optymistyczne, przy eventach z 1000 jednoczesnych dostępów kolejka jest bardziej niezawodna.

Eksport iCal jest standardem: każda potwierdzona rezerwacja generuje plik .ics, który jest wysyłany jako załącznik w e-mailu potwierdzającym. Do dwukierunkowej synchronizacji (rezerwacja w TYPO3 pojawia się w Google Calendar i odwrotnie) potrzebne jest Google Calendar API lub CalDAV.

Częste problemy i rozwiązania

Podwójne rezerwacje mimo sprawdzania dostępności. Najczęstsza przyczyna: sprawdzenie “Czy slot jest wolny?” i wstawienie rezerwacji nie odbywają się w tej samej transakcji bazodanowej. Między sprawdzeniem a insertem mogą upłynąć milisekundy, w których drugi użytkownik zarezerwuje ten sam slot. Rozwiązanie: zamknięcie sprawdzenia i insertu w jednej transakcji z blokadą wiersza.

Callbacki płatności nie docierają. Stripe i PayPal wysyłają potwierdzenia płatności przez webhook. Jeśli witryna TYPO3 jest za reverse proxy lub firewallem, callbacki nie docierają do serwera. Rozwiązanie: udostępnienie URL webhook przez dedykowaną trasę (np. /api/payment/webhook), która nie jest blokowana przez cachowanie TYPO3 czy reguły .htaccess.

Chaos stref czasowych przy rezerwacjach międzynarodowych. Gdy rezerwujący i zasób są w różnych strefach czasowych, pojawiają się błędy. Rozwiązanie: przechowywanie wszystkich czasów wewnętrznie jako UTC, wyświetlanie w frontendzie dostosowane do lokalnej strefy czasowej użytkownika przez JavaScript.

Migracja i kompatybilność wersji

Nie istnieje jednolite rozszerzenie rezerwacyjne z oficjalnym wsparciem TYPO3 v12/v13. Większość dostępnych rozszerzeń zatrzymała się na v10 lub v11. Kto migruje istniejący system rezerwacji na TYPO3 v12+, ma dwie opcje: portowanie logiki niestandardowej na Extbase/Doctrine (kompatybilne z v12) lub wydzielenie logiki rezerwacyjnej jako mikroserwisu API z renderowaniem tylko frontendu w TYPO3.

Dla nowych projektów zalecane jest podejście API-first: silnik rezerwacji jako REST-API (w TYPO3 lub jako oddzielny serwis), frontend jako komponent webowy osadzany w każdym szablonie TYPO3. Dzięki temu system rezerwacji pozostaje niezależny od głównych aktualizacji TYPO3. Gosign stosuje to podejście jako standard od 2024 roku.

Gosign kalkuluje typowy projekt systemu rezerwacji (3 typy zasobów, płatność Stripe, workflow e-mail, eksport iCal) na 15 do 25 dni deweloperskich. Z tego około 40% przypada na logikę rezerwacyjną ze sprawdzaniem dostępności, 25% na integrację płatności, 20% na szablony e-mail i powiadomienia oraz 15% na prezentację frontendową i testy.