Slide 1

Slide 1 text

僕が考える 「HTML サイトを WordPress にする」話 Toro_Unit / 2023.11.05 @ Kansai WordPress Meetup 1

Slide 2

Slide 2 text

$ whoami Toro_Unit / 占部 紘 Frontend & WordPress Engineer Github: @torounit Twitter: @Toro_Unit 2

Slide 3

Slide 3 text

Contributions WordPress / Gutenberg Team Shinshu WordPress Meetup WordCamp Tokyo 2023 Speaker WordCamp Kansai 2024 Organizer Team 3

Slide 4

Slide 4 text

長野県松本市からきました Shinshu WordPress Meetup 毎回ピザ食ってます。 11/18 @松本 Wikimedia Commons/File:File:130608_Matsumoto_Ca stle_Matsumoto_Nagano_pref_Japan02bs4 .jpg Author:663highland.License:CC2.5 4

Slide 5

Slide 5 text

Q: WordPress テーマの開発フローってどうしてます? 5

Slide 6

Slide 6 text

HTML を作ってから WordPress テーマにする? いきなり WordPress テーマを作る? 6

Slide 7

Slide 7 text

WordCamp Tokyo 2015 での懇親会での一幕 登場人物 キタジマタカシ: Snow Monkey 等のテーマ作者。この頃は Snow Monkey を作 っていない、受託案件をいかに効率良くするか?ということでテーマ開発をし ていたり色々模索してたころ。 ハムさん (´ ºムº `): 札幌で、主に HTML/CSS をやったり、WordPress とか MT とかいろんな CMS でのサイト実装をしていたり。 7

Slide 8

Slide 8 text

(´ ºムº `):HTML / CSS / JS を完成させる -> WordPress に組み込む! 自分、キタジマ:「HTMLから作るのマジで無駄じゃないですか?」 (´ ºムº `): !!!!!???????? なんかめちゃくちゃびっくりされた。 8

Slide 9

Slide 9 text

そして、WordCamp Tokyo 2016 で 「デザイナーが効率よくテーマ作成を進めるに は? デザインから WordPress のテーマ作成のワークフローを見直す」というセッシ ョンやってました。 https://speakerdeck.com/h2ham/dezainagaxiao-lu-yokutemazuo-cheng-wojin- meruniha-dezainkara-wordpress-falsetemazuo-cheng-falsewakuhurowojian-zhi- su 9

Slide 10

Slide 10 text

自分の感想 手戻りめちゃくちゃ多くね ????? それだと WordPress の HTML とかに合わせるの辛くね????? エディタースタイルどうするんだ????? まぁまぁそうはいっても色んな事情あるしなー。 WordPress 開発する前に HTML でプレビューしたいとかあるらしいし。 案件次第、チームのスキル次第かねぇ。 とは言っても俺は _s とかそういうのベースに作り続けるけど。。。。 10

Slide 11

Slide 11 text

当時の結論 「まぁ一長一短よねー。」 という無難な結論 11

Slide 12

Slide 12 text

なんやかんやあって (´ ºムº `) と一緒に仕事したり会社に入ったり。 12

Slide 13

Slide 13 text

やっぱり効率わるくね????? 時代はブロックエディタ登場前 13

Slide 14

Slide 14 text

結局 テーマ開発のレールは未整備、みんな好き勝手やってる。 でもなんかデフォルトテーマを見てるとお作法とかはありそう。 alignleft / aligncenter / alignright だけしてればいいわけじゃ無い。ちゃんと WYSIWYG に対応させるの無理。任意の class を付ける方法は、TinyMCE のカ スタマイズ。 div タグは書けるけどビジュアルエディタモードでは存在が見えない。 14

Slide 15

Slide 15 text

っていうか WordPress に合わせて、HTML/CSSだけを書くのは少なくとも俺には無 理。 テストしながらやらないと無理。 Theme Unit Test Data を最初にインポートしての作業しないと結局バグる。 15

Slide 16

Slide 16 text

WordPressではHTMLをコントロールするのは結局難しい the_category など、よく出てくる テンプレートタグは、HTML をまとめて吐き 出すが、既に存在する HTML に合わせるのが難しいので使用できない。 get_terms 等で独自実装。 ナビゲーションメニュー、ウィジェットなど、WordPress 側が吐き出す HTML を改変するコストが高い or 不可能なため、カスタムフィールド等で謎の機能が 増える。 WordPress の機能を使い倒そうとすればするほどこの問題が重い。 その結果、カスタムフィールドでの対処が増える。 16

Slide 17

Slide 17 text

ブロックエディターの登場でさらにこの流れは加速。 そのHTML用のブロックを作る技術、コスト。 沢山のブロックがあってもそれはユーザーが使いこなせるの? メンテナンス出来る?アップデートで壊れない? カスタムフィールドで対処したらブロックエディタの恩恵は受けられない。 17

Slide 18

Slide 18 text

WordPress テーマ の機能は、「サイトの見た目を変更する」 作りがかなり緩いので、なんでも書けるけどそれを制約する仕組みが無い。な のでなんでもできるけど、なんでもしていいわけでは無い。 「HTML先に作ってからそれを WordPress に合わせて直していく」 のは、 「とりあえず素敵な服自由に服を作ってから、それを着る人に合わせて直す」 のような話に自分には思える。 18

Slide 19

Slide 19 text

ちゃんと WordPress を使い倒そうと思ったら、デフォルトテー マ、公式ディレクトリに掲載されてるテーマと同じ機能が必要。 それらと同じように開発するのが一番良い。 19

Slide 20

Slide 20 text

現在の開発フロー 1. 初期状態の WordPress を用意 2. _s をコピー / create block theme で empty テーマを作成 3. Theme Unit Test Data を import 4. CSSとブロックスタイルの追加 / ブロックの開発 / theme.json の設定など 5. 固定ページなどでコンテンツを作成 20

Slide 21

Slide 21 text

というのが僕の結論です。 が、世の中そうでも無いらしい。 https://x.com/hookwp_/status/170 1117360701354111?s=20 21

Slide 22

Slide 22 text

本題: HTML サイトを WordPress にする 22

Slide 23

Slide 23 text

「HTML サイトを WordPress にする」ってどういうこと? なんとなくわかるけど、具体的にどういうことだろう。 WordPress テーマ の機能とは、「WordPress サイトの見た目を変更する」 つまり、「HTML サイトを WordPress にする」 ということは「WordPress テーマ をつくること」とは違う。 「静的サイトを WordPress を用いて、ユーザーが記事を追加したり更新で きるようにする」 ということとここでは定義する。 23

Slide 24

Slide 24 text

「静的サイトを WordPress を用いて、ユーザーが記事を追加したり更新で きるようにする」 「WordPress でサイトを作ること」では無く、 「静的サイトに WordPress の 機能を後付けしたい」 ということだ僕は考える。 思考、設計の主体はあくまでも HTML/CSS で作ったサイト。 静的サイトを作り、それを WordPress に適用するというのは、そういうワーク フローになっている。 24

Slide 25

Slide 25 text

じゃぁそういう設計を考えてみよう。 メンタルモデル、本当にやりたいことに実装を合わせるのは重要。 そうしないと、矛盾が発生して色々破綻する。 ワークフローと設計は密接に関係する。 というか設計があって、それを実現する工程がワークフロー。 25

Slide 26

Slide 26 text

問題点 WordPress は静的な HTML と混在させて使うことを想定して作られていない。 WordPress の "サイト URL" 配下のコンテンツは、WordPress が管理。 特定のディレクトリだけ WordPress にするとかも不可能では無いが、共通部分 の管理、js の管理の方法等の違い等でソースコードの共通化は困難。 解決策 WordPress から API でデータを引っ張ってきてそれを表示する。そもそもAPIは外部 のサービス、システムと連携させるためのもの。 26

Slide 27

Slide 27 text

具体的な実装 HTML サイトを 静的サイトジェネレーター(SSG)作成し、WordPress と連携さ せる HTML サイトを作ってからそれに後付けするので、何らかの方法で CMS で追 加された記事を生成する必要がある。 別に SSG じゃなくても良いけど、現代の技術だと一番お手軽。 WordPress から API で記事を取得して、SSGで HTML を生成。 他の方法としては、アプリケーションフレームワークを用いたりとかだけど実 装コスト高い。 27

Slide 28

Slide 28 text

Astro 2022年リリース。現在再注目のフレームワ ーク。 React とかを使わずに普通の HTML っぽい 構文で作れる React とか Vue とかを部分的に混ぜて使っ たりも出来る 28

Slide 29

Slide 29 text

npm create astro@latest コマンド一発でプロジェクト作成出 来る。 29

Slide 30

Slide 30 text

既存の 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. に変更する。 30

Slide 31

Slide 31 text

Astro に WordPress で作成した記事を表示させる オフィシャルのドキュメント https://docs.astro.build/ja/guides/cms/wordpress/ WP-API で記事を取得して、それを Astro で埋め込む格好。基本的に記事は最大100 件しか取得出来ないので、全件取得などは工夫しないといけない。 31

Slide 32

Slide 32 text

WP-API で記事を取得して、一覧を表示 index.astro --- const res = await fetch("https://[wp-url]/wp-json/wp/v2/posts?_embed") const posts = await res.json(); ---
{ posts.map((post) => (

)) }
32

Slide 33

Slide 33 text

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 }, })); } ---

33

Slide 34

Slide 34 text

HTML に WordPress に後付けできた。 WordPress が記事閲覧時に動作しないので、動的な処理は出来ない。フォーム等 は、form.run / Formspree / SSGForm / Google Form 等の外部サービスを利用したり するのが簡単。 WordPress の一部の機能だけを使いたい、ということであればこれはこれで1つの方 法。 34

Slide 35

Slide 35 text

DEMO https://github.com/torounit/astro-wp-demo 35

Slide 36

Slide 36 text

デプロイしてみる ここでは、Cloudflare Pages にデプロイしてみる。 1. Github に レポジトリを作ってそこに Push 2. Cloudflare Pages で レポジトリを選択 3. ビルドコマンドの設定。プリセットで Astro を選べばやってくれる。自前で設 定するなら、 npm run build をビルドコマンドに設定して、生成されるディ レクトリをデプロイディレクトリに指定すればOK。 36

Slide 37

Slide 37 text

37

Slide 38

Slide 38 text

デプロイ完了! https://torounit-astro-wp- demo.pages.dev/ https://astro-wp-demo.netlify.app/ ドメインとか設定すれば、そのまま 仕事とかでも使える。 Netlify / Vercel / Amplify とかでもだ いたい同じ。 38

Slide 39

Slide 39 text

デプロイ方法、記事の更新方法 Cloudflare Pages / Vercel / Netlify などの Jamstack のホスティングを利用。 Github Actions を用いてレンタルサーバーにデプロイしても良い。 WordPress の 記事更新時に Webhook を叩いて更新。 WordPress.com の無料ホスティングも利用できる。 39

Slide 40

Slide 40 text

この方法のメリット ほぼ落ちないサイトがローコストに作れる。WordPress が落ちてもサイトは落 ちないし、WordPress 側にアクセスがないので、強力なサーバーが必要ない。 (画像などは WordPress 側のホストから読まれる) CMS は違うかもだけど、「しいたけ占い公式サイト」でも採用されている。 「しいたけ占い公式サイト」を支える技術: https://hori- ryota.com/blog/shiitakeuranai-dev/ 40

Slide 41

Slide 41 text

デメリット WordPress の設計に合わせてるわけではないので、WordPress の機能を使い倒 すことは出来ない。 記事のプレビューなど、別途その機能を作る必要があったり、あきらめた りする必要がある。 これ大真面目にやると、WordPress で作るよりコストがかかる場合も。 ただし、WordPress で作るよりも、サイトのパフォーマンスは良い。 41

Slide 42

Slide 42 text

おわりに まぁこんな方法もあるよ。 自分がつくろうとしているモノをちゃんと理解すること、そしてそれに合致し た設計・技術選定・ワークフローになっているのか?という問いにちゃんと向 き合わないと色々歪む。 HTML を書けない人のために CMS を導入してるのに、HTML を記述させ たりとか。 ページを追加するのに、テーマファイルを編集する必要があるとか。 42

Slide 43

Slide 43 text

何のために CMS 導入するの? 「WordPressを導入する」が目的化していませんか? 変更とかをいちいち依頼してもらう前提なら、本当に必要? 誰のために、どんな課題を解決するために WordPress 導入するの? 全部静的にして、お客さんからの依頼で更新してもいいんですよ。 WordPress は全てのページを WYSIWYG で編集出来るように、メニューも管理 画面から変更出来るような設計になっているCMS。中途半端に使うと、実装が 大変な割にユーザーが結局更新してくれないという本末転倒なことに。 43

Slide 44

Slide 44 text

特別なことをする理由がないなら、まずは、WordPress そのものの仕組み、 考え方に合わせて設計・ワークフロー構築をするべき。 WordPress を WordPress らしく使うためにはデフォルトテーマのように作 るのが一番いいし、ユーザーにもそれが基本的には一番優しい。 デフォルトテーマで出来ることが実現されていないのって、「WordPress 化」なんですか? 44

Slide 45

Slide 45 text

WordPress を WordPress らしく使った話 ブロックエディタをゴリゴリ に使い倒してサイトを作った 話 https://speakerdeck.com/toro unit/kansai-wordpress- meetup-2023-09-23 45

Slide 46

Slide 46 text

Let’s share your WordPress experiences ! 46

Slide 47

Slide 47 text

Thanks! Github: @torounit Twitter / WP.org: @Toro_Unit torounit.com 47