プラグイン開発における WordPress ボイラープレートの重要性

過去 5 ～ 10 年の間に、Web サイトや Web アプリケーションの構築は、1990 年代に構築された多くのものよりもはるかに複雑になりました。大文字の HTML、テーブルベースのレイアウト、醜い JavaScript を使用して Web サイトを手動で作成し、ページ上で何らかのかわいいアニメーションを作成する時代は終わりました。

現在、さまざまなテクノロジー、フレームワーク、言語があり、それらがすべて連携して、ブラウザーで実行される完全なソフトウェア アプリケーションを構築するのに役立ちます。

今は開発者にとって素晴らしい時期です。

自由に使えるテクノロジーが非常に多いため、ボイラープレートの人気はますます高まっています。馴染みのない人のために説明すると、ボイラープレートは基本的に、開発者がすべてのサイトやアプリケーションに共通するコードや特定のコンポーネントを記述せずにプロジェクトをすぐに開始できるようにするコード ベースです。

もちろん、やりすぎて必要以上に面倒で複雑になる可能性がありますが、優れたものはすべて、コア アルゴリズムの作成に集中できるように基礎を築くこと、つまり一種の足場を提供することを目的としています。プロジェクトとニーズに固有のコードと関数。

1 年以上前、私は WordPress Plugin Boilerplate と WordPress Widget Boilerplate という 2 つのプロジェクトに取り組み始めました。それぞれの目的は、WordPress のベスト プラクティスを使用してプラグインを構築するための基盤を開発者に提供することです。ありがたいことに、これらのプロジェクトは、可能な限り強力なものにするために、オープンソース コミュニティから他の多くの貢献も受けています。

これらのプロジェクトを維持する際の 1 つの側面は、なぜこのように配置するのかという質問を受けることがよくあることです。したがって、この 2 部構成のシリーズでは、定型ファイル、私が行っている方法で定型ファイルを整理する理由 (および利点) を見ていき、次に、これらの定型ファイルの 1 つを使用して単純なプラグインを構築して、例を示します。将来のプロジェクトでそれらをどのように使用するか。

---

ファイル構成

ソフトウェア アプリケーションを構築する際の重要なコンポーネントの 1 つは、規模の大小を問わず、プログラムをどのように構成するかです。これは、クラスや関数がどのように関連しているか (これについては別の記事で説明します) に限定されるものではなく、ファイルがどのように編成されているかにも当てはまります。

理想的には、ファイルを単にディレクトリにダンプし、プロジェクトを維持するために他の開発者が選別するままにしておくべきではありません。代わりに、ファイルは一貫したディレクトリに論理的に編成され、(巧妙にではなく) 明確に名前が付けられるべきであり、プロジェクトに貢献する開発者は、特定のファイルがどこにあるのか、自分で追加したものをどこに置くのかを知るためにほとんど労力を必要としないはずです。

これは古い格言のようなものです:

あらゆるものを適切な場所に配置。

これら 2 つのボイラープレートを作成するとき、私はこの特定の原則に従おうとしただけでなく、Ruby on Rails がそのレイアウトをモデル化する方法からインスピレーションを得ようとしました。具体的には、彼らは「設定よりも慣例」を好みます。

明らかに、WordPress は Rails ではなく、MVC フレームワークでもありませんし、そうであってほしくありません。他の開発者から良いアイデアを借りて、私たちの環境での生活を楽にしたいだけです。

コアプラグインファイル

プラグインがどれほど単純か複雑かに関係なく、プラグインには少なくとも 1 つの PHP ファイルが含まれている必要があります。 このファイルはコア プラグイン ファイルとして機能し、プラグインを有効にするすべてのコード、ロジック、機能が含まれています。

さまざまなプラグインを見ると、開発者がさまざまなアプローチをとっていることがわかります:

• 一部のファイルには すべてが 1 つのファイルに含まれています
• 関連する関数を別個のファイルに分割し、コア プラグイン ファイルを使用して各関数を単純にインクルードする場合もあります
• フロントエンド コードの一部をサーバー側コードから分離するものもあります

私はここで、これらの方法 (または言及されている方法) が他の方法よりも優れている理由を証明するためにここにいるのではなく、ボードがなぜこのようにレイアウトされているのか、そしてそれがどのように機能するのかを説明するだけです。

README ファイルに基づくプラグインのホームページ。

WordPress プラグインには、コア プラグイン ファイルに加えて、エンド ユーザーにプラグインの使用方法と WordPress プラグイン リポジトリ内のページへの入力方法に関する手順を提供する Readme ファイルも必要です。

最も基本的なレベルでは、WordPress プラグインに必要なのは、コア プラグイン ファイルと Readme ファイルだけです。これら 2 つのファイルだけを使用して非常に複雑なプラグインを構築できますが、特に他の開発者が貢献し始めた場合、メンテナンスが非常に困難になる可能性があり、最終的には予期しないバグが発生する可能性があります。

したがって、私はコードを論理的に分離するコンポーネントの大ファンです。

視聴回数

View は、MVC パターンから借用した言葉です (Rails からインスピレーションを受けました)。

ビューは、管理者や Web サイト訪問者のために画面上に要素をレンダリングするフロントエンド マークアップとして定義できます。

＃＃＃それだけです。簡単ですよね？

もちろん、PHP で作業しているため、コード全体にいくつかの小さな PHP タグが配置されることは間違いありませんが、ビュー ファイルの大部分は、class 属性と ID 属性を持つ HTML である必要があります。

テンプレートには 2 つのビューがあります:

1. admin.php は、管理ダッシュボードでユーザーに要素を表示するために使用されるビューです。
widget.php
2. または plugin.php は、Web サイト訪問者に要素をレンダリングするために使用されるビューです。 もちろん、プラグインにはダッシュボードや Web サイト訪問者のビューがない場合もあります。この場合、
views

ディレクトリが削除され、コア プラグイン ファイルにこれらのディレクトリを含めるコードが削除されます。

スタイルシート

これは、定型文の簡単なコンポーネントです。フロントエンド開発を行う人なら誰でも、スタイルシートの管理方法を知っており、スタイルシートを編成する独自の方法を持っている可能性があるためです。

ただし、一貫性を保つために、

css

ディレクトリにすべてのスタイルシートが保存されることに注意してください。これらのファイルも、関連するビューと同じ命名規則に従います。

＃＃＃特定の：＃＃＃

admin.css

は、管理ダッシュボードでユーザーの要素をスタイル設定するために使用されるビューです。

widget.css
1. または plugin.css は、Web サイト訪問者向けの要素のスタイルを設定するために使用されるビューです。
2. LESS または SASS にディレクトリ構造を導入することを検討しましたが、それは開発にとってあまりにも独断的すぎると思いますし、それは私がボイラープレートに望んでいる方向ではありません。むしろ開発者が自分のスタイルを選んで取り入れてほしいと思っています。 この目的を達成するために、私が通常プロジェクトでスタイルシートを整理する方法は、css ディレクトリ内に
dev

ディレクトリを導入し、次に

admin .less# を導入することです。 ## および

plugin.less

ファイルはコンパイルされ、ルートの css ディレクトリに縮小されます。 これは、組織の定型的なアプローチに従い続けながら、LESS ファイルを含めることも可能にします。 JavaScript スタイルシートと同様、JavaScript ファイルは定型文の単純なコンポーネントです。これは、WordPress を使用してテーマやプラグインを開発するほとんどの人が JavaScript を使用しているためです。 残念ながら、ユーザーとしても開発者としても、WordPress で JavaScript を使用する際に最もイライラする部分の 1 つは、開発者がベスト プラクティスに従っていないことが多いことです。

一般に、開発者は常に次のことを行う必要があります:

WordPress にバンドルされているバージョンの jQuery を使用してください

匿名関数を使用して jQuery '$' 関数にアクセスすることで、jQuery '$' 関数との競合を回避します

jQuery を別のプラグインとして登録解除しないでください。テーマがそれを使用している可能性があります。

そうは言っても、スタイルシートやビューなどの定型ファイルは次のように構成されています。
2. admin.js
は、管理ダッシュボードのユーザー要素の動作を管理するために使用される JavaScript です。
widget.js

または

plugin.js

は、訪問者に対する要素の動作を管理するために使用される JavaScript

です。
1. スタイルシートと同様に、開発者はプラグインを公開する前に JavaScript を検査および/または縮小することもできます。 JavaScript ファイルの管理方法が厳格になりすぎないように、定型文にはサブディレクトリは含まれていませんが、事前チェックを管理するために js
ディレクトリ内に
2. dev ディレクトリを作成することがよくあります。事前に縮小された JavaScript。 ＃＃＃言語＃＃＃ プラグインを構築する際の 1 つの側面は、他の言語を話す人がプラグインにアクセスして翻訳できるようにすることです。できるだけシンプルにするために、ボイラープレートには lang
ディレクトリとスケルトン

plugin.po

ファイルも含まれています。 このファイルは、POEdit と組み合わせて使用​​するように設計されているため、開発が完了すると、ローカライズされたすべての文字列を簡単に処理できるようになります。 画像やその他のアセットはどうなりますか?

ボイラープレートは、スタイルシートと JavaScript ファイル以外の他のアセット (画像など) を管理するためのディレクトリや規則を提供しません。

繰り返しますが、これは、開発者がコア機能に集中できるように十分な足場を提供しながら、意見が偏りすぎないようにするバランスです。すべてのプラグインに管理 CSS、JavaScript、またはビューが含まれているわけではありませんが、画像やその他のリソースが含まれるよりも一般的です。 ただし、規定されている規則では、assets ディレクトリ、

images

ディレクトリ、

icons

ディレクトリ、またはその他の使用するタイプのディレクトリを作成できると記載されています。ファイルの。

なぜわざわざ？

WordPress ウィジェット テンプレート それでは、これには一体何の意味があるのでしょうか?ファイルを開いてすべてのコードを書き始めるのは簡単だと思いませんか?本当に。ただし、ほとんどの開発は製品のリリース後に行われるため、プラグインの開発に真剣に取り組んでいる場合は、製品を構築する仕事に携わることになるということを覚えておいてください。 したがって、終わりを念頭に置いて始める必要があります。ファイルの整理、ファイルの名前付けなどには一貫したスキームを使用してください:

• 長期的には開発を簡素化し、開発者と開発者がファイルの管理方法、新しいファイルの配置場所、必要に応じた依存関係の検索方法を理解できるようにします
• プラグインを強化できる共通の構成とパターンを提供することでメンテナンスが容易になります
• コードベースが扱いにくくなった場合に大規模なリファクタリングを必要とせずに、最初のバージョンを超えてプロジェクトを拡張する機能の向上

最も重要なことは、スキャフォールディングにより、開発者が邪魔をせずに製品の中核となるビジネス ロジックに簡単に取り組み始められるようにすることです。

---

＃＃＃結論は＃＃＃

この記事では、定型文の構成の「なぜ」について検討しましたが、実際には定型文の「方法」については検討していないため、次の記事ではそれについてのみ説明します。

具体的には、ボイラープレート ファイルの 1 つを使用してプラグインを段階的に構築し、ボイラープレートのコピーを取得して開発を開始するために必要な一般的な手順を決定できるようにします。

以上がプラグイン開発における WordPress ボイラープレートの重要性の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。