知識のアップデートを怠ると世の中から取り残されるんじゃないかと戦々恐々としているmmochiです。
前回は、CloudflareのEmDashを触ってみて、「これ、使えるんじゃね？」と思った話でした。
そして、夏休みの課題（笑）として自社サイトをEmDashで作り始めたんですよねー。
はい。
データを移しただけでは終わりませんでしたorz
まじで。
WXRでWordPressのコンテンツをEmDashに持ってくること自体はできますよ？
でも、
「そのコンテンツをどういう構造で管理するのか」
「どういうデザインで表示するのか」
「コンテンツ同士をどう関連付けるのか」
「どんな処理をするのか」
までは、WXRには入っていません。
ということで、ここからが本当の「検証」です。
まずはデータを持ってくる
まずはWXR。WordPressからコンテンツをエクスポートして、EmDashへインポートします。
記事や制作実績など、これまでWordPressで管理してきたコンテンツをEmDash側へ持っていく。
ここは比較的わかりやすい。
ただし、これで終わりにはならないんですよねー
WXRが持ってきてくれるのは、基本的に「何が入っていたか」というデータです。
「このデータをどういう画面で編集していたか」
「どういうデザインで表示していたか」
「この情報とこの情報をどう関連付けていたか」
といった情報までは持ってないんですよね。
「じゃあ、今のサイトはどうやって再現するんだ？」
WordPressのテーマをそのまま持っていくわけではない
今回の検証では、WordPressのテーマをそのままEmDashへ載せ替える、という方法は取りませんでした。そもそも、WordPressテーマをそのままEmDashで動かすような構成ではないので。
WordPressのテーマをそのまま載せ替えるのではなく、テーマの構造やスタイル、表示ルールを参考にしながら、Astro側で作り直します。
なので、今まで使っていたWordPressテーマを一度バラして考えます！
あんどぷらすのテーマには、
- Dynamic Block
- CSS
- JavaScript
- ページごとのテンプレート
- いろいろな表示ルール
などが入っています。
これらを見ながら、
- 「この表示は新しいサイトではどうする？」
- 「このブロックはどういうコンポーネントになる？」
- 「このJavaScriptはどこで動かす？」
なんてことを考えながら、ひとつずつ新しい構成へ置き換えていきます。
データはEmDash。
見た目と挙動はAstro。
という役割を覚えておきます。
Astroで作り直す
EmDashのフロントエンドはAstroをベースにしています。WordPressのDynamic Blockは、そのままでは動かないのでAstroのコンポーネントとして作り直すことになるんですよね。
例えばWorks。
WordPressではWorks用のカスタム投稿とDynamic Block、それにAJAXなどを組み合わせてフィルタ実装してました。
これを新しい構成では、
- Worksのデータ → EmDash
- Worksの表示 → Astro
- 絞り込み → API
- 画像 → Cloudflare R2
というように分担していきます。
こうして、「CMSの機能」と「Webサイトの表示」を別々に考えるようにすると結構いい。
CSSもJavaScriptも持ってくる
もちろん、フロントを全部ゼロからデザインし直したわけではないですよ。これまで使ってきたCSSもあれば、JavaScriptもあるのでね。
必要なものはAstro側へ移し、新しい構成に合わせて組み直します。
これまで使っていたCSSはテーマの共通スタイルやブロックごとのスタイルを整理しないとAstro側へ移設しても役に立たないかも。
JavaScriptも同じように、新しい構成に合わせて組み直します。
- ヘッダーやサイドバーの動き。
- Worksの絞り込み。
- Cultureのスライダー。
- Servicesのアニメーション。
こういうものですね。
ただ、これも単純にファイルをコピーすれば動くっていうわけじゃないんですよね。
HTMLの構造が変わればJavaScriptも変わるし、データの取り方が変われば処理も変わるので、
「WordPressテーマを移植する」というより「WordPressテーマがやっていたことをAstroで再実装する」
というのが正確なところですねー。
そして、情報の持ち方も変える
ここで、前回の記事で書いたように「情報モデル」を設計するところから。例えばWorksには、
- 作品情報
- クライアント情報
- プラットフォーム
- 担当Member
- 関連するサービス
など、いろいろな情報があります。
WordPressでは、それをACFやtaxonomyなどを組み合わせて持たせていました。
でも、新しい構成では、「ACFのこのフィールドを再現する」ではなく、「Worksにはどんな情報が必要なのか？」から考えます。
Memberとの関係も同じ。
Worksから担当Memberを見たい。
Memberからも、その人が関わったWorksを見たい。
だったら、最初からWorksとMemberは関連する情報モデルとして定義すればいい
WordPressの管理画面で見えていた「フィールド」は、あくまで情報を入力するためのUIなんですよね。
本当に考えたいのは、その裏側にある「情報の関係」なんですよ。
固定ページも、そのままでは持っていかない
固定ページも同じです。WordPressでは、固定ページにACFを追加して、ページごとに必要な情報を持たせていました。
でも、
「Homeの情報」と
「Companyの情報」と
「Servicesの情報」
を、無理に同じ構造で持つ必要はないんですよね。
これも、EmDashの機能に合わせたというより、
「このサイトにはどういう情報が必要なのか」
から考えているからこその情報設計になると思うんですよね。
前回書いた、「CMSに合わせて情報を持たせるのではなく、情報構造を先に考える。」というのは、こういうことなんです。
3,853行のfunctions.phpをどうする？
忘れちゃいけない`functions.php` 3,853行。これ、どうすんのｗ
もちろん、そのまま移植はしないし、できればしたくないｗ
中身を見ていくと、
- SEO
- OGP
- JSON-LD
- 管理画面の処理
- 独自API
- 各種表示処理
- その他いろいろ
と、いろんな処理が共存してるんですよね。
このひとつひとつが本当に「サイトに必要な機能」なのかというと、そうでもないんですよ。
- WordPressだから必要だったもの
- 昔必要だったけど、今は必要ないもの
- 逆に、サイトとして絶対に必要なもの
っていうものが混在しているので、
「functions.phpを移植する」んじゃなくて、「functions.phpの中にある要件を整理する」
っていうことが重要になりますねー。
それをやると、せっかくWordPressを離れるのに、EmDashの上で「WordPressっぽい何か」を作ることになっちゃう。
おすすめしないですからね？
EmDashで足りないところもある
特にコンテンツ同士の関連付けとか、管理画面の使い勝手とか。WordPress + ACFでは簡単にできていたことでも、EmDashではそのままでは実現できないんですよね。なので別の方法を考えたり、必要なところは補ったりが必要です。
場合によっては「これは今のEmDashではちょっと厳しいな」と判断したり。
まだ1.0なので、従来のWordPressと同じ操作感や機能が揃っているわけではないですね。
でも、ここも含めて「検証」なんですよ。
「EmDashにこの機能がないから終わり」ではなく、「そもそも、何を実現したいんだっけ？」
ということをちゃんと考え直してみると、別の方法で解決できることもありますね。
で、だんだん見えてきた
WXRでデータを持ってきて、WordPressのテーマを棚卸しして、
Astroで表示や挙動を作って、
EmDash側の情報構造を考えて、
足りないところを補っていく。
そんなことをやっていると、これは「WordPressをEmDashに置き換える」という話ではないな、と気づくんですよね。
WordPressで作ってきたサイトを、
「データ」と「表示」に分けて、もう一度組み直す。
っていうことが必要になるんですよ。
そして、これをやってみると、昔やっていたことを思い出すんですよね。
そう。
Jamstack。
次回は、以前Gatsby＋WordPressでやっていた経験を振り返りながら、なぜ今回またこの方向に戻ってきたのかを書いてみます。
Jamstack再び。
関連記事
CloudflareのCMS「EmDash」を触ってみた。01WordPressからEmDashへ。3,853行のfunctions.phpをどうしたか。02
Jamstack三度。今回のEmDashは何が違うのか 03
速くて、セキュアで、自由なWebサイトをつくる。EmDash 04
