こういう細かい話とかが意外と共有されて無さそうなので気をつけてることを思いつく限りつらつらと。 テンプレートのトップレベルには、グループブロックを配置しその中に要素を設置する。 Twitter でも書きましたが、トップレベルにはグループブロックが必要です。基本的にはグループブロックがサイトの横幅を制御しています。CSS とかで横幅の制御を自前でやっても管理画面では崩れたり、幅広や全幅が正しく動作しなかったりします。 Twenty Twenty-Five だとこんな感じです。main タグがそれに当たります。 <!-- wp:template-part {"slug":"header"} /--> <!-- wp:group {"tagName":"main","style":{"spacing":{"margin":{"top":"var:preset|spacing|60"}}},"layout":{"type":"constrained"}} --> <main class="wp-block-group" style="margin-top:var(--wp--preset--spacing--60)"> <!-- wp:query-title {"type":"archive"} /--> <!-- wp:term-description /--> <!-- wp:pattern {"slug":"twentytwentyfive/template-query-loop"} /--> </main> <!-- /wp:group --> <!-- wp:template-part {"slug":"footer"} /--> テンプレートや、テンプレートパーツの要素は基本的に「コンテント幅を使用するインナーブロック」が有効になっている （"layout":{"type":"constrained"}が設定されている）グループブロックの子要素になるものと考えればよいと思います。 CSS の記述は極力避けて、ブロックの設定でスタイリングを行う。 エディター側でスタイルを変更する機能が結構沢山あるんですが、「エディタで変更したのにスタイルが当たらない」とかの問題を引き起こしがち。また、最近は少なくなった気がしますが、WordPress のアップデートで CSS のセレクタの優先度やセレクタそのものが変更されることもあったりするので、その際にアップデートを困難にする一つの要因になります。 それでも CSS を記述する場合も当然存在します。その際は「WordPress が提供してるスタイルを上書きして塗り替える」的なアプローチより、「WordPress に足りないスタイルをちょい足しする」みたいなスタンスで付き合うのが良いのかなと。 また、html 要素に対して、font-size: 62.25% とかを設定するのも避けたいです。最近だとエディタが iframe になったのでデメリットが減りましたが、管理画面でのルート要素とフロントエンド側側でのルート要素に当たるスタイルが一致しないとかで不具合を引き起こしたりします。

WordPress 7.1 でテックリードを務めた浜野さんがこんな話をしてました。 実際に、たびたびマイナーリリースを待ってからみたいな話は聞きますし、気持ちとしては理解できる「WordPressはマイナーリリースがでるまでアップデートしない」ってのがそもそも戦略として妥当なのかというのはそもそも考える必要があるのではないかなと。 WordPress のセキュリティポリシー Ubuntu とかだと、ポイントリリース（マイナーアップデート）が出るまでメジャーアップデートを有効にしなかったりその辺はプロダクトの性質やら開発の方針とかで色々ポリシーがあると思います。 WordPress はどうかというと、メジャーリリースが出たらそのタイミングでアップデート可能になってます。まぁ OS と CMS じゃそりゃ当然違うわけです。Ubuntu だと LTS のサポートは5年ありますが、WordPress が公式にサポートしてるのは最新バージョンだけだったりします。 WordPress の最新バージョンのみが公式にサポートされていますが、セキュリティチームは、古いサイトが自動更新を介して重要なセキュリティ修正を受けられるように、好意で古いバージョンにも修正をバックポートしています。 文字通り解釈すれば、7.1 がリリースされた時点で 7.0 はもうサポート外というわけです。実際のところ 4.7ブランチでもアップデートがまだ提供されているわけではありますが、動作保証とかそういうわけでもないです。 また、長いことプラグイン作者やってますが、そう簡単に最低動作バージョンを変えることもしないですし、サポートを切るとしても流石に過去2バージョンくらいは一応サポートするか、みたいなスタンスが結構多いのではないかなと。 「マイナーリリースまで待ったから大丈夫」は本当なのか 当たり前の話ではありますが、マイナーリリースが出たから必ずバグがなくなるというわけでも無いです。当然マイナーリリースを重ねればそりゃ改善されていく訳なんですが。 先日の wp2shell なんかは 7.0.1 で発見されてますし、こちらも影響が大きかった WordPress の WP-API が搭載された 4.7 では権限昇格の脆弱性がありましたが、これが修整されたのは 4.7.2 です。じゃぁ x.x.2 まで待つのが正しいの？という話になるかというと、当然そんなわけ無いわけです。たまたまそのタイミングで発見されただけに過ぎません。 また、流石にもうやらないでしょうが、4.9.xの頃は「ブロックエディターをリリースするまで 5.0 を出さない！」としてしまったせいで4.9.xが1年以上続き、通常だったらメジャーリリースで入るようなものがマイナーリリースとして出荷されたこともありました。 結局、バージョン番号の振り方やそれの位置づけ自体プロダクトによって全然異なるので、「マイナーリリースまで待った方がいい」がいつでも正しいわけではないはず。 また、待つことで当然プラグインなどの更新も貯まり検証コストが増え、アップデートに関するコストが上がっていきます。そうしてるうちに次のメジャーリリースが増えて、結果アップデートがされなくなっていった WordPress をたびたび見てきました。メジャーリリースのバグを踏むより、そちらの方がよほどリスクが高い状態なのではと考えてます。 「プラグインやテーマのサポートを待ってから更新」について 一般論としては割と真っ当だと思う話だと思うんですが、WordPress に限っては基本的には待たずに更新するのが良いのかなと思います。 後方互換をかなり大事にしているので、古い関数も20年以上残し続けていたりします。また過去に Gutenberg でプルリクエストを出した際に、どうしても hook を残せないことがありましたがそのときは影響を受けるプラグイン作者に連絡を入れたりしてました。公式レポジトリ掲載しておくとこういうこともあるんだーと思いました。 なので、WordPress 本体を更新したところでテーマやプラグインが不具合を起こすってのは結構希なケースではあります。( CSS とかでテーマ作者が苦労してる話はたまに聞いたりしますが。) そうなるとプラグイン作者としてはまぁ別に動いてるしいいかってなってプラグインの更新を放置しがちだったりもします。readme.txt の Tested up to の数字を更新するだけなのですが、その「更新するだけ」がなかなかできない。「CI も通ってるし手元で動いてたし、手が空いたときにでもやろう」ってなってそのまま忘れてたり。別に全部のプラグインがそうではないんですが、有名なプラグインでも結構そういうことが起きてるのはそう珍しい話でもないです。 そうなってくると、「プラグインやテーマのサポートを待って」というのは結局いつのタイミングでやればいいのかが不透明になってきます。 じゃぁ結局どうするのが良いのか そのサイトの事情次第としか言えないのですが、まずそのサイトの保守に見合ったアップデート戦略を立てるのが大事なのかなと。極論、小規模なサイトで謝って済む場合であればメジャーリリースもプラグインも自動アップデートという戦略もありだと思います。実際にそういう運用にしてるクライアントワークもあります。 それができないのであれば、「検証用の環境で Beta3 や RC が出た段階で検証を開始し、リリース後一週間以内くらいでアップデートを適用する」、とかが良いのかなと思ってます。 また WordPress プラグインの方が基本的にはコアより問題を起こすのではという気はします。玉石混交ですし。そもそもよっぽどのことが無い限り他のプラグインとの結合テストなんてプラグイン開発側でやらないですし。 検証コストが少ないうちにちまちまアップデートをしていくのが、結局のところ大事です。当たり前の回答なんですが、結局動かしてみないことにはわからないわけで。そのためには、いつでもサクッと検証できるような環境を含めて保守したりが必要になってきますが、最近だとステージング機能を提供しているレンタルサーバーも増えましたし、昔よりはその辺が大幅にやりやすくなったはずです。 「マイナーリリースまで待ったから大丈夫」は別に根拠ない。 「プラグインやテーマのサポートを待ってから更新」も微妙、とりあえず検証しよう。 溜めるとコストが増大していくので、短いスパンでコストが小さいうちに片付ける。 そんなことを、溜まった洗濯物の山とか食器の山とか気がついたら溜まりに溜まってる段ボールなどから目をそらしつつ思う次第です。

AI Provider for OpenAI のほぼほぼコピーみたいな感じでサクッと作れるのでは？ということで、LM Studio 用の AI Provider を作ってみました。 プラグインをインストールして、LM_STUDIO_SERVER_URL を適当に設定すれば使えます。wp-config.php に以下のような感じで書く感じです。便利そうだったらそのうち管理画面上から設定可能にしようかなとは思ってます。 define( 'LM_STUDIO_SERVER_URL', ' ); デフォルトでは、 を指しているので、npx @wordpress/env --runtime=playground とかで起動するぶんには、なにも設定せずに動くと思います。docker 等を指定してください。 LMStudio 側で認証を有効にした場合は、作成したトークンを AI コネクタの設定画面上の API キー設定の所に入れてください。 ネットワーク上のホストで実行するには LMStudio をそこから見えるようにしないといけないので、tailscale とか Cloudflare Access とかを使ってそのサーバーからアクセス出来るようにする必要があります。 特長としては、Text Embedding 用のモデルも WordPress 側から呼び出せるようにしてあります。ベクトル検索のプラグインをローカルで開発するとかそんな用途で使うのが良いんじゃ無いでしょうか。 色々気にせず雑に使い倒せたりデバッグログとかが見えたりするのは、ローカル LLM のメリットかなと思ったりしてます。まぁ速度はかなり遅いのでタイムアウトしたりもしますので、実験とか遊びで使う感じになるのかなと現時点では思ってます。今後の未来に期待したいところ。AIプラグイン の機能もテキスト生成とかは使えるはずなので遊んでみてください。

僕がメンテしてるプラグインに Custom Post Type Permalinks ってのがありまして。 もともとこのプラグイン、WordPress 自動で投稿のスラッグがタイトルから生成される機能あるんですが、「日本語で記事を書くと日本語でスラッグが設定されてちょっと面倒くさい」みたいな問題を、パーマリンクを自由に設定出来ないカスタム投稿タイプでもなんとかしたいなーみたいな動機で生まれたモノです。 ただ、URL に投稿IDを設定すると、WordPress から 別の CMS とかではもちろん、WordPress から WordPress への記事のインポートなどでも URL が変わってしまいます。この挙動はちょっと問題あるなと思っていました。また、このプラグインを作成した頃からだいぶ時が経ち、日本語が含まれた URL でもそこまで不便しないなとは思っています。まぁ、そうはいっても URLエンコードされない URL にしておきたいニーズがあるのもわかるなーと思いつつモヤモヤしてました。 投稿 ID を URL に含めない形でクリーンなURLが生成されてほしいなーと思って何年も経った今日この頃、WordPress 7.0 で AI Client が搭載されることになりました。 これを用いて、投稿のタイトルからスラッグを生成するのは筋が良さそうだなと思い、突貫でプラグインをこさえてみました。Slug Automator という名前で WP.org にリリースしてあります。 Slug Automator プラグインの提供する機能 以下の2つの機能を提供します。WordPress 7.0 以上対応なので、6.9 等では有効化できません。RC版や、ローカルの開発環境などで試してみてください。また、AI コネクタでの API Key が必要です。Google / Anthropic / OpenAI のどれでも動作します。 記事公開時にスラッグが未設定の場合、投稿のタイトルからスラッグを自動的に生成 記事公開時にスラッグが未設定であれば自動的にスラッグを生成します。すでにスラッグが設定されている場合は何もしません。 記事の投稿画面にて、スラッグの生成/再生成を行う機能 投稿設定のところに、「Generate Slug」というボタンがあるので、これをクリックするとスラッグの生成を行います。既存の記事のスラッグを変更したい場合、下書き時にスラッグを生成させて確認したい場合などはこの機能を用いてください。手動で生成させた場合は既存のスラッグを上書きします。 タイトルからスラッグを生成するだけのシンプルな機能なので、Google AI Studio の無料枠とかでもそれなりにちゃんと機能するかなという感じです。 Github: フィードバックなどお待ちしてますー。

先日、page-*.php を使うことの是非みたいな話が話題になりました。それについて僕なりの見解をまとめておこうと思います。

Deploy your applications with ease using Dokploy

Jetpack のお問い合わせフォーム、ブロックエディターからの操作が簡単で、サクッとフォームを作りたいとかの時は便利かなと思ってます。 ただメールフォームを設置するとスパムメールで問い合わせメールが埋もれてしまいます。 Akismet の導入を検討したのですが、そこまでコストかけるほどでも無さそうな感じだったので、サクッと自前でスパム判定機能を実装してみました。 実装 ソース読んでいくと、jetpack_contact_form_is_spam というフィルターフックがあるので、この辺使うと上手いこと出来そうです。 projects/packages/forms/src/contact-form/class-contact-form.php の2690 行あたりにそれっぽいコードがありました。 // Is it spam? /** This filter is already documented in \Automattic\Jetpack\Forms\ContactForm\Admin */ $is_spam = apply_filters( 'jetpack_contact_form_is_spam', false, $akismet_values ); if ( is_wp_error( $is_spam ) ) { // WP_Error to abort return $is_spam; // abort } elseif ( $is_spam === true ) { // TRUE to flag a spam $spam = '***SPAM*** '; }

Custom Post Type Permalinks をアップデートしました。アップデート内容は以下の通りです。 WordPress 6.9 / 7.0 beta での動作テスト PHP 8.4 での動作テスト 最低動作環境を、WordPress 6.7 / PHP 8.0 変更。 自動テスト環境の更新 プラグインの本体の変更はほぼ無く、CI とかその辺の修整が中心です。 アップデートよろしくお願いします。