サイト移行を支える技術

公開日：2020-06-05

「今年は空梅雨だったかな？」というノリの既に暑い沖縄からこんにちは、西島です。

さて、先日弊社のコーポレートサイトをWebflowに移行しました。今回の移行ではWordPressや散在していたサテライトサイト（ブログはMedium、イベント申し込みはクローバ）もコーポレートサイトにまとめ直すなど、なかなか大掛かりな移設となりました。

その辺りのデザイン的な話は、弊社のくーらがブログに書いてくれているのでそちらに譲るとして、この記事では技術的にどうやったのか、また移設にあたって書いたコードの供養をしたく（一度しか使われないので…）、記事を書きます。

なお、タイトルは釣りであまり技術的なことは出てきません。地味な作業の連続です…。

WebflowのCMS Collection仕様

Webflowの動的コンテンツ（お知らせ、ブログ記事、イベント情報等）はCMSで作成することになります。これはCollection毎にCSVインポートすることが出来ます。公式のドキュメントはこのあたりにあります。

https://university.webflow.com/article/cms-collections

「CSVで移行できるなら簡単でいいじゃん！」

はい、そう思いますよね？ 自分もそう思っていたのですが、早々に野望は打ち砕かれました。幾つか注意する点は以下です。

• CSVの方言としては、行中に改行が含まれてはいけないスタイルなので注意（特にWordPressからの移行時）
• Collection fieldsのうち、CSVでセットできないものがあることに注意（特にReference…）
• 画像フィールドもCSVでセットは出来ないので注意（リッチテキスト内の画像URLは自動的にダウンロードされます。これは便利）
• CSVでアップロードすると、日付が全て同じになってしまうので、別途自分でセットする日付フィールドがあったほうが良い

結構ハマりどころが多そうですね。気を取り直して、移設作業を進めることにします。

WordPressからの移設

以前のコーポレートサイトはWordPressのStatic Site GeneratorであるShifterを利用していました。ShifterはWordPressと全く同じように使えるので、WordPress用のCSVエクスポートプラグインを利用して、各記事をCSVにエクスポートします。

その後、エクスポートした各CSVファイルを、Webflow向けの方言にあうように調整します。

プラグインによると思うのですが、出力直後のCSVは記事部分に改行が含まれていたりして、そのままではWebflowにインポートすることは出来ません。Libreofficeなどで開いて、記事部分の改行を置換して削除しておきます。

また、記事中の画像src指定も要注意です。おそらく殆どのCSVファイルが以下のようなルートからの相対パスで書かれていると思います。

<img src=”/wp-content/uploads/filename.jpg”>

これをWebflowのリッチテキストフィールドに読み込ませても、Webflow側でダウンロードできないので上手く行きません。

今回は、assets.r3it.comというホスト名を新たに用意して、この配下に画像ファイルを全て置いた上で、imgタグのURLを以下のように書き換えました。

<img src=”https://assets.r3it.com/wp-content/uploads/filename.jpg”>

このHTMLが書かれたCSVをインポートすると、めでたくリッチテキストフィールドに画像も自動的に入ってくれます。

この作業を「お客様事例」「コラム」「お知らせ」などなど、コンテンツごとに繰り返しました。地道だ…。

Mediumからの移行

コーポレートサイトの移設に目処が付いたら、次はブログサイトの移設です。以前のブログサイトはMediumの独自ドメインを使っていました。この独自ドメインというのも、あとで面倒になる作業の1つでしたが、、、今はひとまず記事を移設することに注力します。

Mediumで作成した記事は、このURL https://medium.com/me/settings にある「Download your information」からダウンロード可能です。ただ、これは全てのデータが含まれたHTMLになっています。

さて、これらHTMLファイル群をどうやって、インポートできるCSVファイルにするかが問題です。

まずダウンロードしたHTMLファイルを確認してみると、独自のCSSクラス指定などがたっぷり張り付いている感じで、このままリッチテキストに貼り付けても上手く行きそうにありません…。考えた結果、以下のような方法でやってみることにしました。

• まず各HTMLファイルをmarkdownファイルに変換する
• markdownファイルを読み込み、HTMLに変換しつつCSVファイルを作成する

markdownをHTMLにする時に、独自にコンテンツに変換もかけられるし、この方法は案外上手くできそうです。

MediumのHTMLをmarkdownファイルに変換する方法

まず1ステップ目の、HTMLからmarkdownファイルを作成する部分です。自分で作成しても良かったのですが、少し探したところGitHubにツールを公開されている方がいらっしゃったので、これを利用させてもらいました。

https://github.com/gautamdhameja/medium-2-md

このツールは画像ファイルのダウンロード機能もありますが、これは使いません。Mediumで作成した記事中にある画像のURLは、ホスト名を含むURLで書かれていますので、これはそのまま利用可能です。

markdownファイルからCSVファイルを作成

次にこのツールを使って変換した.mdファイルを読み込んで、CSVファイルを生成する簡単なプログラムを作成しました。弊社固有の処理なども入っているのでそのまま流用は出来ないと思いますので、参考程度にしてください。

詳細はコードを見ていただけば分かるのですが、以下のような処理をしています。 ちなみに、markdownのパーサーにはgoldmarkを使用しています。

• 元記事の情報からslug、作者名を取得して生成
• markdownのhタグ変換
• 自サイト https://blog.r3it.com 内リンクの自動書き換え

これで HTMLファイル → markdownファイル → Webflow向けのCSVファイルという長い旅が終わりました。

CSV読み込み後、微調整

作成したCSVファイルをWebflowにインポートし、細かい部分を調整します。ひとこと「微調整」と書きましたが、ReferenceのCollection fieldsがCSVで編集できない部分は、一覧画面からまとめても編集できないですし、なかなか地獄です。

Wishlistには上がってるので、皆さんサインアップしてVote!Vote!

これで記事自体の移行は終わりましたので、作業完了です！

と言いたいところでしたが、まだもう少し続きがあるのです…。

そう、旧サテライトサイトへのアクセスをどうするか、という問題です。

Amazon CloudFront と API Gateway を利用したサイトのリダイレクト

やりたいことは以下のとおりです。

• httpおよびhttps://blog.r3it.com へのアクセスは https://www.r3it.com/blog へリダイレクト
• blog記事への直接リンクは、出来る限り /blog/のURLにリダイレクトする（間違ってたらごめんレベル）

またその後、別の同僚からSlackでこんな雑な要望が来てもめげません。

設定のニュアンスとしては↓みたいなかんじ(ふいんき

RewriteEngine on
RewriteCond %{HTTP_HOST} ^seminar.r3it.com$
RewriteRule ^(.*)$ https://www.r3it.com/seminarevent/ [R=301,L]

nginxが1台あれば簡単に実現できそうな話ですが、今回はAWSのマネージドなサービスを使って実現してみます。具体的には以下のような手順です。

リダイレクト用のLambda関数とREST APIを作成

こんな感じの簡単なLambda関数です。

AWS SAM CLIを使うとLambda関数やAPI Gatewayの定義など諸々をまとめてさくっと書けます。ローカルでの実行・テストもdockerで出来たりと、とても便利ですので未体験の方はぜひお試しください。

これで作成したAPIに対して、以下を設定します。

その1. カスタムドメイン名を設定

ここで付けた名前（例えば blog-redirect.r3it.com）が、最終的にLambdaで受け取ったときのHostヘッダーに乗ってきます。

1点注意点としては、APIマッピングでステージ「Prod」パス「なし(none)」を追加するのをお忘れ無く。

その2. Route53で blog-redirect.r3it.com -> カスタムドメインの詳細にある「API Gateway ドメイン名」にAレコードでエイリアスを作成

これはまあ、まんまです。この名前も登録しておかないと、そもそもカスタムドメイン名でAPIGWが応答してくれません。

その3. httpでのアクセスを受け付けるために、この前段にCloudFrontを設置する。

ここが面倒なところです。API Gatewayはhttpsでしか通信できませんので、httpも処理したいとなると、前段にCloudFrontを設置する必要があります。作成の際に忘れずに http -> https のリダイレクトを設定します。

その4. このCloudFrontに対して、リダイレクトしたいホスト名からAレコードでエイリアスを作成。

この場合、「blog.r3it.com」のAレコードのエイリアスとして、今設定したCloudFrontをセットします。

この一式の設定を、サテライトサイトごとに設定します（めんどくさい…）。 ただ、APIは一つで大丈夫です。というか大丈夫になるように、Hostヘッダを見て動作を切り替えています。

サイト公開＆リンク切れチェック

様々な作業の後、無事（？）移行後のサイトが公開されたあとで、念の為リンク切れチェックをかけて自動で自サイト内リンクを書き換えた部分などを確認しました。幾つか問題がありましたが、さくっと修正してもらい、大きな問題は特に無さそうでした（リダイレクトのバグがあって、一晩動作がおかしかったのは内緒です:)。

まとめ

以上が今回のサイト移行の技術的な裏側でした。 全然スマートではありませんでしたが、泥臭く細々と頑張れば、意外にちゃんと移行できるということがよく分かりました。次のプラットフォームが来ても怖くないぞ！（えw

ということで、皆さんのサイト移行時の考え方や対応策のヒントにでもなれば幸いです。

‍