WordPressでウェブアプリを構築する、第2版

第4章. テーマ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

WordPressテーマはウェブアプリのフロントエンドを動かす。 第1章では、WordPressテーマは伝統的なMVCフレームワークにおけるビューのようなものだという例えを紹介した。この例えは完璧ではないが、テーマとビューは、どちらもアプリの見た目をコントロールし、デザイナーが最も時間を費やす場所であるという点で似ている。

WordPressコミュニティによってまとめられたTheme Developer Handbookは、WordPress用のテーマを標準ベースの方法で構築する方法を学ぶための定義である。すべてのテーマ開発者はこのリソースを使うべきだ。この章では、アプリ開発者にとって特に重要なテーマ開発の分野をカバーする。

テーマとプラグインの比較

あるレベルでは、テーマやプラグインのすべてのソースファイルは、WordPressによって異なるタイミングで読み込まれる.phpファイルにすぎない。 理論的には、アプリのコード全体を1つのテーマや1つのプラグインに置くことができる。実際には、テーマをWebサイトのフロントエンド（ビュー）に関連するコード用に確保し、プラグインをアプリのバックエンド（モデルやコントローラ）に使いたいだろう。

コードをどこに置くかは、アプリ全体を作るのか、それとも個別のプラグインやテーマを作るのかによって決まる。

アプリ開発におけるコードの配置

完全なウェブアプリ（基本的に1つのWordPressインストール）を構築している場合、あなたはサイトやインストールされているテーマやプラグインにフルアクセスできる。 あなたのコードはどこにでも行くことができる。それでも、特定の機能をアプリのプラグインやテーマのモジュールとしてコード化すべきか、それとも別のプラグインとしてコード化すべきかを決定する際には、何らかの思考プロセスに従うべきだ。このステップでのあなたの優れた計画の主な恩恵を受けるのは、開発者（あなただけかもしれないが）だ。コードを適切に組織化することで、アプリの保守や開発が容易になる。

アプリを作る際、私たちは以下のガイドラインを使うようにしている：

• コアアプリのコードを格納するメインプラグインを1つ使い、フロントエンドのコードを管理するテーマを1つ使う。

• 他のプロジェクトで役に立ったり、他のプラグインに取って代わられる可能性のあるモジュール機能は、別のプラグインとしてコード化すべきである。

• 決してコアをハッキングしてはならない！¹

では、何がコア・アプリのコードで、何がフロントエンドのコードなのか？繰り返しになるが、擬似MVCフレームワークは次のようになる：

プラグイン = モデル

データ構造、ビジネスロジック、Ajaxサービスを定義するコードは、すべてコアプラグインに入れるべきである。CPTやタクソノミーの定義、フォーム処理、Post とUser クラスのラッパーなどもコアプラグインに入れるべきである。

テーマ＝見解

テンプレート・コードとフロントエンド・ロジックは、すべてテーマの中にあるべきだ。Webサイトのフレーム、ヘッダ、フッタ、メニュー、サイドバーはテーマでコーディングする。if(is_user_logged_in()) { //show menu } else { //show login } のようなシンプルなロジックはテーマに入れるべきだ。 ...