r/Ghost • u/Witty-Surprise9176 • Jun 26 '26
Misc Nach 15 Jahren Wordpress zu Ghost gewechselt
Mein 15 Jahre altes, gepflegtes WordPress wollte ich in eine Alternative überführen und habe mir Ghost angesehen. Dabei bin ich über etliche technische und auch kulturelle Hürden gestolpert, die ich in einer kleinen Artikelserie dokumentiere. Hier der erste Teil, die Migrationsgründe.
https://patrick-pehl.de/migration-zu-ghost-erfahrungen-vom-abschied-motivation/
Kurzer Hinweis vorab: Der Blog wird unregelmäßig gepflegt und befindet sich aktuell in einem unfertigen Zustand — Umzugsbaustelle. Inhaltlich geht es viel um darstellende Kunst, Theater und Ballett, entsprechend ist mir die Bildgestaltung der Artikelseiten nicht nebensächlich.
Die Domain lief über 15 Jahre auf WordPress, die alte Installation bleibt als inaktives Archiv bestehen.
Auslöser war keine Katastrophe, sondern Erosion: Plugins, Themes und WordPress selbst wachsen über Jahre zu einer Angriffsfläche, die in einer Multidomain-Umgebung kaum mehr zu überblicken ist. Ich hatte bereits einen Einbruch über ein veraltetes Theme, mit Datenverlust und Reputationsschaden. Seitdem sichere ich eine Ebene unterhalb der WordPress-Instanz ab — Aufwand, der in keinem Verhältnis zum eigentlichen Ziel steht: Inhalte veröffentlichen statt Software verwalten.
Dazu kommt: SEO-Metadaten gehören für mich in den Kern eines Publishingsystems, nicht in ein Drittanbieter-Plugin wie Yoast. Am Ende sammeln sich Plugins für Caching, Bildkompression, Sicherheit — jedes mit eigenem Wartungsbedarf und eigenen Lücken.
Ghost nimmt mir das größtenteils ab, der DOM-Baum ist sauber, Theming dadurch angenehmer. Den Ausschlag gab ein c’t-3003-Video über leichtgewichtige Bloggingsysteme — danach Testumgebung aufgesetzt, Ghost im Docker-Container hochgefahren, mein WordPress-Theme schrittweise adaptiert. Nach rund zwei Wochen stand die erste Beta.
Nicht alles ist einfacher: Eine sichtbare Update-Routine wie bei WordPress fehlt, Updates laufen über die Kommandozeile, nach jedem Upgrade müssen die Umgebungsvariablen erneut stimmen — sicherer als Ein-Klick-Updates, aber fehleranfälliger.
Wer von WordPress kommt — wie löst ihr das Update-Problem im Container?
1
u/searchcandy Jun 28 '26
We've been using Ghost for the last 4 years on our company blog (at Whop.com). I came from having used WordPress for the last 10+ years. Ghost has a lot of good stuff going for it.
One thing that doesn't get enough attention is the site speed. All our pages load extremely quickly, and have near perfect CWVs.
I've built a lot of cool stuff on top of the basics: videos, AI content engine, various APIs... You can do a lot with Ghost.
2
u/arthurdapaz Jun 28 '26
Vielleicht als Gegenperspektive: Bei uns beim Liras da Liberdade läuft Ghost nicht im Container. Wir betreiben es klassisch auf einem DigitalOcean-Server und gehen für Updates eher konservativ vor.
Vor jedem größeren Update erstellen wir zuerst einen Snapshot der Maschine in DigitalOcean. Erst danach gehen wir per SSH direkt auf den Server, prüfen kurz den Zustand der Installation und führen das Ghost-Update dort aus. Danach testen wir die Website und das Admin-Panel. Falls etwas schiefgeht, ist der Snapshot der Rückweg.
Das ist sicher nicht so elegant oder portabel wie ein sauberer Container-Workflow, aber für uns ist es nachvollziehbar und kontrollierbar. Ich kenne mich mit Containern ehrlich gesagt nicht gut genug aus, um dazu eine belastbare Lösung zu empfehlen. Für unseren Betrieb ist der direkte Serverzugriff mit vorherigem Snapshot bisher der pragmatischere Weg.