Case Study: Von WordPress zum eigenen Flat-File-CMS — der Relaunch dieser Seite

Case Study: Von WordPress zum eigenen Flat-File-CMS — der Relaunch dieser Seite

Die Seite, auf der du das hier liest, ist selbst eine Case Study. Mein altes Portfolio lief auf WordPress 5.7 — Theme von der Stange, ein Dutzend Plugins, jQuery, und ein Admin-Bereich, der träger wurde, je länger man ihn ignorierte. Für eine Portfolio-Seite mit einer Handvoll Inhalten war das ein Overkill an beweglichen Teilen. Zeit für einen radikalen Schnitt.

Die Anforderungen

  • Mega-moderner Look mit echten WebGL-Animationen statt Template-Optik
  • Ein eigenes CMS — aber ohne Datenbank, ohne Update-Tretmühle, ohne Plugin-Zoo
  • Muss auf klassischem Shared Hosting (All-Inkl) laufen, also kein Node.js-Server
  • Alle Inhalte und Bilder der alten Seite übernehmen, alte URLs sauber umleiten

Die Architektur: Flat-File statt Datenbank

Die Lösung ist bewusst einfach: PHP 8 als Runtime (läuft auf jedem Shared Hosting), alle Inhalte als JSON-Dateien in einem content/-Ordner, davor ein schlanker Front-Controller mit Routing per .htaccess. Ein Projekt ist eine Datei, ein Blogpost ist eine Datei — ein Backup ist ein Ordner-Download. Kein MySQL, keine Migrationen, kein Build-Schritt: Änderung speichern, fertig.

Das Admin-Panel habe ich komplett selbst geschrieben: Login mit bcrypt und CSRF-Schutz, Projekte mit Drag-&-Drop-Sortierung, Bild-Upload mit serverseitigem Resize, Blog-Editor, Einstellungen. Insgesamt ein paar hundert Zeilen PHP — statt eines CMS, das für Millionen Anwendungsfälle gebaut wurde, von denen ich drei brauche.

Das Frontend: CGI-Feeling im Browser

Der Hero ist eine Three.js-Szene: ein Partikel-Wellenfeld aus über 14.000 Punkten, das per Shader animiert wird und auf Maus und Scroll reagiert. Dazu GSAP mit ScrollTrigger für Reveals und die animierten Skill-Bars, Lenis für Smooth-Scrolling, ein Custom Cursor und Seiten-Übergänge. Wichtig war mir der Fallback: prefers-reduced-motion wird respektiert, und ohne WebGL bleibt die Seite voll nutzbar.

Die Migration: Inhalte retten, SEO erhalten

Die alten Inhalte habe ich über die WordPress-REST-API und die Sitemaps ausgelesen — 13 Portfolio-Projekte, 6 Blog-Artikel und alle Bilder in Originalauflösung. Überraschung dabei: Einige Projekte hatten vertauschte Texte und falsche Kundenzuordnungen, die jahrelang niemandem aufgefallen sind. Die Galerie-Bilder steckten hinter Visual-Composer-Shortcodes und mussten über die Media-API aufgelöst werden.

Für SEO leiten alle alten URLs per 301 auf die neuen Pfade um (/portfolio/* → /projekte/*), Titel und Descriptions sind pro Seite pflegbar, und ein Person-Schema (JSON-LD) ist eingebaut.

Was ich mitnehme

  • Für Portfolios und kleine Sites ist ein Flat-File-Ansatz dem klassischen CMS in fast allem überlegen: schneller, sicherer, wartungsfrei
  • Die WordPress-REST-API ist ein unterschätztes Migrations-Werkzeug — sauberer als jedes HTML-Scraping
  • WebGL + GSAP sind auch auf Shared Hosting kein Problem, weil alles im Browser läuft
  • Alte Inhalte blind übernehmen ist gefährlich: Der Umzug war die perfekte Gelegenheit für ein Content-Audit