Neugestaltung der TrailRun-Website

Eine vollständig entwickelte Anmelde- und Ticketplattform für einen Traillauf auf einer niederländischen Watteninsel — von Grund auf umgesetzt mit einem eigenen PHP-Framework, direkter Zahlungsabwicklung, PDF-Tickets und automatischem E-Mail-Versand.

Worum geht es bei diesem Projekt?

TrailRun Terschelling ist die Anmeldewebsite für einen jährlichen Traillauf auf der niederländischen Insel Terschelling. Teilnehmer können sich online für 10 km, 15 km oder 25 km anmelden, mit verschiedenen in den Niederlanden üblichen Zahlungsarten bezahlen und sofort ein PDF-Ticket mit eindeutigem Zugangsschlüssel erhalten.

Das Projekt deckt den gesamten Teilnehmerablauf ab: Informationen mit interaktiven Streckenkarten, ein mehrstufiges AJAX-Anmeldeformular mit serverseitiger Prüfung, eine produktive Zahlungsanbindung, PDF-Erzeugung und automatische Transaktions-E-Mails. Alles wird durch ein eigenes schlankes MVC-Framework verbunden.

2025 wurde das gesamte Frontend neu gestaltet: mit neuer CSS-Architektur, Custom Properties, Flexbox-Layout und auf Mobilgeräte ausgerichteten Breakpoints. Zugleich wurde der PHP-Code auf PHP-8-Kompatibilität geprüft, während er weiterhin auf dem Produktionsserver mit seiner Beschränkung auf PHP 5.6 einsetzbar bleiben musste.

Eigenes MVC-Framework

Statt Laravel oder Symfony verwendet das Projekt ein schlankes eigenes Framework, das speziell für solche Veranstaltungsanmeldungen entwickelt wurde. Es ist klein, schnell und technisch vollständig nachvollziehbar — ohne verborgene Mechanismen und unnötigen Ballast.

Seitenklassen

Jede Route führt zu einer konkreten Seitenklasse, die TrailrunWebpage erweitert; diese Klasse erweitert wiederum NSActiveWebpage. Die einzelne Seiteninstanz wird in $_SESSION gespeichert. So bleibt der Formularzustand über AJAX-Aufrufe hinweg erhalten, ohne versteckte Felder oder wiederholte Datenbankzugriffe.

// All routing goes through .htaccess → index.php
// index.php routes to the correct page class

IndexPage      → Home / hero slider / news
RegisterPage   → Multi-step registration form
RoutesPage     → Leaflet map + GPX route overlay
InformatiePage → Static race info content

Das Buchungssystem

Die Anmeldung erfolgt über ein mehrstufiges AJAX-Formular, das jede Änderung mit dem Server abgleicht. Dadurch gehen vor der Zahlung keine Angaben verloren, wenn der Browser geschlossen wird oder die Sitzung abläuft.

Zahlungsablauf

Datenmodell

Die Buchung ist in drei zusammenhängende Entitäten aufgeteilt, damit die Zuständigkeiten klar getrennt bleiben:

Zustandsautomat

Jede Buchung durchläuft festgelegte Zustände. Das verhindert doppelte Zahlungen und erleichtert Prüfungsabfragen:

STATENOPAYMENT  (1)  → Created, awaiting payment
STATEPAID       (2)  → Payment confirmed, PDF + email sent
STATECHANGE     (3)  → Booking modified post-payment
STATECANCELED   (4)  → Cancelled / refunded

Verwaltung der Startplätze

Die EventFactory fragt beim Laden der Seite die Datenbank ab und berechnet die verfügbaren Plätze je Distanz, indem sie bestätigte Buchungen vom festgelegten Maximum abzieht. Ist eine Distanz ausgebucht, wird sie automatisch aus der Auswahl entfernt, ohne manuellen Eingriff.

Anbindung des Zahlungsanbieters

Zahlungen laufen über das EMS e-Commerce Gateway. Es unterstützt die drei für eine niederländische Sportveranstaltung besonders relevanten Verfahren: iDEAL als direkte Bankzahlung, Mastercard und PayPal.

1. 1
   Auftrag anlegenWenn ein Teilnehmer „Bezahlen“ wählt, sendet der Client per AJAX ein Zahlungsereignis (payment_ideal, payment_mastercard oder payment_paypal). Der Server ruft EMSPayment::sendPaymentRequest() auf. Diese Methode berechnet eine HMAC-Signatur über die Auftragsparameter und liefert eine Weiterleitungs-URL zurück.
2. 2
   Weiterleitung zum ZahlungsanbieterDer Browser wird auf die von EMS gehostete Zahlungsseite weitergeleitet. Alle sensiblen Kartendaten werden auf der Domain des Zahlungsanbieters verarbeitet; die Anwendung selbst erhält keine Kartennummern.
3. 3
   Asynchrone RückmeldungNach der Autorisierung sendet EMS das Ergebnis per POST an inschrijven.php. Die Verarbeitung prüft die HMAC-Signatur, um die Echtheit der Antwort sicherzustellen, und liest anschließend chargetotal, txndatetime und den Freigabecode aus.
4. 4
   AbschlussBei approval_code == 'Y' und status == 'APPROVED' wird die Buchung als bezahlt markiert, der vollständige Transaktionsdatensatz in boeking_payment gespeichert und die PDF- und E-Mail-Verarbeitung gestartet. Jedes andere Ergebnis führt zu PAYMENTFAILURE und einer verständlichen Fehlermeldung für den Benutzer.

Die Codebasis enthält außerdem noch die alte Ogone-Zahlungsanbindung als Vorgänger. Sie ist nicht mehr aktiv, bleibt aber als Referenz erhalten, weil frühere Buchungen darüber abgewickelt wurden und das Antwortformat weiterhin in Kommentaren dokumentiert ist.

PDF-Tickets mit PDFlib erzeugen

Jede bestätigte Anmeldung erzeugt ein persönliches, druckfertiges PDF-Ticket. Es wird serverseitig mit PDFlib erstellt, einer kommerziellen PDF-Bibliothek, die wegen ihrer präzisen Layoutsteuerung und zuverlässigen Schriftdarstellung gewählt wurde.

Die Ticket-Factory (framework/factories/PDFTicket.php) erstellt das Dokument per Code — ohne Vorlagendatei, HTML-zu-PDF-Konvertierung oder zwischengeschalteten Renderschritt. Jedes Element wird mit exakten Punktkoordinaten auf einer A4-Seite mit 595 × 842 pt platziert.

Was auf dem Ticket steht

So wird das Dokument erstellt

// Simplified excerpt from PDFTicket::BuildTicket()

$pdf = new PDFlib();
$pdf->set_option("license=m900102-...");
$pdf->begin_document("pdf_gen_tickets/{$nr}.pdf", "");
$pdf->begin_page_ext(595, 842, "");      // A4

// Place branded header image
$img = $pdf->load_image("jpeg", "pdf_ticketkop.jpg", "");
$pdf->fit_image($img, 0, 700, "boxsize={595 130}");

// Distance-specific route map
$routeImg = $pdf->load_image("jpeg", "pdf_{$km}KM.jpg", "");
$pdf->fit_image($routeImg, 300, 480, "boxsize={280 200}");

// Participant name in Helvetica-Bold 14pt
$font = $pdf->load_font("Helvetica-Bold", "winansi", "");
$pdf->setfont($font, 14);
$pdf->show_xy($naam, 40, 650);

// Amount in large 24pt type
$pdf->setfont($font, 24);
$pdf->show_xy("EUR {$amount}", 40, 560);

$pdf->end_page_ext("");
$pdf->end_document("");

Das fertige PDF wird unter pdf_gen_tickets/{BookingNumber}.pdf gespeichert und steht sofort als Anhang der Bestätigungs-E-Mail bereit.

Der Ablauf der Transaktions-E-Mails

Bestätigungs-E-Mails werden unmittelbar nach der Zahlungsprüfung versendet — ohne Warteschlange und Verzögerung. Die PostOffice-Factory kapselt PHPMailer und leitet ausgehende Nachrichten für eine zuverlässige Zustellung über das SMTP-Relay von Mailgun.

1. 1
   Vorlage ladenDie HTML-E-Mail-Vorlage wird aus framework/mail_templates/reserveringsbevestiging.html gelesen. Diese eigenständige HTML-Datei kann auch ohne Programmierkenntnisse bearbeitet werden, ohne PHP-Code anzutasten.
2. 2
   Platzhalter ersetzenPlatzhalter wie [FIRSTNAME], [RESERVATIONNUMBER] und [BOOKINGDATA] werden zur Laufzeit durch die Angaben des Teilnehmers ersetzt. Die tabellarische Buchungsübersicht wird als direkt eingebettetes HTML erzeugt.
3. 3
   PDF anhängenDas neu erzeugte PDF-Ticket (pdf_gen_tickets/{BookingNumber}.pdf) wird vor dem Versand angehängt. Teilnehmer erhalten es innerhalb weniger Sekunden nach der Zahlungsbestätigung.
4. 4
   Versand per SMTPPHPMailer sendet über smtp.eu.mailgun.org:25 an die Adresse des Teilnehmers. Eine verdeckte BCC-Kopie geht für die Dokumentation an die Veranstalter. Der Betreff enthält die Buchungsnummer: Inschrijf bevestiging TrailRun Terschelling 2027 [TRT-00123].

// PostOffice::sendConformation() — core logic

$body = file_get_contents('framework/mail_templates/reserveringsbevestiging.html');
$body = str_replace('[FIRSTNAME]',          $boeking->Voorletters(),   $body);
$body = str_replace('[RESERVATIONNUMBER]',   $boeking->Boekingsnummer(), $body);
$body = str_replace('[BOOKINGDATA]',         $itemTable,               $body);

$mail->AddAttachment("pdf_gen_tickets/{$nr}.pdf");
$mail->AddBCC('info@mooi-weer.nl');
$mail->Send();

Frontend und Neugestaltung 2025

Die Neugestaltung 2025 ersetzte ein veraltetes Layout durch ein modernes Designsystem mit Schwerpunkt auf Mobilgeräten. Der zugrunde liegende PHP-Code blieb dabei nach Möglichkeit unverändert. Die Bildsprache greift bewusst den rauen Outdoor-Charakter der Veranstaltung auf.

Erzeugte Produktionsdateien

Das CSS wird in css/design.css mit 1752 Zeilen gepflegt und für den Produktivbetrieb zu design.min.css minimiert. Das JavaScript des Anmeldeformulars wird von js/inschrijven.js zu inschrijven.min.js minimiert. Die .htaccess aktiviert gzip-Komprimierung für CSS-, JavaScript- und Schriftdateien und setzt weitreichende Cache-Header für statische Dateien.

Die Herausforderung der PHP-Kompatibilität

Die produktive Hosting-Umgebung ist auf PHP 5.6 beschränkt. Gleichzeitig muss der Code eine PHP-8-Syntaxprüfung bestehen und auf dem Entwicklungsrechner sauber unter PHP 8 laufen. Das ist die anspruchsvollste einzelne Vorgabe dieses Projekts.

2025 wurde jede PHP-Datei auf Funktionen geprüft, die sich zwischen diesen Versionen unterschiedlich verhalten:

1. 1
   mysqli_* statt mysql_*Alle alten Aufrufe von mysql_query(), mysql_fetch_array() und verwandten Funktionen wurden durch ihre mysqli_*-Entsprechungen ersetzt, die sowohl unter PHP 5.6 als auch unter PHP 8 verfügbar sind.
2. 2
   Iterator-Schnittstelle Collection-Klassen müssen die passende Iterator-Schnittstelle implementieren. Sowohl Iterator als auch IteratorAggregate gab es bereits vor PHP 8. Code, der unter PHP 5.6 laufen muss, kann keine Rückgabetypdeklarationen verwenden: Diese Version unterstützt die entsprechende Syntax nicht. Die Typen werden stattdessen in Docblocks dokumentiert. Ab PHP 8.1 sind zudem vorläufige Rückgabetypen interner Schnittstellen zu berücksichtigen.
3. 3
   Syntax für ZeichenkettenindizesPHP 8 unterstützt die Indizierung mit geschweiften Klammern ($str{0}) nicht mehr. Alle Vorkommen wurden auf die Syntax mit eckigen Klammern ($str[0]) umgestellt, die in beiden Versionen gültig ist.
4. 4
   Keine Typangaben für ParameterPHP 5.6 unterstützt weder skalare Typangaben noch Rückgabetypen in Funktionssignaturen. Der gesamte Code wurde ohne diese geschrieben; stattdessen unterstützen Docblock-Kommentare die Entwicklungsumgebung.

Alle Technologien

Jede Komponente wurde aus praktischen Gründen gewählt — kein Framework um seiner selbst willen und keine Abhängigkeit ohne konkreten Nutzen.

Erkenntnisse und Lehren

Was dieses Projekt über seine Funktionsliste hinaus zeigt.