Entwickler Journal ist eine Fachplattform für Softwareentwicklung, Architektur, DevOps, Security und moderne Entwicklerwerkzeuge. Die frühere Website lief auf WordPress; heute trägt sie eine eigene, serverseitig gerenderte PHP-Anwendung auf Basis von Markdown.
Ausgangslage
Die WordPress-Website erfüllte ihren ursprünglichen Zweck. Mit dem Ausbau der Plattform wuchsen jedoch die Anforderungen an das Content-Modell: Fachartikel, Serien, Projekte, Übersetzungen, Kategorien, Medien mit nachvollziehbarer Herkunft sowie SEO- und Discovery-Metadaten sollten sauber strukturiert und miteinander verbunden werden.
Gleichzeitig sollte die Plattform schlank bleiben – ohne klassische CMS-Datenbank und ohne umfangreiche Plugin-Abhängigkeiten.
Die Frage war deshalb nicht, wie sich WordPress weiter anpassen ließe, sondern welche Architektur für die geplante Plattform langfristig die geeignetere ist.
Ziel
Die neue Lösung sollte mehrere Anforderungen verbinden:
- serverseitiges Rendering
- strukturierte und versionierbare Inhalte
- deutsch- und englischsprachige Veröffentlichungen
- klare Trennung zwischen Anwendung und Content
- technische SEO als Bestandteil der Architektur
- Erweiterbarkeit für neue Content-Typen
- nachvollziehbare Medienherkunft
- geringer technischer Overhead und gute Wartbarkeit
Dabei sollte keine allgemeine CMS-Plattform nachgebaut werden. Die Architektur sollte genau die Funktionen enthalten, die Entwickler Journal tatsächlich braucht.
Architekturentscheidung
Die Plattform wurde als individuelle PHP-Anwendung aufgebaut. Die Inhalte liegen nicht in einer CMS-Datenbank, sondern als Markdown-Dokumente mit strukturiertem YAML-Front-Matter. Redaktionelle Inhalte und Quellcode lassen sich dadurch gemeinsam versionieren, validieren und ausliefern.
Die Anwendung übernimmt Routing, Content-Auflösung, Rendering, Übersetzungsbeziehungen, Medienverwaltung, SEO-Metadaten, Sitemap und Feeds, strukturierte Daten sowie Navigation und interne Beziehungen.
Das Frontend wird serverseitig ausgeliefert. JavaScript ergänzt nur dort Funktionen, wo tatsächlich clientseitige Interaktion nötig ist.
Publishing- und Content-Modell
Die Architektur orientiert sich nicht an Seiten im klassischen CMS-Sinn, sondern an strukturierten Inhaltstypen. Fachartikel, Serien und Projekte besitzen definierte Metadaten und lassen sich dadurch gezielt auswerten und miteinander verbinden.
Markdown trägt den redaktionellen Inhalt. Das Front Matter beschreibt Titel, Veröffentlichungsdatum, Sprache, Kategorien, Übersetzungsbeziehungen und Medien. So bleibt das Content-Modell für die redaktionelle Arbeit ebenso nachvollziehbar wie für die Anwendung.
Serien sind dabei ein eigener Inhaltstyp und keine gefilterte Blogliste: Zusammengehörige Beiträge werden als Sammlung geführt, mit eigener Übersicht und eigener Reihenfolge.
Mehrsprachigkeit als Teil des Content-Modells
Deutsch und Englisch sind keine voneinander unabhängigen Kopien. Zusammengehörige Inhalte werden über gemeinsame Übersetzungskennungen verbunden.
Die Anwendung erkennt dadurch vorhandene Übersetzungen, verlinkt den Sprachumschalter auf das tatsächliche Gegenstück, erzeugt hreflang-Beziehungen und sprachspezifische Sitemap-Einträge – und behandelt fehlende Übersetzungen bewusst, statt sie zu verschweigen.
Die englische Fassung ist damit Bestandteil derselben Publishing-Architektur und keine nachträglich angehängte Parallelwebsite.
SEO und Discovery
Technische SEO wurde nicht nachträglich ergänzt, sondern in die Architektur integriert: Canonical URLs, hreflang, Open Graph, X Cards, strukturierte Daten, Breadcrumbs, Sitemap-Index und sprachspezifische Sitemaps, RSS-Feeds, semantisches HTML und echte 404-Seiten.
Die Metadaten entstehen aus demselben Content-Modell wie die sichtbaren Inhalte. Redaktionelle Informationen werden dadurch nicht an mehreren Stellen unabhängig voneinander gepflegt.
Medien mit nachvollziehbarer Herkunft
Für redaktionelle Medien wird nicht nur die Datei gespeichert. Das System unterscheidet zusätzlich zwischen Originalmaterial, KI-generierten und KI-modifizierten Medien.
Diese Herkunft lässt sich je nach Inhalt sichtbar machen oder technisch auswerten. Sie wird damit zum Bestandteil des Publishing-Modells und nicht zu einer nachträglichen Anmerkung.
Qualitätssicherung
Die Architektur wird automatisiert geprüft. Tests und Validatoren kontrollieren Content-Strukturen, Routing, Übersetzungsbeziehungen, interne Links, SEO-Metadaten, Sitemaps, Feeds, Medienreferenzen sowie Templates und Rendering.
Inhalte und Anwendung werden dadurch gemeinsam abgesichert – ein fehlerhafter Verweis fällt beim Build auf und nicht erst im Betrieb.
Ergebnis
Aus einer klassischen WordPress-Website entstand eine eigenständige Publishing-Plattform, deren Architektur auf die konkreten Anforderungen von Entwickler Journal zugeschnitten ist. Sie verbindet Publishing, Mehrsprachigkeit, SEO, Medien, Projekte, Serien und technische Inhalte in einem gemeinsamen System.
Das Projekt zeigt zugleich einen Grundsatz der Webentwicklung bei EicDevCon: Eine bestehende Plattform wird nicht ersetzt, nur weil eine Individualentwicklung technisch möglich wäre. Eine eigene Lösung lohnt sich dann, wenn sie für Anforderungen, Betrieb und Weiterentwicklung einen nachvollziehbaren Vorteil bietet.
Technischer Überblick
Backend – PHP, eigenes Routing, Content Repository, Translation Repository Content – Markdown, YAML-Front-Matter, strukturierte Inhaltstypen Frontend – serverseitiges Rendering, HTML, CSS, Vanilla JavaScript Publishing – Artikel, Serien, Projekte, Kategorien, Übersetzungen Discovery – Canonical, hreflang, JSON-LD, Sitemap, RSS, Open Graph Qualität – Content-Validierung, automatisierte Tests, responsive Prüfung
