これまでの【theme.json 実験室】では、settings を中心にさまざまな機能を実験してきました。

theme.json の layout は、ブロックテーマを作り始めると必ず目にする設定の一つです。
しかし、「何となく contentSize と wideSize を書いているだけ」という人も多いと思います。

theme.json の settings と styles は役割がまったく異なります。

theme.json の Spacingプリセットは、余白の値をテーマ全体で統一して管理するための仕組みです。

theme.json では、テーマ独自のカラーパレットを定義できます。
多くのテーマで使われている機能ですが、

今回は settings.border を実際に試しながら、仕様を確認していきます。
名前の通りBorder関連の設定になります。

theme.json には、ブロックで使用する Shadow（影） をプリセットとして登録する機能があります。
WordPress公式ドキュメントには基本的な書き方は載っていますが、

appearanceTools は、theme.json の中でも比較的よく見かける設定です。

今回は、その続きです。
fontSizes には fluid という項目があります。

theme.jsonを書いていると、

「この設定を書いたら、どこがどう変わるんだろう？」

ブロックテーマには「テンプレート」「テンプレートパーツ」「パターン」という、名前がよく似た仕組みがあります。
どれもブロックを使って編集するため、最初は「何が違うの？」と迷う方も多いでしょう。

• おすすめの開発環境は何ですか？

• XAMPPとLocalはどちらがいいですか？

• Studioでも開発できますか？

WordPressの権限管理というと、「誤操作を防ぐため」「セキュリティ対策のため」という印象を持つ方が多いかもしれません。
もちろん、それも間違いではありません。

2026年でもWordPressを学ぶ価値は十分あります。
ただし、昔と同じ「HTMLとCSSを書いてテーマを作る」という学び方ではありません。

最近は、AIを使ってWordPressテーマを制作する人も増えてきました。
「AIだけでテーマは作れるのか？」
「どこまで任せられるのか？」

Composerの基本操作(composer requireなど)はなんとなく分かるけれど、グローバルインストールやVSCode拡張機能との連携は初めて、という人にも読めるように書いています。

• 便利な機能を追加する。

• 細かい部分まで制御できるようにする。

• テーマだけで完結できるようにする。

style.cssは、テーマをWordPressに認識させるためのテーマ定義ファイルとしての役割を持っています。

WordPress公式テーマ審査で重要なのは、単純にデザインが優れていることではありません。

WordPressテーマ制作では、functions.phpは万能ファイルではありません。
とりあえず、「動くから書く」を繰り返すと、functions.phpはすぐに肥大化します。
さらに問題なのは、functions.phpをプラグインの代わりとして使ってしまうことです。
テーマと機能の責任範囲を分けない設計は、あとから保守やリニューアルで問題になります。

WordPressが重い原因は、必ずしもサーバーやプラグインだけではありません。
特に管理画面やサイト全体の表示が遅い場合、データベースの `wp_options` に保存されたautoload対象データが肥大化しているケースがあります。
この記事では、WordPress内部の設定保存テーブルである `wp_options` と、ページ表示時に読み込まれるautoloadの仕組みについて、保守・改善の視点から解説します。

WordPressには「Cron（クーロン）」と呼ばれる仕組みがあります。
しかし、サーバー管理で使う本来のCronとは少し違います。
名前は同じですが、実行される仕組みは別物です。

ブロックテーマ制作を始めると、多くの人が最初につまずくのが theme.json です。

テーマ制作を主な活動にする前は、長い間 _s（Underscores）というテーマをベースにカスタマイズしていた。
_sはAutomattic社が提供しているスターターテーマで、WordPressテーマ開発者の間では非常に有名な存在である。
テーマ制作に必要な基本ファイルが揃っており、余計なデザインや機能を持たないので、カスタマイズがしやすい。
_sをベースにテンプレートを編集し、PHPを書き、CSSでデザインを作り込むという流れでテーマを制作していた。