WordPressからJamstackへの移行

グレート・マイグレーションWordPressからJamstackへの移行

インターネット上で開発、編集、執筆をする人なら、WordPressの名前を聞いたことがあるだろう。WordPressは多機能である。

さまざまなフレームワークの市場シェアについて話すたびに、誰かがWordPressの新しい数字を魔法で作り出す。 サラ・ドラスナーによる素晴らしい指摘だ。 スマッシング・マガジンがWordPressからPreact/Hugoに移行したときのことを書いている。今年の初めにスマッシング・マガジンがWordPressからPreact/Hugoに移行したときのことを書いている。

私はこれまで、WordPressのセキュリティ、スピード、ブロート、UXに関する問題を公にしてきた。WordPressの開発者や、それをメンテナンスしている人たちから何かを奪うわけではありませんが、私たちのような組織には、エンジニア、ライター、ユーザーエクスペリエンスの専門家がいます。

だから、サラの投稿と同じように、2020年の初め、世界がその、COVIDに向かうと思われる前に、マイアミで会ったあの時から、この旅の何／なぜ／どうしてを探ってみようと思う。

なぜですか？

私たちはリブランディングを進めており、そのタイミングは完璧でした。私たちのブランドに基づいて一から新しいサイトを制作できるのに、なぜWordPressサイトのリブランディングのために代理店に投資したのでしょうか？

また、コンテンツ作成プロセスを3つのプラットフォームに分割していました。コンテンツはMarkdownで編集・レビューされ、WordPressに移行され、JIRAでトラッキングされました。

前述したように、私たちはWordPressのスピードとセキュリティに対する一般的な懸念をよく知っていました。

その上、このWordPressサイトは、ほとんどすべてのオペレーション・チームにとって未知のインフラの一部でした。Vonageは近年買収したAPIビジネスのインフラを統合する作業を続けており、Wordpressプラットフォームはそのレガシーの不要な名残だったのです。

信頼性

私たちのデベロッパー教育チームは、デベロッパー・リレーションズの中にあり、それ自体は製品組織の中にあります。ですから、私たちはフルタイムのエンジニアに集中しているわけではありませんし、大量のインフラを所有しているわけでもありません。

Netlifyのおかげで、私たちはコンテンツを燃やして忘れることができます。WordPressがもたらす複雑さ、メンテナンス、セキュリティ、信頼性の心配を取り除くことができます。Netlifyでは、サイトが構築できる限り、デプロイすることができます。

ワークフロー

すでに述べたように、私たちはワークフローを3つのプラットフォームに分割していました。特に、私たちのコンテンツ・リポジトリにアクセスできない外部のライター、例えば私たちの スポットライト・プログラム.

このプロジェクトの目標のひとつは、ワークフローを簡素化する方法を見つけることでした。Netlify CMSはそれを可能にしてくれました。

Netlify CMSが提供する編集ワークフローは、私たちの既存のJIRAワークフローをかなり忠実に反映しており、自動化(あるいは、JIRAにログインする機会を減らす)への期待を抱かせてくれました。同時に、Netlify CMSのgitベースのストレージも、私たちの既存のレビュープロセスを反映していました。

Netlify CMSを使うことで、プロセスのかなりの部分を統合することができました。

WordPressからのコンテンツの移行は、結局のところ、私たちが直面する最も重要なハードルでした。WP REST APIが利用できたので、私はAPIコールに次ぐAPIコールで、WordPressからコンテンツを抽出する最良の方法を特定しようとした。WordPressで編集したコンテンツはMarkdownとして保存されているはずだ。APIコールを使ってMarkdownを取得し、Markdownファイルとして保存することができると思うと、ワクワクしてきた。

しかし、それはMarkdownとして保存されていたのだろうか？メンテナンスされていないコミュニティ主導のプラグインの性質上、結局のところ、そんなに簡単なものはなかった。

WordPressの保存記事はHTMLとしてレンダリングされる。シンタックスハイライタープラグインのCrayonは、行番号の列とコード行ごとの行を持つテーブルでコードを管理していた。非推奨になる前のCrayonの最後のバージョンでは、コードを他のシンタックス・ハイライターと同じように <pre><code>タグにコードを保存するようになった。最後のアップデートの目的は、コンバーターや他のハイライターとも互換性があるので、そこから移行することをより管理しやすくすることだった。しかし悲しいことに、プラグインはとても古く、サイトもひどくメンテナンスされていなかったため、コンテンツを出すためにすべてを更新するという非現実的な障害に直面していた。

Crayonの驚くべき皮肉は、管理者もWordPressに飽き足らず、JamstackのプラットフォームであるJekyllにサイトとフォーカスを移すことを決めたことだ。

私たちは、すべてのコンテンツを手作業で見直すことにしました。スマッシング・マガジンのような何千もの記事はありませんが、500以上のコンテンツがあります。先ほどリブランディングの話をしました。この決定により、ブランディングを更新し、SDKのバージョンを更新し、新しいアートワークを要求し、2020年にそれらをもたらすために、すべてのコンテンツを見直すことができました（かわいそうに）。

しかし、数週間のうちに新しいコンテンツを制作し、すべてのコンテンツを見直すにはどうしたらいいでしょうか？それは無理だ。コンテンツの見直しは、数カ月かけて行うものだ。

プラン

リライトルールを使って、人々が古いサイトにアクセスできないようにする。新しいドメインの同じ投稿にリダイレクトさせるのだ。 新しいドメインメタデータはマークダウン・ファイルとしてインポートされる。

旧サイトは新しい "レガシー "ドメインに移され、インポートする各記事にはそこへのリンクが貼られる。

新しいサイトでは、"このコンテンツはまだ移行中です "という趣旨の素敵な注意書きが表示され、カウントダウンとともにレガシーリンクにリダイレクトされる。

コンテンツを移行する際には、すでにインポートしたマークダウン・ファイルを編集し、レガシーリンクを削除して移行したコンテンツを追加し、ユーザー・エクスペリエンスの真ん中にコンテンツを配置します。目標は、ユーザーへの影響を最小限に抑え、すべてのコンテンツを迅速に移行するチームの負担を減らすことです。

さらに影響を抑えるため、最もよく読まれている最新のコンテンツを優先的に移行し、本番稼動前にそのほとんどを移行した。

フレームワークの選択

私は過去にJekyllと同様のワークフローで作業するいくつかの経験を持っていた。Jekyllは、正しく構成され、レンダリングすることは非常に高速です。他のJamstackプラットフォームと比較しても、ビルド速度はトップクラスだと思う。私が動作することを知っている何かで、そこから始めることは正しいと感じました。

Vue.jsは素晴らしいし、私はJamstackの大ファンだからだ。私の好きな2つのもの（Vumstack？ Jamue？）を組み合わせて、私はNuxt.jsを見つけた！Vonageには、BootstrapをベースにしたVoltaというデザインシステムもあり、これは私たちのブランディング・ガイドラインをすべて適用し、Vue.jsライブラリとして利用可能でした。

そこで、JekyllとNuxt.jsの2つの概念実証を作った。一般的にはリキッドテンプレートの方がずっと作業がしやすかったにもかかわらず、私はVoltaのおかげでNuxt.jsの方がはるかに素早くプロトタイプを作成できることに気づきました。私たちのブランディングとサーバーサイド・レンダリングによって、すでに素晴らしいフロントエンドが完成していたので、このNuxt.jsのプロトタイプにとても興奮しました。数週間にわたる微調整とフィードバックの適用を経て、現在の形に近いものができました。

Nuxt.jsがその方法だった！

コンセプト実証が終わった2週間後、Voltaはデザインチームによって廃止されました！私たちはTailwindCSSを使用し、Voltaと同等のデザインを実現しましたが、より予測可能なブレークポイントや、レスポンシブ・サイト用のユーティリティの数を増やすことができました。

結論

その結果、私たちにとって大きな変革がもたらされました。より多くの種類のコンテンツを、より速く、より確実に配信できるようになる。私たちは今、2021年および将来の当面の目標をすべてサポートするプラットフォームを手にしています。自分で言うのもなんだが、見た目も素晴らしい。

移行は続いているが、本番の日は何の問題もなかった。必要であればレガシーへのリダイレクトも行いながら、スムーズに新プラットフォームへ移行することができた。

サーバーサイドのアナリティクスのおかげで、以前よりも正確なトラッキングができるようになり、より詳細なデータにアクセスできるようになった。