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