最新のPHPによるWordPressコードの改善

WordPressは15年前に誕生しましたが、下位互換性が歴史的に維持されているため、新しいバージョンのコードでは、新しいバージョンのPHPが提供する最新の機能を十分に活用できませんでした。 PHPの最新バージョンは7.3.2ですが、WordPressはPHP5.2.4までのサポートを提供します。

しかし、それらの日はすぐに終わります！ WordPressは、最小のPHPバージョンサポートをアップグレードし、2019年4月にPHP 5.6に、2019年12月にPHP 7にアップグレードします（すべてが計画どおりに進んだ場合）。 そうすれば、クライアントのサイトを壊すことを恐れることなく、最終的にPHPの命令型プログラミング機能の使用を開始できます。 やあ！

WordPressの15年間の関数型コードは、開発者がWordPressを使用して構築する方法に影響を与えたため、当社のサイト、テーマ、プラグインには、アップグレードを喜んで受け取ることができる最適ではないコードが散らばっている可能性があります。

この記事は2つの部分で構成されています。

1. 最も関連性の高い新機能
   PHPバージョン5.3、5.4、5.5、5.6、および7.0にさらに機能が追加され（PHP 6がないことに注意してください）、最も関連性の高い機能について説明します。
2. より良いソフトウェアの構築
   これらの機能と、それらがより優れたソフトウェアの構築にどのように役立つかを詳しく見ていきます。

PHPの「新」機能を調べることから始めましょう。

クラス、OOP、SOLID、デザインパターン

クラスとオブジェクトがPHP5に追加されたため、WordPressはすでにこれらの機能を利用していますが、それほど広範または包括的ではありません。WordPressのコーディングのパラダイムは、オブジェクトではなく関数型プログラミング（アプリケーション状態のない関数を呼び出すことによって計算を実行する）です。指向プログラミング（OOP）（オブジェクトの状態を操作して計算を実行する）。 したがって、クラスとオブジェクト、およびOOPを介してそれらを使用する方法についても説明します。

OOPは、モジュラーアプリケーションの作成に最適です。クラスを使用すると、コンポーネントを作成できます。各コンポーネントは、特定の機能を実装し、他のコンポーネントと対話でき、カプセル化されたプロパティと継承を通じてカスタマイズを提供できるため、高度なコードの再利用が可能になります。 結果として、個々の機能をアプリケーションから分離して独自に処理できるため、アプリケーションのテストと保守が安価になります。 開発者はすでに開発されたコンポーネントを使用でき、アプリケーションごとに車輪の再発明を回避できるため、生産性も向上します。

クラスにはプロパティと関数があり、 private （定義クラス内からのみアクセス可能）、 protected （定義クラスとその祖先および継承クラス内からアクセス可能）、およびpublic （どこからでもアクセス可能）を使用して可視性を与えることができます。 関数内から、名前の前に$this-> ：を付けることで、クラスのプロパティにアクセスできます。

 class Person { protected $name; public function __construct($name) { $this->name = $name; } public function getIntroduction() { return sprintf( __('My name is %s'), $this->name ); } }

クラスはnewキーワードを介してオブジェクトにインスタンス化され、その後、 -> ：を介してそのプロパティと関数にアクセスできます。

 $person = new Person('Pedro'); echo $person->getIntroduction(); // This prints "My name is Pedro"

継承クラスは、その祖先クラスからpublic関数とprotected関数をオーバーライドし、それらの前にparent::を付けることで祖先関数にアクセスできます。

 class WorkerPerson extends Person { protected $occupation; public function __construct($name, $occupation) { parent::__construct($name); $this->occupation = $occupation; } public function getIntroduction() { return sprintf( __('%s and my occupation is %s'), parent::getIntroduction(), $this->occupation ); } } $worker = new WorkerPerson('Pedro', 'web development'); echo $worker->getIntroduction(); // This prints "My name is Pedro and my occupation is web development"

メソッドはabstractできます。つまり、継承するクラスによって実装する必要があります。 abstractメソッドを含むクラスは、それ自体をabstract化する必要があります。つまり、インスタンス化することはできません。 抽象メソッドを実装するクラスのみをインスタンス化できます。

 abstract class Person { abstract public function getName(); public function getIntroduction() { return sprintf( __('My name is %s'), $this->getName() ); } } // Person cannot be instantiated class Manuel extends Person { public function getName() { return 'Manuel'; } } // Manuel can be instantiated $manuel = new Manuel();

クラスはstaticメソッドとプロパティを定義することもできます。これらはクラス自体の下にあり、オブジェクトとしてのクラスのインスタンス化の下にはありません。 これらは、 self::を介して、クラス内から、およびクラスの名前+ ::を介して、クラスの外部からアクセスされます。

 class Factory { protected static $instances = []; public static function registerInstance($handle, $instance) { self::$instances[$handle] = $instance; } public static function getInstance($handle) { return self::$instances[$handle]; } } $engine = Factory::getInstance('Engine');

OOPを最大限に活用するために、SOLIDの原則を使用して、アプリケーションの健全でありながら簡単にカスタマイズ可能な基盤を確立し、パターンを設計して、実証済みの方法で特定の問題を解決できます。 デザインパターンは標準化され、十分に文書化されているため、開発者はアプリケーション内のさまざまなコンポーネントが互いにどのように関連しているかを理解し、グローバル変数（ global $wpdbなど）の使用を回避するのに役立つ規則的な方法でアプリケーションを構造化する方法を提供できます。地球環境を汚染します。

名前空間

名前空間はPHP5.3に追加されたため、現在WordPressコアから完全に欠落しています。

名前空間を使用すると、コードベースを構造的に編成して、異なるアイテムが同じ名前の場合の競合を回避できます。オペレーティングシステムのディレクトリと同様に、異なるディレクトリに保存されている限り、同じ名前の異なるファイルを使用できます。 名前空間は、PHPアイテム（クラス、特性、インターフェイスなど）に対して同じカプセル化トリックを実行し、異なる名前空間に配置することで、異なるアイテムが同じ名前を持つ場合の衝突を回避します。

サードパーティのライブラリとやり取りする場合、名前空間は必須です。アイテムの名前を制御できないため、アイテムに「ファイル」、「ロガー」、「アップローダー」などの標準名を使用すると、衝突が発生する可能性があります。 さらに、単一のプロジェクト内であっても、名前空間は、他のクラスとの衝突を回避するためにクラス名が極端に長くなるのを防ぎ、「MyProject_Controller_FileUpload」などの名前になる可能性があります。

名前空間は、キーワードnamespace （開始<?phpの直後の行に配置）を使用して定義され、 \ ：を使用して区切られた複数のレベルまたはサブ名前空間（ファイルを配置する複数のサブディレクトリを持つのと同様）にまたがることができます。

 <?php namespace CoolSoft\ImageResizer\Controllers; class ImageUpload { }

上記のクラスにアクセスするには、名前空間を含む（そして\で始まる）名前を完全に修飾する必要があります。

 $imageUpload = new \CoolSoft\ImageResizer\Controllers\ImageUpload();

または、クラスを現在のコンテキストにインポートしてから、その名前でクラスを直接参照することもできます。

 use CoolSoft\ImageResizer\Controllers\ImageUpload; $imageUpload = new ImageUpload();

確立された規則に従って名前空間に名前を付けることにより、追加の利点を得ることができます。 たとえば、PHP Standards Recommendation PSR-4に従うことで、アプリケーションはComposerの自動ロードメカニズムを使用してファイルをロードできるため、複雑さが軽減され、依存関係間の相互運用性がスムーズになります。 この規則では、ベンダー名（会社名など）を最上位のサブネームスペースとして含め、オプションでパッケージ名を続け、その後に各サブネームスペースが同じ名前のディレクトリに対応する内部構造を含めるようにしています。 結果は、ファイルで定義された要素の名前空間を使用して、ドライブ内のファイルの物理的な場所を1対1でマップします。

特性

トレイトはPHP5.4に追加されたため、現在WordPressコアから完全に欠落しています。

PHPは単一の継承をサポートしているため、サブクラスは複数のクラスからではなく、単一の親クラスから派生します。 したがって、相互に拡張しないクラスは、クラスの継承を通じてコードを再利用できません。 トレイトは、動作の水平方向の構成を可能にするメカニズムであり、異なるクラス階層に存在するクラス間でコードを再利用できるようにします。

トレイトはクラスに似ていますが、それ自体でインスタンス化することはできません。 代わりに、トレイト内で定義されたコードは、コンパイル時に作成クラスに「コピーされて貼り付けられる」と考えることができます。

トレイトはtraitキーワードを使用して定義され、その後、 useキーワードを使用して任意のクラスにインポートできます。 以下の例では、2つの完全に無関係なクラスPersonとShopが、トレイトAddressableを介して同じコードを再利用できます。

 trait Addressable { protected $address; public function getAddress() { return $this->address; } public function setAddress($address) { $this->address = $address; } } class Person { use Addressable; } class Shop { use Addressable; } $person = new Person('Juan Carlos'); $person->setAddress('Obelisco, Buenos Aires');

クラスは、複数の特性を構成することもできます。

 trait Exportable { public class exportToCSV($filename) { // Iterate all properties and export them to a CSV file } } class Person { use Addressable, Exportable; }

トレイトは、他のトレイトで構成したり、抽象メソッドを定義したり、2つ以上の構成されたトレイトが同じ機能名を持つ場合に競合解決メカニズムを提供したりすることもできます。

インターフェース

インターフェイスはPHP5に追加されたため、WordPressはすでにこの機能を利用していますが、非常に控えめです。コアに含まれるインターフェイスは合計で10未満です。

インターフェイスを使用すると、実装する必要のあるメソッドを指定するコードを作成できますが、これらのメソッドが実際にどのように実装されるかを定義する必要はありません。 これらは、コンポーネント間のコントラクトを定義するのに役立ちます。これにより、アプリケーションのモジュール性と保守性が向上します。インターフェイスを実装するクラスは、コードのブラックボックスになる可能性があり、インターフェイス内の関数の署名が変更されない限り、コードは、重大な変更を加えることなく自由にアップグレードできます。これにより、技術的負債の蓄積を防ぐことができます。 さらに、一部のインターフェイスの実装を別のベンダーの実装に交換できるようにすることで、ベンダーロックインを減らすのに役立ちます。 結果として、実装ではなくインターフェースに対してアプリケーションをコーディングすることが不可欠です（そして、依存性注入によって実際の実装がどれであるかを定義します）。

インターフェイスはinterfaceキーワードを使用して定義され、メソッドのシグネチャのみをリストする必要があります（つまり、コンテンツを定義せずに）。これは、可視性をpublicする必要があります（デフォルトでは、可視性キーワードを追加しないと公開されます）。

 interface FileStorage { function save($filename, $contents); function readContents($filename); }

クラスは、 implementsキーワードを介してインターフェースを実装することを定義します。

 class LocalDriveFileStorage implements FileStorage { function save($filename, $contents) { // Implement logic } function readContents($filename) { // Implement logic } }

クラスは複数のインターフェースを実装でき、それらを, ：で区切ります。

 interface AWSService { function getRegion(); } class S3FileStorage implements FileStorage, AWSService { function save($filename, $contents) { // Implement logic } function readContents($filename) { // Implement logic } function getRegion() { return 'us-east-1'; } }

インターフェイスは、コンポーネントが実行することになっていることの意図を宣言するため、インターフェイスに適切な名前を付けることが非常に重要です。

クロージャ

クロージャはPHP5.3に追加されたため、現在WordPressコアから完全に欠落しています。

クロージャは無名関数を実装するためのメカニズムであり、使い捨て（またはめったに使用されない）関数からグローバル名前空間を整理するのに役立ちます。 技術的に言えば、クロージャはクラスClosureのインスタンスですが、実際には、害を及ぼすことなく、この事実に幸いにも気付かない可能性があります。

クロージャの前に、関数を引数として別の関数に渡すときは常に、関数を事前に定義し、その名前を引数として渡す必要がありました。

 function duplicate($price) { return $price*2; } $touristPrices = array_map('duplicate', $localPrices);

クロージャーを使用すると、匿名（つまり名前のない）関数をパラメーターとして直接渡すことができます。

 $touristPrices = array_map(function($price) { return $price*2; }, $localPrices);

クロージャは、 useキーワードを使用して変数をコンテキストにインポートできます。

 $factor = 2; $touristPrices = array_map(function($price) use($factor) { return $price*$factor; }, $localPrices);

ジェネレーター

ジェネレーターはPHP5.5に追加されたため、現在WordPressコアから完全に欠落しています。

ジェネレーターは、単純なイテレーターを実装する簡単な方法を提供します。 ジェネレーターを使用すると、メモリ内に配列を作成しなくても、 foreachを使用してデータセットを反復処理するコードを記述できます。 ジェネレーター関数は通常の関数と同じですが、1回返す代わりに、繰り返される値を提供するために必要な回数だけyieldできる点が異なります。

 function xrange($start, $limit, $step = 1) { for ($i = $start; $i <= $limit; $i += $step) { yield $i; } } foreach (xrange(1, 9, 2) as $number) { echo "$number "; } // This prints: 1 3 5 7 9

引数と戻り値の型の宣言

PHPのさまざまなバージョンでさまざまな引数型の宣言が導入されました：WordPressはすでにインターフェイスと配列を宣言できます（これはできません：コアのパラメーターとして配列を宣言する関数のインスタンスはほとんど見つかりませんでしたが、インターフェイスはありません）。すぐに呼び出し可能配列（PHP 5.4で追加）とスカラー型（bool、float、int、string（PHP 7.0で追加））を宣言できるようになります。 戻り型の宣言がPHP7.0に追加されました。

引数型の宣言により、関数は引数がどの特定の型でなければならないかを宣言できます。 検証は呼び出し時に実行され、引数の型が宣言されたものでない場合は例外をスローします。 戻り型の宣言は同じ概念ですが、関数から返される値の型を指定します。 型宣言は、関数の意図を理解しやすくし、ランタイムエラーが予期しない型を受信または返すことを回避するのに役立ちます。

引数の型は引数変数名の前に宣言され、戻り型は引数の後に宣言され、前に:が付きます。

 function foo(boolean $bar): int { }

スカラー引数型の宣言には、強制と厳密の2つのオプションがあります。 強制モードでは、間違ったタイプがパラメーターとして渡された場合、それは正しいタイプに変換されます。 たとえば、文字列を期待するパラメータに整数が与えられた関数は、文字列型の変数を取得します。 厳密モードでは、宣言の正確なタイプの変数のみが受け入れられます。

強制モードがデフォルトです。 strictモードを有効にするには、 strict_types宣言で使用されるdeclareステートメントを追加する必要があります。

 declare(strict_types=1); function foo(boolean $bar) { }

新しい構文と演算子

WordPressは、関数func_num_argsを介して可変長引数リストをすでに識別できます。 PHP 5.6以降では、 ...トークンを使用して、関数が可変数の引数を受け入れることを示すことができます。これらの引数は、指定された変数に配列として渡されます。

 function sum(...$numbers) { $sum = 0; foreach ($numbers as $number) { $sum += $number; } return $sum; }

PHP 5.6以降、定数には、静的な値だけでなく、数値リテラルと文字列リテラル、および配列を含むスカラー式を含めることができます。

 const SUM = 37 + 2; // A scalar expression const LETTERS = ['a', 'b', 'c']; // An array

PHP 7.0以降では、 define ：を使用して配列を定義することもできます。

 define('LETTERS', ['a', 'b', 'c']);

PHP 7.0では、Null合体演算子（ ?? ）とSpaceship演算子（ <=> ）の2つの新しい演算子が追加されました。

ヌル合体演算子?? isset（）と組み合わせて三項を使用する必要がある一般的なケースの構文糖衣です。 存在し、NULLでない場合は、最初のオペランドを返します。 それ以外の場合は、2番目のオペランドを返します。

 $username = $_GET['user'] ?? 'nobody'; // This is equivalent to: // $username = isset($_GET['user']) ? $_GET['user'] : 'nobody';

宇宙船演算子<=>は、2つの式を比較するために使用され、最初のオペランドがそれぞれ2番目のオペランドよりも小さい、等しい、または大きい場合に-1、0、または1を返します。

 echo 1 <=> 2; // returns -1 echo 1 <=> 1; // returns 0 echo 2 <=> 1; // returns 1

これらは、バージョン5.3から7.0にまたがるPHPに追加された最も重要な新機能です。 この記事に記載されていない追加の新機能のリストは、バージョンからバージョンへの移行に関するPHPのドキュメントを参照することで入手できます。

次に、これらすべての新機能を最大限に活用し、Web開発の最近の傾向から、より優れたソフトウェアを作成する方法を分析します。

PHP標準の推奨事項

PHP Standards Recommendationsは、人気のあるフレームワークとライブラリのPHP開発者のグループによって作成され、さまざまなプロジェクトをよりシームレスに統合し、さまざまなチームが相互に連携できるように規則を確立しようとしています。 推奨事項は静的ではありません。既存の推奨事項は廃止され、代わりに新しい推奨事項が作成される可能性があり、新しい推奨事項は継続的にリリースされます。

現在の推奨事項は次のとおりです。

コンポーネントで考えてコーディングする

コンポーネントを使用すると、フレームワーク自体に固定されることなく、フレームワークの最高の機能を使用できます。 たとえば、Symfonyは、Symfonyフレームワークとは独立してインストールできる再利用可能なPHPコンポーネントのセットとしてリリースされています。 別のPHPフレームワークであるLaravelは、いくつかのSymfonyコンポーネントを利用し、任意のPHPプロジェクトで使用できる独自の再利用可能なコンポーネントのセットをリリースしました。

これらのコンポーネントはすべて、パブリックPHPパッケージのリポジトリであるPackagistで公開されており、PHPの非常に人気のある依存関係マネージャーであるComposerを介して任意のPHPプロジェクトに簡単に追加できます。

WordPressは、このような好循環の一部である必要があります。 残念ながら、WordPressコア自体はコンポーネントを使用して構築されておらず（インターフェイスがほぼ完全にないことからも明らかです）、さらに、Composerを介してWordPressをインストールできるようにするために必要なcomposer.jsonファイルさえありません。 これは、WordPressコミュニティが、WordPressがサイトの依存関係であるか（この場合、Composerを介してインストールすることが正当化される）、またはそれがサイト自体であるか（この場合、Composerがジョブに適したツールではない可能性がある）について合意していないためです。 。

私の意見では、WordPressが今後15年間（少なくともバックエンドCMSとしてのWordPressとして）関連性を維持することを期待する場合、 WordPressはサイトの依存関係として認識され、Composerを介してインストールできるようにする必要があります。 理由は非常に単純です。ターミナルでコマンドを1つだけ使用するだけで、Composerは、Packagistで公開されている数千のパッケージからプロジェクトの依存関係を宣言してインストールできるため、非常に強力なPHPアプリケーションを短時間で作成できます。このように働いています。 WordPressがこのモデルに適応しない場合、Gitベースのデプロイメントの導入後にFTPが支持されなくなったのと同じように、開発コミュニティからのサポートを失い、忘却に陥る可能性があります。

Gutenbergのリリースは、WordPressがサイト自体ではなくサイトの依存関係であることをすでに示していると主張します。GutenbergはWordPressをヘッドレスCMSとして扱い、Drupal Gutenbergが例示するように、他のバックエンドシステムでも動作できます。 したがって、グーテンベルクは、サイトに電力を供給するCMSは交換可能である可能性があることを明確にしています。したがって、それは依存関係として扱われる必要があります。 さらに、Gutenberg自体はnpmを通じてリリースされたJavaScriptコンポーネントに基づくことを目的としているため（コアコミッショナーのAdam Silversteinが説明）、WordPressクライアントがnpmパッケージマネージャーを介してJavaScriptパッケージを管理することが期待される場合は、このロジックをComposerを介してPHPの依存関係を管理するためのバックエンド？

朗報です。WordPressをサイトの依存関係として扱い、Composerを介してインストールすることはすでに可能であるため、この問題が解決されるのを待つ必要はありません。 John P. BlochはGitでWordPressコアをミラーリングし、composer.jsonファイルを追加して、Packagistでリリースしました。また、RootsのBedrockは、最新の開発ツールと強化されたセキュリティをサポートするカスタマイズされたフォルダー構造でWordPressをインストールするパッケージを提供します。 また、テーマとプラグインについても説明します。 WordPressテーマとプラグインのディレクトリにリストされている限り、WordPressPackagistで利用できます。

結果として、テーマやプラグインの観点から考えるのではなく、コンポーネントの観点から考えて、Packagistを介してPHPプロジェクトで使用できるようにし、さらにテーマとしてパッケージ化してリリースするWordPressコードを作成することは賢明なオプションです。 WordPressの特定の使用のためのプラグイン。 コンポーネントがWordPressAPIと対話する必要がある場合、これらのAPIは、必要に応じて他のCMSにも実装できるインターフェイスの背後で抽象化できます。

ビューレイヤーを改善するためのテンプレートエンジンの追加

コンポーネントの考え方とコーディングの推奨事項に従い、WordPressをサイト自体以外のサイトの依存関係として扱うと、プロジェクトはWordPressによって課せられた境界から解放され、他のフレームワークから取得したアイデアやツールをインポートできます。

サーバー側でのHTMLコンテンツのレンダリングはその好例であり、これはプレーンなPHPテンプレートを介して行われます。 このビューレイヤーは、テンプレートエンジンTwig（Symfonyによる）とBlade（Laravelによる）を介して拡張できます。これらは、非常に簡潔な構文と強力な機能を提供し、プレーンなPHPテンプレートよりも優れています。 特に、Gutenbergの動的ブロックは、サーバー側でブロックのHTMLをレンダリングするプロセスが、WordPressのテンプレート階層アーキテクチャから切り離されているため、これらのテンプレートエンジンから簡単に恩恵を受けることができます。

一般的な使用のためのアプリケーションの設計

インターフェイスに対してコーディングし、コンポーネントの観点から考えることで、プロジェクトごとに特定の用途のためにコーディングするのではなく、一般的な用途向けにアプリケーションを設計し、提供する必要のある特定の用途に合わせてアプリケーションをカスタマイズできます。 このアプローチは短期的にはコストがかかりますが（余分な作業が必要です）、汎用アプリケーションをカスタマイズするだけで、より少ない労力で追加のプロジェクトを提供できる場合、長期的には効果があります。

このアプローチを効果的にするには、次の考慮事項を考慮する必要があります。

固定依存関係を回避する（可能な限り）

jQueryとBootstrap（またはFoundation、または<–お気に入りのライブラリをここに挿入–> ）は、数年前には必須と見なされていた可能性がありますが、バニラJSや新しいネイティブCSS機能に対して着実にその地位を失っています。 したがって、これらのライブラリに依存していた5年前にコーディングされた汎用プロジェクトは、現在では適切ではない可能性があります。 したがって、一般的な経験則として、サードパーティライブラリへの固定依存関係の量が少ないほど、長期的には最新であることが証明されます。

機能のプログレッシブエンハンスメント

WordPressはユーザー管理を含む本格的なCMSシステムであるため、ユーザー管理のサポートはすぐに利用できます。 ただし、すべてのWordPressサイトでユーザー管理が必要なわけではありません。 したがって、アプリケーションはこれを考慮に入れ、各シナリオで最適に機能する必要があります。必要に応じてユーザー管理をサポートしますが、そうでない場合は対応するアセットをロードしないでください。 このアプローチも徐々に機能します。クライアントがお問い合わせフォームを実装する必要があるが予算がないため、機能が制限された無料のプラグインを使用してコーディングし、別のクライアントが商用プラグイン製品からライセンスを購入する予算があるとします。より良い機能。 次に、機能をデフォルトで非常に基本的な機能にコーディングし、システムで利用可能な最も機能的なプラグインの機能をますます使用することができます。

継続的なコードとドキュメントのレビュー

以前に作成したコードとそのドキュメントを定期的に確認することで、新しい規則やテクノロジーに関して最新であるかどうかを検証し、最新でない場合は、技術的負債が高額になって克服できない前にアップグレードするための対策を講じることができます。そして、最初からもう一度コーディングする必要があります。

おすすめの読み物：注意してください：サイトを安全でないものにする可能性のあるPHPおよびWordPress関数

問題を最小限に抑えることを試みますが、問題が発生したときに備えてください

100％完璧なソフトウェアはありません。バグは常に存在しますが、まだ発見されていません。 そのため、問題が発生したら、簡単に修正できるようにする必要があります。

それを簡単に

複雑なソフトウェアを長期的に維持することはできません。他のチームメンバーがそれを理解できないだけでなく、それをコーディングした人が数年後に自分の複雑なコードを理解できない可能性があるためです。 したがって、単純なソフトウェアだけが正しく高速であるため、単純なソフトウェアの作成を優先する必要があります。

コンパイル時の失敗は実行時よりも優れています

コードの一部をコンパイル時または実行時のいずれかでエラーに対して検証できる場合は、コンパイル時のソリューションを優先する必要があります。これにより、エラーが発生し、開発段階でアプリケーションが本番環境に到達する前に処理できるようになります。 たとえば、定数の定義にはconstとdefineの両方が使用されますが、 constはコンパイル時に検証されますが、 defineは実行時に検証されます。 したがって、可能な限り、 defineよりもconstを使用することをお勧めします。

この推奨事項に従って、クラスに含まれるWordPress関数のフックは、クラス名の文字列ではなく、実際のクラスをパラメーターとして渡すことで拡張できます。 以下の例では、クラスFooの名前が変更され、2番目のフックがコンパイルエラーを生成する場合、最初のフックは実行時に失敗するため、2番目のフックの方が優れています。

 class Foo { public static function bar() { } } add_action('init', ['Foo', 'bar']); // Not so good add_action('init', [Foo::class, 'bar']); // Much better

上記と同じ理由で、グローバル変数（ global $wpdbなど）の使用は避ける必要があります。これらはグローバルコンテキストを汚染するだけでなく、元の場所を追跡するのも簡単ではありません。また、名前が変更されると、エラーが発生します。実行時に生成されます。 解決策として、依存性注入コンテナを使用して、必要なオブジェクトのインスタンスを取得できます。

エラー/例外への対処

Exceptionオブジェクトのアーキテクチャを作成して、アプリケーションが特定の問題ごとに適切に対応し、可能な場合はいつでも問題から回復するか、そうでない場合はユーザーに役立つエラーメッセージを表示し、一般にエラーをログに記録できるようにします。問題を修正するための管理者。 そして、常にユーザーを死の白い画面から保護します。キャッチされなかったすべてのErrorとExceptionは、関数set_exception_handlerを介してインターセプトされ、怖くないエラーメッセージを画面に出力できます。

ビルドツールを採用する

ビルドツールは、手動で実行するのが非常に面倒なタスクを自動化することで、多くの時間を節約できます。 WordPressは特定のビルドツールとの統合を提供していないため、これらをプロジェクトに組み込む作業は完全に開発者に委ねられます。

さまざまな目的を達成するためのさまざまなツールがあります。 たとえば、画像の圧縮とサイズ変更、JSファイルとCSSファイルの縮小、リリースを作成するためのディレクトリへのファイルのコピー（Webpack、Grunt、Gulpなど）のタスクを実行するビルドツールがあります。 他のツールは、プロジェクトの足場を作成するのに役立ちます。これは、Yeomanなどのテーマまたはプラグインのフォルダー構造を作成するのに役立ちます。 実際、非常に多くのツールが使用されているため、利用可能なさまざまなツールを比較する記事を参照すると、ニーズに最も適したツールを見つけるのに役立ちます。

ただし、プロジェクトに必要なものを正確に実現できるビルドツールがない場合もあるため、プロジェクト自体の拡張として独自のビルドツールをコーディングする必要があります。 たとえば、WordPressでService Workerのサポートを追加するために、service-worker.jsファイルを生成するためにこれを行いました。

結論

下位互換性を維持することに重点を置いており、PHP 5.2.4まで拡張されているため、WordPressはPHPに追加された最新機能の恩恵を受けることができませんでした。この事実により、WordPressはコーディングにとってそれほどエキサイティングなプラットフォームになりませんでした。多くの開発者の間で。

幸いなことに、これらの悲観的な時代はもうすぐ終わり、WordPressは再びコーディングするための光沢のあるエキサイティングなプラットフォームになる可能性があります：2019年12月から始まるPHP 7.0+の要件により、多くのPHP機能が利用可能になり、開発者はより強力でよりパフォーマンスの高いソフトウェア。 この記事では、新しく利用可能になった最も重要なPHP機能と、それらを最大限に活用する方法について説明しました。

グーテンベルクの最近のリリースは、これからの良い時期の兆候かもしれません。グーテンベルク自体がコミュニティに完全に受け入れられていなくても、少なくとも最新のテクノロジー（ReactやWebpackなど）をコアに組み込む意欲を示しています。 。 この一連の出来事は私に不思議に思います：フロントエンドがそのような変身を得ることができるなら、なぜそれをバックエンドに拡張しませんか？ WordPressが少なくともPHP7.0を必要とするようになると、最新のツールと方法論へのアップグレードが加速する可能性があります。npmが選択されたJavaScriptパッケージマネージャーになったのと同じくらい、Composerを公式のPHP依存関係マネージャーにしないのはなぜですか。 ブロックがフロントエンドでサイトを構築するための新しいユニットである場合、機能をバックエンドに組み込むためのユニットとしてPHPコンポーネントを使用してみませんか？ そして最後に、GutenbergがWordPressをスワップ可能なバックエンドCMSとして扱う場合、WordPressがサイト自体ではなく、サイトの依存関係であることをすでに認識していないのはなぜですか？ 私はあなたが熟考し、熟考するためにこれらの未解決の質問を残しておきます。