Friederike Lindeckes bisherige Jimdo-Seite war sichtbar in die Jahre gekommen. Die neue Website sollte moderner wirken, mehr Anfragen ermöglichen und trotzdem nicht den Pflegeaufwand eines großen Content-Management-Systems mitbringen.
Die Lösung wurde deshalb nicht „größer“, sondern gezielter: eine individuelle PHP-Website mit einem kleinen geschützten Backend für Seminare und Kontaktanfragen. Texte und Leistungsseiten bleiben bewusst fest im Code. Nur die Inhalte, die Friederike regelmäßig ändern muss, sind dynamisch.
Von Jimdo zur individuellen Website
Vor dem Projekt wurden Seminare über PDF-Flyer angekündigt und Anmeldungen per E-Mail abgewickelt. Die Jimdo-Seite bot zwar einen visuellen Builder, passte gestalterisch aber nicht mehr zum Auftritt der Praxis. Das Ziel war eine ruhigere, persönlichere Website und ein klarer Weg von der Information zur Anfrage.
Der neue Auftritt umfasst neben der Startseite eigene Bereiche für Therapieangebote, Seminare, Konditionen, die Person hinter der Praxis und Kontakt. Die Sonderlösung liegt unter der Oberfläche: Friederike kann Seminare pflegen und eingehende Anfragen bearbeiten, ohne Zugriff auf Layout, Templates oder technische Einstellungen zu benötigen.
Eine fertige Seminarplattform hätte zwar noch mehr Funktionen mitgebracht: Onlinezahlung, automatische Erinnerungen, feste Platzkontingente und Teilnehmerexporte. Genau diese Funktionen waren hier aber nicht Teil des Arbeitsablaufs. Sie hätten laufende Kosten, ein weiteres Benutzerkonto und einen verbindlichen Buchungsprozess eingeführt, obwohl Anmeldungen weiterhin persönlich bestätigt werden sollten.
Die Sonderlösung verbindet stattdessen Website und Verwaltung direkt. Ein neu gespeichertes Seminar ist ohne Synchronisation auf der öffentlichen Seite verfügbar. Es gibt keine externe Plattform, deren Gestaltung an die Praxis angepasst werden muss, und keine Daten, die zusätzlich in einem Drittsystem gepflegt werden. Der geringere Funktionsumfang ist in diesem Fall ein Produktvorteil.
Warum kein klassisches CMS?
WordPress wäre technisch möglich gewesen, hätte für diesen Umfang aber deutlich mehr Verwaltungsoberfläche, Updates und potenzielle Angriffspunkte mitgebracht. Ein kompletter Website-Builder war ebenfalls nicht nötig. Der Großteil der Inhalte ändert sich selten.
Die entscheidende Frage war daher nicht „Welches CMS nehmen wir?“, sondern „Welche Inhalte müssen wirklich editierbar sein?“. Die Antwort: Seminare und die daraus entstehenden Anfragen. Dafür entstand ein maßgeschneidertes Backend; alles andere bleibt eine schlanke PHP-Seite ohne Theme- und Plugin-Abhängigkeiten.
Eine Individualentwicklung muss nicht bedeuten, jedes CMS-Feature nachzubauen. Wartbar wird die Lösung gerade dadurch, dass Redaktionsfunktionen nur dort existieren, wo sie im Alltag gebraucht werden.
PHP und JSON statt großer Datenbank
Die Website läuft mit PHP 8 und benötigt weder Framework noch MySQL-Datenbank. Seminare und Kontaktanfragen werden als strukturierte JSON-Daten in geschützten Verzeichnissen gespeichert. Für den überschaubaren Datenumfang ist das einfacher zu sichern und zu warten als ein zusätzliches Datenbanksystem.
Jedes Seminar enthält Titel, Untertitel, Kategorie, URL-Slug, Bild, mehrere Termine, Ort, Preis, verfügbare Plätze und eine ausführliche Beschreibung. Öffentliche Seiten lesen dieselben Daten, sortieren Termine chronologisch und blenden vergangene Veranstaltungen automatisch aus.
Entscheidend war die Trennung zwischen statischen Fachinhalten und dynamischen Betriebsdaten. Therapieangebote, Konditionen und die Über-mich-Seite werden nur selten geändert und liegen direkt in klar gegliederten PHP-Templates. Seminare dagegen besitzen einen eigenen Lebenszyklus: Sie werden angelegt, erhalten mehrere Termine, ändern sich und verschwinden nach dem letzten Termin aus der öffentlichen Übersicht.
Diese Trennung hält das System klein. Es gibt keine universelle Seitentabelle, keinen Block-Editor und keine abstrakte Komponentenverwaltung. Das Backend kennt genau eine redaktionelle Aufgabe und bildet sie mit den Begriffen ab, die Friederike auch im Alltag verwendet.
- Titel, Untertitel, Tagline und ausführliche Beschreibung
- eindeutige URL und optionales Titelbild mit Alternativtext
- beliebig mehrere Kombinationen aus Datum und Uhrzeit
- Ort, Preis und verfügbare Plätze
- Zeitstempel für Erstellung und letzte Bearbeitung
JSON ist hier keine Notlösung, sondern eine bewusste Größenentscheidung. Es gibt eine Redakteurin, wenige Datensätze und keine komplexen gleichzeitigen Transaktionen. Die Dateien lassen sich direkt sichern und bei Bedarf lesen. Schreibvorgänge verwenden eine exklusive Dateisperre, damit nicht zwei Prozesse gleichzeitig eine unvollständige Datei erzeugen. Sobald mehrere Bearbeiter, verbindliche Buchungen oder umfangreiche Auswertungen nötig würden, wäre der Wechsel auf eine Datenbank der richtige nächste Schritt.
// Schreiben: JSON_PRETTY_PRINT hält die Datei lesbar, LOCK_EX verhindert,
// dass zwei Prozesse gleichzeitig eine halbe Datei hinterlassen.
function seminare_save(array $seminare): bool {
$json = json_encode($seminare,
JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
return file_put_contents(SEMINARE_FILE, $json, LOCK_EX) !== false;
}
// Lesen: alte Datensätze hatten ein einzelnes date-Feld. Die Migration
// läuft beim Laden, nicht als Einmal-Skript - so bleibt Bestehendes kompatibel.
function seminare_load(): array {
$data = json_decode(file_get_contents(SEMINARE_FILE), true);
if (!is_array($data)) return [];
foreach ($data as &$s) {
if (empty($s['dates']) && !empty($s['date'])) {
$s['dates'] = [['date' => $s['date'], 'time' => $s['time'] ?? '']];
}
$s['dates'] = $s['dates'] ?? [];
}
return $data;
}
// Öffentliche Übersicht: sortiert nach dem nächsten noch offenen Termin.
// Ein Seminar mit drei Terminen bleibt so bis zum letzten Termin sichtbar.
function seminar_next_date(array $seminar): ?array {
$today = date('Y-m-d');
$future = array_filter($seminar['dates'] ?? [],
fn($d) => ($d['date'] ?? '') >= $today);
usort($future, fn($a, $b) => strcmp($a['date'], $b['date']));
return $future[0] ?? null;
}Seminare selbst verwalten
Im geschützten Bereich kann Friederike Seminare anlegen, bearbeiten und löschen. Mehrere Termine werden direkt am Seminar gepflegt. Bilder lassen sich hochladen oder ersetzen; Dateityp und Größe werden serverseitig geprüft. Fehlt ein URL-Slug, erzeugt das Backend ihn automatisch aus dem Titel.
Auf der öffentlichen Seminarübersicht erscheinen nur Veranstaltungen mit zukünftigen Terminen. Jede Detailseite zeigt Beschreibung, Termine, Ort, Preis und Teilnehmerzahl. Für Suchmaschinen entstehen zusätzlich strukturierte Event-Daten und die dynamischen Seminarseiten werden in die Sitemap aufgenommen.
Beim Speichern prüft das Backend nicht nur Pflichtfelder. Slugs müssen eindeutig bleiben, hochgeladene Bilder werden nach Typ und Größe kontrolliert und alte Bilddateien bei einem Austausch gezielt entfernt. Für bestehende Datensätze gibt es außerdem eine kleine Migration: Ein früher einzelnes Datumsfeld wird beim Laden in die heutige Liste mehrerer Termine überführt. So bleiben bereits erfasste Inhalte kompatibel, obwohl die Funktion später erweitert wurde.
Auf der öffentlichen Seite wird nicht einfach die Reihenfolge aus der Datei ausgegeben. Für jedes Seminar wird der nächste noch nicht vergangene Termin ermittelt; danach sortiert die Übersicht chronologisch. Ein Seminar mit drei Terminen bleibt dadurch bis zum letzten Termin sichtbar, ohne dass Friederike es mehrfach anlegen oder später manuell ausblenden muss.
Vom Seminar zur Anfrage
Der Button „Jetzt anmelden“ führt nicht in einen unnötig komplexen Buchungsprozess. Er öffnet das Kontaktformular bereits mit dem Thema „Seminar“ und dem gewählten Seminartitel. Besucher ergänzen ihre Kontaktdaten und Nachricht.
Nach dem Absenden wird die Anfrage im Backend gespeichert und zusätzlich per E-Mail weitergeleitet. Das Dashboard zeigt neue und gesamte Anfragen. Friederike kann Nachrichten lesen, als gelesen oder ungelesen markieren, per E-Mail antworten und bei Bedarf löschen. Es handelt sich bewusst um eine Anfrageverwaltung, nicht um ein automatisches Ticket-, Zahlungs- oder Teilnehmerlistensystem.
Die Entscheidung gegen einen vollautomatischen Checkout war fachlich, nicht technisch. Bei einem kleinen, persönlichen Seminarangebot ist eine kurze Rückfrage oft sinnvoller als sofortige Zahlung und fest verbuchte Teilnahme. Die Seite nimmt deshalb Reibung aus der Anfrage, ohne den persönlichen Prozess zu ersetzen.
Das vorausgefüllte Formular übergibt Seminartitel und Thema über die URL, prüft aber alle Daten erneut auf dem Server. Neben Name und E-Mail können Telefonnummer und Nachricht erfasst werden. Eine erfolgreiche Anfrage landet sowohl im geschützten Backend als auch im E-Mail-Postfach. Damit gibt es eine zentrale Übersicht, ohne dass Friederike ihre gewohnte Kommunikation aufgeben muss.
Sicherheit ohne Plugin-Stapel
Weniger Komponenten bedeuten weniger laufenden Pflegeaufwand, aber nicht den Verzicht auf Sicherheitsmaßnahmen. Das Backend verwendet Passwort-Hashes, geschützte Sessions sowie CSRF-Tokens für schreibende Aktionen. Ausgaben werden escaped und sensible Verzeichnisse sind per Serverkonfiguration vor direktem Zugriff geschützt.
Das Kontaktformular kombiniert serverseitige Validierung, Honeypot, Sitzungs-Rate-Limit und Datenschutzbestätigung. Bild-Uploads akzeptieren nur definierte Formate und Größen. Die Lösung reduziert damit die typische Plugin- und Update-Fläche eines CMS, ohne Sicherheit mit „kein CMS“ gleichzusetzen.
Auch die Wartung wurde auf den tatsächlichen Umfang zugeschnitten. Navigation, Kopfbereich und Footer liegen in gemeinsamen Includes; globale Gestaltung und responsive Regeln in einem zentralen Stylesheet. Dadurch muss eine Telefonnummer oder Navigation nicht auf jeder Unterseite einzeln geändert werden, obwohl kein CMS dazwischenliegt.
Die reduzierte Architektur spart Plugin-Updates, ersetzt aber keine Pflege. PHP-Version, Serverkonfiguration und Backups müssen weiterhin kontrolliert werden. Der Unterschied: Es existiert nur eine kleine, nachvollziehbare Codebasis statt eines allgemeinen Redaktionssystems mit Funktionen, die das Projekt nie verwendet.
Das Ergebnis
Innerhalb weniger Wochen entstand eine vollständige, responsive Praxis-Website mit einer klar begrenzten Verwaltungsoberfläche. Friederike kann das Seminarangebot selbst aktuell halten und Anfragen an einer Stelle überblicken. Gleichzeitig bleiben Design und technische Struktur vor versehentlichen Änderungen geschützt.
- Moderner individueller Auftritt statt alter Jimdo-Vorlage
- Seminarpflege ohne Eingriff in Layout oder Code
- Mehrere Termine und automatische Ausblendung vergangener Veranstaltungen
- Direkter Weg vom Seminar zur vorausgefüllten Anfrage
- Weniger Update- und Plugin-Pflege als bei einem vollständigen CMS
„Joshua Maurer hat meinen Auftrag für die Erstellung bzw. Neugestaltung meiner Homepage übernommen und meine Erwartungen übertroffen! Ein super Kontakt, souverän, kompetent, freundlich und schnell. … Eine Herzensempfehlung!“– Google-Bewertung von Friederike Lindecke
Die Website ist unter friederikelindecke.de erreichbar. Das Projekt zeigt, wie sich eine individuell erstellte Website mit gezielter Web-Programmierung verbinden lässt: Nur wenige Inhalte müssen dynamisch sein, diese dafür aber exakt zum Arbeitsablauf passen.
Ein größeres Beispiel für eine maßgeschneiderte Verwaltungsoberfläche zeigt der Berichts-Projektmanager für ein ökologisches Gutachterbüro.
Häufige Fragen zu individuellen PHP-Websites
Braucht eine kleine Website immer ein CMS?
Nein. Wenn sich nur wenige klar definierte Inhalte ändern, kann eine schlanke Individualentwicklung mit einem gezielten Admin-Bereich wartungsärmer sein als ein vollständiges CMS.
Warum werden die Seminare in JSON statt MySQL gespeichert?
Der Datenumfang ist klein und die Zugriffe sind überschaubar. Eine geschützte JSON-Datei hält die Architektur einfach. Bei komplexen Buchungen, vielen gleichzeitigen Bearbeitern oder umfangreichen Auswertungen wäre eine Datenbank sinnvoller.
Verwaltet das System verbindliche Seminarbuchungen?
Nein. Besucher senden über ein vorausgefülltes Kontaktformular eine Seminaranfrage. Friederike verwaltet diese Anfragen im Backend und bestätigt die Teilnahme persönlich.
Ist eine Website ohne WordPress automatisch sicher?
Nein. Auch individuelle PHP-Seiten benötigen sichere Authentifizierung, CSRF-Schutz, validierte Eingaben, geschützte Datenspeicherung und Updates der Serverumgebung. Die kleinere Angriffsfläche ersetzt diese Maßnahmen nicht.
Was passiert, wenn zwei Personen gleichzeitig ein Seminar speichern?
Schreibvorgänge verwenden eine exklusive Dateisperre (LOCK_EX). Damit kann keine halb geschriebene JSON-Datei entstehen. Für den Fall echter Mehrbenutzer-Redaktion mit vielen parallelen Änderungen wäre eine Datenbank der richtige nächste Schritt.
Lässt sich die Lösung später auf eine Datenbank umstellen?
Ja. Der Datenzugriff liegt gebündelt in wenigen Funktionen wie seminare_load() und seminare_save(). Die öffentlichen Seiten und der Adminbereich arbeiten nur mit Arrays. Ein Wechsel auf MySQL würde diese Funktionen ersetzen, nicht die Templates.
Brauchst du eine Lösung, die genau zu deinem Ablauf passt?
Ich entwickle schlanke Web-Anwendungen und Verwaltungsoberflächen ohne unnötige Funktionen oder laufenden Plugin-Ballast.
Individuelle Lösung anfragen