僕が考える 「HTML サイトを WordPress にする」話 / 2023-11-05 Kansai WordPress Meetup

Kansai WordPress Meetup@大阪『 WordCamp Tokyo 2023 をみんなで振り返る+α (https://www.meetup.com/ja-JP/kansai-wordpress-meetup/events/296857054/) 登壇資料です。

Transcript

1. 僕が考える 「HTML サイトを WordPress にする」話 Toro_Unit / 2023.11.05 @ Kansai WordPress Meetup 1
2. $ whoami Toro_Unit / 占部 紘 Frontend & WordPress Engineer Github: @torounit Twitter: @Toro_Unit 2
3. Contributions WordPress / Gutenberg Team Shinshu WordPress Meetup WordCamp Tokyo 2023 Speaker WordCamp Kansai 2024 Organizer Team 3
4. 長野県松本市からきました Shinshu WordPress Meetup 毎回ピザ食ってます。 11/18 @松本 Wikimedia Commons/File:File:130608_Matsumoto_Ca stle_Matsumoto_Nagano_pref_Japan02bs4 .jpg Author:663highland.License:CC2.5 4
5. Q: WordPress テーマの開発フローってどうしてます？ 5
6. HTML を作ってから WordPress テーマにする? いきなり WordPress テーマを作る? 6
7. WordCamp Tokyo 2015 での懇親会での一幕 登場人物 キタジマタカシ: Snow Monkey 等のテーマ作者。この頃は Snow Monkey を作 っていない、受託案件をいかに効率良くするか？ということでテーマ開発をし ていたり色々模索してたころ。 ハムさん (´ ºムº `): 札幌で、主に HTML/CSS をやったり、WordPress とか MT とかいろんな CMS でのサイト実装をしていたり。 7
8. (´ ºムº `):HTML / CSS / JS を完成させる -> WordPress に組み込む！ 自分、キタジマ:「HTMLから作るのマジで無駄じゃないですか？」 (´ ºムº `): !!!!!???????? なんかめちゃくちゃびっくりされた。 8
9. そして、WordCamp Tokyo 2016 で 「デザイナーが効率よくテーマ作成を進めるに は？ デザインから WordPress のテーマ作成のワークフローを見直す」というセッシ ョンやってました。 https://speakerdeck.com/h2ham/dezainagaxiao-lu-yokutemazuo-cheng-wojin- meruniha-dezainkara-wordpress-falsetemazuo-cheng-falsewakuhurowojian-zhi- su 9
10. 自分の感想 手戻りめちゃくちゃ多くね ????? それだと WordPress の HTML とかに合わせるの辛くね????? エディタースタイルどうするんだ????? まぁまぁそうはいっても色んな事情あるしなー。 WordPress 開発する前に HTML でプレビューしたいとかあるらしいし。 案件次第、チームのスキル次第かねぇ。 とは言っても俺は _s とかそういうのベースに作り続けるけど。。。。 10
11. 当時の結論 「まぁ一長一短よねー。」 という無難な結論 11
12. なんやかんやあって (´ ºムº `) と一緒に仕事したり会社に入ったり。 12
13. やっぱり効率わるくね????? 時代はブロックエディタ登場前 13
14. 結局 テーマ開発のレールは未整備、みんな好き勝手やってる。 でもなんかデフォルトテーマを見てるとお作法とかはありそう。 alignleft / aligncenter / alignright だけしてればいいわけじゃ無い。ちゃんと WYSIWYG に対応させるの無理。任意の class を付ける方法は、TinyMCE のカ スタマイズ。 div タグは書けるけどビジュアルエディタモードでは存在が見えない。 14
15. っていうか WordPress に合わせて、HTML/CSSだけを書くのは少なくとも俺には無 理。 テストしながらやらないと無理。 Theme Unit Test Data を最初にインポートしての作業しないと結局バグる。 15
16. WordPressではHTMLをコントロールするのは結局難しい the_category など、よく出てくる テンプレートタグは、HTML をまとめて吐き 出すが、既に存在する HTML に合わせるのが難しいので使用できない。 get_terms 等で独自実装。 ナビゲーションメニュー、ウィジェットなど、WordPress 側が吐き出す HTML を改変するコストが高い or 不可能なため、カスタムフィールド等で謎の機能が 増える。 WordPress の機能を使い倒そうとすればするほどこの問題が重い。 その結果、カスタムフィールドでの対処が増える。 16
17. ブロックエディターの登場でさらにこの流れは加速。 そのHTML用のブロックを作る技術、コスト。 沢山のブロックがあってもそれはユーザーが使いこなせるの？ メンテナンス出来る？アップデートで壊れない？ カスタムフィールドで対処したらブロックエディタの恩恵は受けられない。 17
18. WordPress テーマ の機能は、「サイトの見た目を変更する」 作りがかなり緩いので、なんでも書けるけどそれを制約する仕組みが無い。な のでなんでもできるけど、なんでもしていいわけでは無い。 「HTML先に作ってからそれを WordPress に合わせて直していく」 のは、 「とりあえず素敵な服自由に服を作ってから、それを着る人に合わせて直す」 のような話に自分には思える。 18
19. ちゃんと WordPress を使い倒そうと思ったら、デフォルトテー マ、公式ディレクトリに掲載されてるテーマと同じ機能が必要。 それらと同じように開発するのが一番良い。 19
20. 現在の開発フロー 1. 初期状態の WordPress を用意 2. _s をコピー / create block theme で empty テーマを作成 3. Theme Unit Test Data を import 4. CSSとブロックスタイルの追加 / ブロックの開発 / theme.json の設定など 5. 固定ページなどでコンテンツを作成 20
21. というのが僕の結論です。 が、世の中そうでも無いらしい。 https://x.com/hookwp_/status/170 1117360701354111?s=20 21
22. 本題： HTML サイトを WordPress にする 22
23. 「HTML サイトを WordPress にする」ってどういうこと？ なんとなくわかるけど、具体的にどういうことだろう。 WordPress テーマ の機能とは、「WordPress サイトの見た目を変更する」 つまり、「HTML サイトを WordPress にする」 ということは「WordPress テーマ をつくること」とは違う。 「静的サイトを WordPress を用いて、ユーザーが記事を追加したり更新で きるようにする」 ということとここでは定義する。 23
24. 「静的サイトを WordPress を用いて、ユーザーが記事を追加したり更新で きるようにする」 「WordPress でサイトを作ること」では無く、 「静的サイトに WordPress の 機能を後付けしたい」 ということだ僕は考える。 思考、設計の主体はあくまでも HTML/CSS で作ったサイト。 静的サイトを作り、それを WordPress に適用するというのは、そういうワーク フローになっている。 24
25. じゃぁそういう設計を考えてみよう。 メンタルモデル、本当にやりたいことに実装を合わせるのは重要。 そうしないと、矛盾が発生して色々破綻する。 ワークフローと設計は密接に関係する。 というか設計があって、それを実現する工程がワークフロー。 25
26. 問題点 WordPress は静的な HTML と混在させて使うことを想定して作られていない。 WordPress の "サイト URL" 配下のコンテンツは、WordPress が管理。 特定のディレクトリだけ WordPress にするとかも不可能では無いが、共通部分 の管理、js の管理の方法等の違い等でソースコードの共通化は困難。 解決策 WordPress から API でデータを引っ張ってきてそれを表示する。そもそもAPIは外部 のサービス、システムと連携させるためのもの。 26
27. 具体的な実装 HTML サイトを 静的サイトジェネレーター(SSG)作成し、WordPress と連携さ せる HTML サイトを作ってからそれに後付けするので、何らかの方法で CMS で追 加された記事を生成する必要がある。 別に SSG じゃなくても良いけど、現代の技術だと一番お手軽。 WordPress から API で記事を取得して、SSGで HTML を生成。 他の方法としては、アプリケーションフレームワークを用いたりとかだけど実 装コスト高い。 27
28. Astro 2022年リリース。現在再注目のフレームワ ーク。 React とかを使わずに普通の HTML っぽい 構文で作れる React とか Vue とかを部分的に混ぜて使っ たりも出来る 28
29. npm create astro@latest コマンド一発でプロジェクト作成出 来る。 29
30. 既存の HTML を Astro に移植する 最初から Astro で作った方が本当は快適ですし効率も良いしパーツの使い回しもしや すいしパフォーマンスも良いです。 1. HTML ファイルは、src/pages に放り込む。中身は特に弄らない。 2. 拡張子を .astro に変更する。 for filename in *.html; do mv $filename ${filename%.html}.astro; done 3. 画像、CSS、JS 等は、public ディレクトリにつっこむ。 4. <script src="....> 、 <script is:inline src="....> に変更する。 30
31. Astro に WordPress で作成した記事を表示させる オフィシャルのドキュメント https://docs.astro.build/ja/guides/cms/wordpress/ WP-API で記事を取得して、それを Astro で埋め込む格好。基本的に記事は最大100 件しか取得出来ないので、全件取得などは工夫しないといけない。 31
32. WP-API で記事を取得して、一覧を表示 index.astro --- const res = await fetch("https://[wp-url]/wp-json/wp/v2/posts?_embed") const posts = await res.json(); --- <div> { posts.map((post) => ( <article> <a href={`/posts/${post.slug}/`}> <h2 set:html={post.title.rendered} /> </a> <Fragment set:html={post.excerpt.rendered} /> </article> )) } </div> 32
33. WP-API で記事を取得して、個別記事を生成 posts/[slug].astro --- const { slug } = Astro.params; const res = await fetch(`https://[wp-url]/wp-json/wp/v2/posts?slug=${slug}&_embed`) const [post] = await res.json(); export async function getStaticPaths() { const data = await fetch("https://[wp-url]/news/wp-json/wp/v2/posts?_embed") const posts = await data.json(); return posts.map(({slug}) => ({ params: { slug }, })); } --- <article> <h2 set:html={post.title.rendered} /> <Fragment set:html={post.content.rendered} /> </article> 33
34. HTML に WordPress に後付けできた。 WordPress が記事閲覧時に動作しないので、動的な処理は出来ない。フォーム等 は、form.run / Formspree / SSGForm / Google Form 等の外部サービスを利用したり するのが簡単。 WordPress の一部の機能だけを使いたい、ということであればこれはこれで1つの方 法。 34
35. DEMO https://github.com/torounit/astro-wp-demo 35
36. デプロイしてみる ここでは、Cloudflare Pages にデプロイしてみる。 1. Github に レポジトリを作ってそこに Push 2. Cloudflare Pages で レポジトリを選択 3. ビルドコマンドの設定。プリセットで Astro を選べばやってくれる。自前で設 定するなら、 npm run build をビルドコマンドに設定して、生成されるディ レクトリをデプロイディレクトリに指定すればOK。 36
38. デプロイ完了！ https://torounit-astro-wp- demo.pages.dev/ https://astro-wp-demo.netlify.app/ ドメインとか設定すれば、そのまま 仕事とかでも使える。 Netlify / Vercel / Amplify とかでもだ いたい同じ。 38
39. デプロイ方法、記事の更新方法 Cloudflare Pages / Vercel / Netlify などの Jamstack のホスティングを利用。 Github Actions を用いてレンタルサーバーにデプロイしても良い。 WordPress の 記事更新時に Webhook を叩いて更新。 WordPress.com の無料ホスティングも利用できる。 39
40. この方法のメリット ほぼ落ちないサイトがローコストに作れる。WordPress が落ちてもサイトは落 ちないし、WordPress 側にアクセスがないので、強力なサーバーが必要ない。 （画像などは WordPress 側のホストから読まれる） CMS は違うかもだけど、「しいたけ占い公式サイト」でも採用されている。 「しいたけ占い公式サイト」を支える技術: https://hori- ryota.com/blog/shiitakeuranai-dev/ 40
41. デメリット WordPress の設計に合わせてるわけではないので、WordPress の機能を使い倒 すことは出来ない。 記事のプレビューなど、別途その機能を作る必要があったり、あきらめた りする必要がある。 これ大真面目にやると、WordPress で作るよりコストがかかる場合も。 ただし、WordPress で作るよりも、サイトのパフォーマンスは良い。 41
42. おわりに まぁこんな方法もあるよ。 自分がつくろうとしているモノをちゃんと理解すること、そしてそれに合致し た設計・技術選定・ワークフローになっているのか？という問いにちゃんと向 き合わないと色々歪む。 HTML を書けない人のために CMS を導入してるのに、HTML を記述させ たりとか。 ページを追加するのに、テーマファイルを編集する必要があるとか。 42
43. 何のために CMS 導入するの？ 「WordPressを導入する」が目的化していませんか？ 変更とかをいちいち依頼してもらう前提なら、本当に必要？ 誰のために、どんな課題を解決するために WordPress 導入するの？ 全部静的にして、お客さんからの依頼で更新してもいいんですよ。 WordPress は全てのページを WYSIWYG で編集出来るように、メニューも管理 画面から変更出来るような設計になっているCMS。中途半端に使うと、実装が 大変な割にユーザーが結局更新してくれないという本末転倒なことに。 43
44. 特別なことをする理由がないなら、まずは、WordPress そのものの仕組み、 考え方に合わせて設計・ワークフロー構築をするべき。 WordPress を WordPress らしく使うためにはデフォルトテーマのように作 るのが一番いいし、ユーザーにもそれが基本的には一番優しい。 デフォルトテーマで出来ることが実現されていないのって、「WordPress 化」なんですか？ 44
45. WordPress を WordPress らしく使った話 ブロックエディタをゴリゴリ に使い倒してサイトを作った 話 https://speakerdeck.com/toro unit/kansai-wordpress- meetup-2023-09-23 45
46. Let’s share your WordPress experiences ! 46
47. Thanks! Github: @torounit Twitter / WP.org: @Toro_Unit torounit.com 47