ブロックテーマとこれからの WordPress サイト制作 / nishinomiya.dev@2025-12-21

Transcript

1. ブロックテーマとこれからのWordPressサイト制作 Toro_Unit / 2025.12.21 @ nishinomiya.dev 1
2. $ whoami Toro_Unit / 占部 紘 Frontend & WordPress Engineer WordPress Contributor Github: @torounit Twitter: @Toro_Unit 2
3. 長野県松本市から来ました 2025年12月13日（土）～ 2026年2月15日（日）まで松 本城のプロジェクションマッ ピングやってます。 3
4. ブロックテーマとは？ 4
6. WordPress 5.9 で導入されたテーマ。( Beta が取れたのは 6.2 ) フルサイト編集 (Full Site Editing, FSE) に対応。 従来のテーマと異なり、PHP テンプレートファイルを持たず、HTML テン プレートと theme.json で構成される。 ブロックエディターを使用して、サイト全体のレイアウトやデザインをカ スタマイズ可能。 ここ数年のデフォルトテーマ (Twenty Twenty-Two 以降) は全てブロックテ ーマ。 6
7. メリット カスタマイザー / ウィジェット / メニュー等が不要に。全てブロックで解 決するように。 PHP の知識が無くても、テンプレートなどをの開発が可能に。-> セキュ リティリスクの低減。 7
9. 「テーマの役割」の変化 従来のテーマ(クラシックテーマ) 完成したデザイン ブロックテーマ デザインの土台、コンポーネントの提供 9
10. ブロックテーマを開発するには 10
11. なんとなくわかった気になる ブロックテーマ入門 / contents.nagoya 2025 6.28 https://speakerdeck.com/chiilog/na ntonakuwakatutaqi- ninaruburotukutemaru-men 11
12. ブロックテーマでの開発事例 12
13. https://risshi-juku.jp/ 設計・デザイン・開発から全て丸っと担当。 13
15. 開発の経緯 塾の先生達からこんな相談。 12月頃、LINE公式アカウントをやりたい、それに伴ってサイト上での同線 を作りたい。 コンテンツの見直しなどもしたいので、操作方法などを教えてほしい。 現状だと情報の不足があってページ追加なども必要、お願いできないか？ 可能であれば自分たちで弄りたい。 15
16. 開発の流れ 1. 色彩設計、タイポグラフィ設計、余白のルール設計 2. ボタン等の汎用のコンポーネントのデザイン定義 3. TOPページ、下層ページの汎用のパーツのデザイン設計 4. ワイヤーフレーム等を作成しながら各ページのコンテンツ設計 5. ヘッダーフッター、ナビゲーションなどの実装 6. 各ページの実装、ブロックパターン等の作成 16
17. デザイン、コンテンツ設計 17
20. 実装方針 基本的に、theme.json で出来ることは可能な限り theme.json で。 css を直接書けば何でも出来るけど、theme.json の挙動など考慮すること が増えるので、可能な限り theme.json や、WordPress 側の機能で実装した い。 ナビゲーションなどは、css 変数が用いられているのでそれを上書きした りすれば多少はコントロール可能。 20
21. ブロックテーマで サイトリニューアルした話 / Toro_Unit / 2025.04.12 @ Shinshu WordPress Meetup https://speakerdeck.com/torounit/2 025-dot-04-dot-12-at-shinshu- wordpress-meetup 21
22. DEMO 22
23. ユーザーの感想 思ってたより簡単に使えた。いわゆる TinyMCE みたいなモノを想像して たからすげーってなった。 以前と比べてとかはよくわからない、触ってないしそもそも個人でサイト とか持ってないし。 ボタンとか簡単に足せるのはおどろいた、後から写真とか足せるのありが たい 普通のサイトが、文字とか画像とかが案外簡単に変えれないって話はそれ はびっくり 事前に編集する部分を決めるのはしんどい。てかわからん。 23
24. 俺の感想 投稿サムネイルとか、毎回作ってエラいなーって思ってたら canva で 結構 簡単に作れるという話。Instagram用の画像も作らないいけないというこ とで。 エンドユーザーがカジュアルにバナーとか作れる時代になったこと が、サイト運営、設計にも影響がある。 緊急のお知らせをどこに出す？みたいな話は緊急時になってみたときには じめてユーザー側が想像できる話だったりするので、柔軟な設計にしてお くメリットはあったなと。 24
25. ユーザーが求めるモノを 文字通り受け取っていいの？ 25
26. ブロックテーマでの開発について 26
27. 考えるべきこと オリジナルのブロックを作成しない限り、HTML を改変することが 難しい。そのため、デザインをフィックスさせてスタートすると 開発コストの増加に繋がる可能性が高い。 デザインと実装でフィードバックをしながらすすめることが重要。 各ブロックなどの挙動理解してデザインをすることが理想だけど、 組み合わせの問題などもあり、事前に把握するのは簡単ではないので、 サクッと実装してみて確認していくのが良いのでは。 27
28. じゃら全てのサイトがこうなるべき？ 28
30. なんか生成 AI でサイト作る話とかも増えたね。 「更新しないなら」を前提にするのは難しいけど、更新したくなったら捨 てて作り直す or AI に書き換えさせれば？みたいなアプローチもあり得 る。 CMS を使いこなすより、雑に AI に毎回作らせる方がコストが低い場合も あるかもね。 30
32. 「そもそもユーザーが Github 直接更新すればええんでない？」 それが出来たら苦労はない、がそれをやらせる方がCMSレクチャーする より楽という実例もある。 この辺のアプローチ、AI によって更に簡単になるのでは？ 32
33. WYSIWYG をやる理由、目的って改めてなんだろうね？ WYSIWYG はそもそも WEB サイトの編集の体験として正しい？ WYSIWYG が有用なケースは間違い無く存在するけど、WYSIWYG = 使い やすいが必ず成り立つわけでもない。 そうはいっても大抵の入力フィールドまみれの UI よりはマシだとは 思うけど。 33
34. 「ぼくらが考えた使いやすさ」 は「ユーザーが感じる使いやすさ」 とは必ずしも一致しない。 エンドユーザーが "考える" ではない。 使ってみないとわからんよね、というのが実情では。 34
35. Thanks!!! 35