Migration von WordPress zu Jamstack

Die große Migration: Die Migration von WordPress zu Jamstack

Wenn Sie im Internet etwas entwickeln, bearbeiten oder schreiben, haben Sie wahrscheinlich schon von WordPress gehört. Zu sagen, dass es sehr produktiv ist, wäre eine Untertreibung.

Jedes Mal, wenn wir über den Marktanteil verschiedener Frameworks sprechen, zaubert jemand eine neue Zahl für WordPress aus dem Hut, ein großartiges Argument von Sarah Drasner als sie darüber schrieb, als Smashing Magazine von WordPress zu Preact/Hugo wechselte zu Beginn dieses Jahres.

Ich habe meine Probleme mit WordPress - Sicherheit/Geschwindigkeit/Bloat/UX - ziemlich öffentlich gemacht. Ich will den WordPress-Entwicklern oder den Leuten, die es pflegen, nichts wegnehmen, aber für eine Organisation wie die unsere - mit Ingenieuren, Autoren und Fachleuten für Benutzererfahrung, die mit anpacken können - fühlte sich das Leben mit einer Plattform, die weithin als klobig und schwerfällig akzeptiert wird, zugunsten eines guten Backends immer ein bisschen kontraintuitiv an.

Ähnlich wie in Sarahs Beitrag werde ich also das Was/Warum/Wie dieser Reise erkunden, seit unserem Treffen in Miami Anfang 2020, bevor die Welt zu, nun ja, COVID zu werden schien.

Warum?

Wir hatten gerade ein Rebranding vor uns, und der Zeitpunkt war für uns perfekt. Warum sollten wir in eine Agentur investieren, um unsere WordPress-Website neu zu gestalten, wenn wir eine neue Website erstellen können, die von Grund auf auf unserer Marke basiert?

Außerdem war unser Prozess der Inhaltserstellung auf drei Plattformen verteilt. Unsere Inhalte wurden in Markdown bearbeitet und geprüft, in WordPress übertragen und in JIRA nachverfolgt.

Wie ich bereits erwähnt habe, waren wir uns der allgemeinen Bedenken hinsichtlich der Geschwindigkeit und Sicherheit von WordPress durchaus bewusst.

Darüber hinaus stellte diese WordPress-Site einen Teil unserer Infrastruktur dar, der fast allen Mitarbeitern unseres Betriebsteams unbekannt war. Vonage arbeitet weiterhin an der Konsolidierung der Infrastruktur der API-Unternehmen, die es in den letzten Jahren übernommen hat, und unsere Wordpress-Plattform war ein unnötiges Überbleibsel dieser Altlasten.

Verlässlichkeit

Unser Entwicklerschulungsteam ist in der Abteilung Developer Relations angesiedelt, die wiederum zur Produktorganisation gehört. Wir sind also keine Vollzeit-Ingenieure, und wir besitzen keine große Infrastruktur.

Netlify ermöglicht es uns, unsere Inhalte zu löschen und zu vergessen. Wir können die Komplexität, Wartung, Sicherheit und Zuverlässigkeit, die WordPress mit sich bringt, hinter uns lassen. Mit Netlify kann unsere Website, solange sie erstellt werden kann, auch bereitgestellt werden.

Arbeitsablauf

Wie bereits erwähnt, war unser Workflow auf drei Plattformen verteilt. Das konnte frustrierend und unzugänglich sein, vor allem für externe Autoren, die keinen Zugang zu unserem Content-Repository hatten, wie z. B. die Teilnehmer an unserem Spotlight-Programm.

Eines der Ziele dieses Projekts war es, einen Weg zu finden, unseren Arbeitsablauf zu vereinfachen und uns so wenig wie möglich zu beeinträchtigen. Mit Netlify CMS konnten wir dies erreichen.

Der von Netlify CMS bereitgestellte Redaktionsworkflow entsprach ziemlich genau unserem bestehenden JIRA-Workflow, was mich auf eine Automatisierung hoffen ließ (oder auf eine weitere Möglichkeit, mich weniger in JIRA einzuloggen). Gleichzeitig entsprach die Git-basierte Speicherung von Netlify CMS auch unserem bestehenden Review-Prozess.

Durch den Einsatz von Netlify CMS konnte ein großer Teil des Prozesses konsolidiert werden.

Die Migration der Inhalte aus WordPress war schließlich die größte Hürde, die wir zu überwinden hatten. Wir hatten die WP REST API zur Verfügung, also habe ich einen API-Anruf nach dem anderen getätigt, um den besten Weg zu finden, unsere Inhalte aus WordPress zu extrahieren. Wir bearbeiteten Inhalte in WordPress als Markdown, also muss es sie auch so speichern? Ich war schon ganz aufgeregt bei dem Gedanken, dass ich einige API-Aufrufe tätigen könnte, um unsere Markdown-Dateien abzurufen und sie als Markdown-Dateien zu speichern.

Aber wurde es als Markdown gespeichert? Aufgrund der Natur von nicht gewarteten, von der Gemeinschaft betriebenen Plugins war nichts so einfach zu lösen.

Unsere in WordPress gespeicherten Beiträge wurden als HTML wiedergegeben. Crayon, das alte und aufgegebene Syntax-Highlighter-Plugin, schien den Code in Tabellen zu speichern, mit Spalten für Zeilennummern und Zeilen für die einzelnen Codezeilen. Die letzte Version von Crayon vor der Abschaffung ging dazu über, den Code in <pre><code> Tags zu speichern, ähnlich wie andere Syntax-Highlighter. Das Ziel des letzten Updates war es, den Umstieg von diesem Plugin zu erleichtern, da es mit Konvertern oder sogar anderen Textmarkern kompatibel sein würde. Aber leider war das Plugin so alt und die Website so ungepflegt, dass es für uns ein unrealistisches Hindernis war, alles zu aktualisieren, um den Inhalt herauszubekommen.

Die unglaubliche Ironie von Crayon besteht darin, dass der Betreiber ebenfalls genug von WordPress hatte und beschloss, seine Website und seinen Schwerpunkt auf Jekyll, eine Jamstack-Plattform, zu verlegen.

Wir haben beschlossen, alle unsere Inhalte manuell zu überprüfen. Wir haben nicht die Tausende von Artikeln des Smashing Magazine, aber wir haben über 500 Inhalte. Ich habe bereits das Rebranding erwähnt. Diese Entscheidung ermöglichte es uns, alle Inhalte zu überarbeiten, um das Branding zu aktualisieren, SDK-Versionen zu aktualisieren, neue Grafiken anzufordern und sie ins Jahr 2020 zu bringen (die armen Dinger).

Aber wie wollen Sie innerhalb weniger Wochen neue Inhalte produzieren UND alle Inhalte überprüfen? Nun, gar nicht. Der Plan wäre, die Überprüfung der Inhalte über einige Monate hinweg durchzuführen.

Der Plan

Mit Hilfe von Rewrite-Regeln würden wir verhindern, dass die Besucher auf die alte Website zugreifen können. Sie würden auf denselben Beitrag auf der neuen Domäneweitergeleitet, wo die Metadaten als Markdown-Dateien importiert würden.

Die alte Website würde auf eine neue "Legacy"-Domäne verschoben und in jedem Beitrag, den wir importieren, mit einem Link versehen.

Auf der neuen Website würde dann ein netter Hinweis erscheinen, der besagt: "Wir migrieren diesen Inhalt noch", und ein Countdown würde die Besucher auf den alten Link umleiten.

Screenshot showing a message that the content hasn't been migrated yet and that the reader will be redirected to the old post

Bei der Migration von Inhalten bearbeiten wir die bereits importierte Markdown-Datei, entfernen den alten Link und fügen die migrierten Inhalte hinzu, wobei wir die Inhalte in der Mitte der Benutzererfahrung einfügen. Ziel ist es, die Auswirkungen auf den Benutzer zu begrenzen und die Belastung des Teams zu verringern, damit alle Inhalte schnell migriert werden können.

Um die Auswirkungen weiter zu begrenzen, haben wir unsere meistgelesenen und neuesten Inhalte für die Migration priorisiert und die meisten von ihnen migriert, bevor wir live gingen.

Rahmenwahlen

Ich hatte in der Vergangenheit bereits einige Erfahrungen mit Jekyll und einem ähnlichen Arbeitsablauf gemacht. Jekyll, richtig konfiguriert, ist blitzschnell zu rendern. Ich schätze, dass es im Vergleich zu anderen Jamstack-Plattformen immer noch an der Spitze liegt, was die Erstellungsgeschwindigkeit angeht. Es fühlte sich richtig an, dort anzufangen, mit etwas, von dem ich wusste, dass es funktioniert.

Ich habe auch mit Nuxt.js experimentiert, weil Vue.js großartig ist und ich ein großer Fan von Jamstack im Allgemeinen bin. Indem ich meine beiden Lieblingsdinge (Vumstack? Jamue?) kombinierte, fand ich Nuxt.js! Vonage hatte auch ein Designsystem namens Volta, das auf Bootstrap basierte, das alle unsere Branding-Richtlinien umsetzte und als Vue.js-Bibliothek verfügbar war.

Also habe ich zwei Proof of Concepts erstellt, eines in Jekyll und eines in Nuxt.js. Obwohl flüssige Vorlagen im Allgemeinen viel einfacher zu handhaben sind, habe ich Nuxt.js dank Volta viel schneller als Prototyp entwickelt. Mit einem Frontend, das bereits gut zu unserem Branding passte, und einem serverseitigen Rendering, das die Seite blitzschnell machte, waren wir von diesem Nuxt.js-Prototyp sehr begeistert. Nach ein paar Wochen des Optimierens und des Einbringens von Feedback hatten wir etwas, das dem heutigen Ergebnis sehr nahe kam.

Nuxt.js war der richtige Weg!

Zwei Wochen nach der Fertigstellung unseres Proof-of-Concept wurde Volta vom Designteam veraltet! Wir ersetzten es durch TailwindCSS, mit dem wir die Design-Parität mit Volta erreichen konnten, aber mit besser vorhersehbaren Haltepunkten und einer größeren Anzahl von Hilfsprogrammen für responsive Sites.

Schlussfolgerung

Das Ergebnis ist für uns einschneidend. Wir werden in der Lage sein, mehr Arten von Inhalten schneller und zuverlässiger bereitzustellen. Wir haben jetzt eine Plattform, die alle unsere unmittelbaren Ziele für 2021 und die Zukunft unterstützt. Außerdem sieht sie AMAZING aus, wenn ich das selbst sagen darf.

Die Migration geht weiter, aber der Tag der Inbetriebnahme verlief ohne Probleme. Wir haben die Mitarbeiter reibungslos auf die neue Plattform umgestellt und bei Bedarf auf die alte Plattform umgeleitet.

Dank der serverseitigen Analyse können wir die Ergebnisse genauer als zuvor verfolgen und haben Zugang zu viel detaillierteren Daten, die uns bei der Festlegung unserer zukünftigen Ziele helfen.

Screenshot of the new learn.vonage.com homepage