WordPressでComposerを使用する

WordPressは2003年から存在しており、Webサイトを始めようとしているほとんどの人にとってデフォルトのツールになっています。 ブログエンジンとしてのルーツからは長い道のりを歩んできましたが、基盤となるテクノロジーは、ユーザーエクスペリエンスと同じ飛躍を遂げていません。

WordPressの開発は、2003年に存在した多くの標準を中心に展開されています。これにより、必要な技術的理解が低くなるため、人々がアクセスしやすくなりますが、多くの新しい開発リソースは、そのままではWordPressと互換性がありません。

今日は、Composerと呼ばれる新しいツールの1つを見ていきます。 それがWordPressワークフローにどのように適合するかを見て、なぜそれを試してみたいのかを議論しましょう。

Composerとは何ですか？

作成するコードのすべてのビットには依存関係があります。 WordPressプラグインを作成している場合、最大の依存関係はWordPress自体です。 WordPressが提供するコア機能がなければ、プラグインはまったく役に立たない可能性があります。 WordPress自体の外では、SOAPベースのAPIとインターフェイスするためにnusoapのような最新のSOAPクライアントが必要になる可能性があります。

以前は、ほとんどの人はnusoapのリポジトリをプラグインのディレクトリにコピーしてから、ライブラリを使用するために必要なファイルを含めるだけでした。 これは、Composerが介入して、依存関係の管理の一部を簡素化できる場所です。

Composerは依存関係マネージャーです。 依存関係のインストールと管理を容易にするように特別に設計されています。 これは、チームで作業していて、チームのすべてのメンバーが開発作業と同じライブラリを使用していることを確認したい場合に特に重要になる可能性があります。

基本的に、Composerは、インストールした依存関係と使用する依存関係のバージョンを詳細に記述したJSONファイルです。 nusoap依存関係を含む基本的な例を以下に示します。

{{

"必要とする"： {

「econea/nusoap」：「^0.9.10」

}

}

プラグインでcomposerrequireeconea / nusoapを実行すると、nusoapがインストールされ、指定されたバージョンにロックされます。 この場合、私は0.9.10を使用しており、Composerに依存関係をアップグレードするように指示しない限り、これを引き続き使用します。

これには、単にnusoapをダウンロードして含めるよりも利点があります。これは、composer updateを使用して、更新があるかどうかを確認してプロジェクトに手動でダウンロードしなくても、すべての依存関係を更新できるためです。 Composerは、このレベルでリソースの管理を引き継ぎます。

Composer入門

composerのインストールはかなり簡単です。

Windowsの場合

Windowsを使用している場合は、プロセスを簡素化するためのインストーラーが提供されています。 最新バージョンのComposerがインストールされ、プロジェクトからグローバルにアクセスできるようになります。

Linux / Unix / macOS

これらのプラットフォームのいずれでも、Composerをセットアップするための手順がさらにいくつかあります。 開始するには、Composerをダウンロードしてセットアップするために必要なコマンドを実行します。

php -r“ copy（'https://getcomposer.org/installer'、'composer-setup.php'）;”

php -r“ if（hash_file（'sha384'、'composer-setup.php'）=== '756890a4488ce9024fc62c56153228907f1545c228516cbf63f885e036d37e9a59d27d63f46af1d4d07ee0f76181c7d3'）{echo'インストーラー検証済み'; } else{echo'インストーラーが破損しています'; unlink（'composer-setup.php'）; }echoPHP_EOL;」

phpcomposer-setup.php

php -r“ unlink（'composer-setup.php'）;”

次に、ローカル開発のためにComposerをグローバルに実行する必要があるため、Composerを使用するときにいつでも使用できるように、デフォルトのインストールを調整する必要があります。 Composerをダウンロードしたのと同じディレクトリから次のコマンドを実行すると、Composerをグローバルに使用できるように移動できます。

mv composer.phar / usr / local / bin / composer

Composerのアップグレード

WindowsとmacOSでは、Composerの最新バージョンにアップグレードするために必要なのは、composerの自己更新を実行することだけです。 Linux / Unixを使用している場合は、sudo apt update && upgradeを実行して、システムが最新バージョンをチェックしてから、composerself-updateを実行して最新バージョンを取得する必要があります。

セットアップが完了したので、Composerを使用してWordPressをインストールする方法を見てみましょう。

ComposerでWordPressをインストールする

Composerを使用してサイト全体を管理する場合はどうでしょうか。 まず、WordPressがプロジェクトの依存関係なのか、プロジェクトのコアなのかを判断する必要がありますか？ うん、少し脳をねじる。

顧客の最終目標はWordPressをインストールすることではないため、WordPressはプロジェクトの依存関係と見なすことができます。 彼らは店やブログを望んでおり、それはあなたがWordPressをインストールするかどうかに依存します。 これは、RootsのようなプロジェクトがBedrockと呼ばれるComposerベースのBedrockWordPressセットアップで採用しているスタンスです。

Bedrockを使用すると、WPackagistはすでに設定されているため、Composerに通知する必要がありません。 Composerを使用してサイト全体を管理する場合は、ここから始めることをお勧めします。

Bedrockをインストールするには、次のコマンドを実行します。

作曲家の作成-プロジェクトのルーツ/岩盤

これにより、次のファイル構造が得られます。

├──composer.json

├──.env

├──設定

│├──application.php

│└──環境

│├──development.php

│├──staging.php

│└──production.php

├──ベンダー

└──ウェブ

├──アプリ

│├──mu-プラグイン

│├──プラグイン

│├──テーマ

│└──アップロード

├──wp-config.php

├──index.php

└──wp

これは、標準のWordPressセットアップとは大きく異なります。 開始するには、インストールのルートにcomposer.jsonファイルがあります。 ここに、Composerの構成が表示されます。

.envファイルは、さまざまなデータベース構成を保存できる場所です。 これが必要なのは、ローカルサイトとライブサイトのデータベースのパスワードとユーザー名が異なるためです。 Bedrockはデータベース接続情報にハードコーディングする代わりにこれらの変数を使用するため、デフォルトのwp-config.phpファイルは.envファイルに入力した変数を理解します。

.envファイルはGitリポジトリでは無視する必要があります。 新しいサイトを構成するときは、必要なデータベース構成情報を含む新しい.envfileをサイトに追加します。

Bedrockを開始するためにここで設定する必要のある他のいくつかの変数があります。これらはすべて、ドキュメントで詳しく説明されています。

configフォルダーの下には、使用する環境のさまざまなデフォルト構成があります。 開発では、これによりエラーレポートがオンになり、本番環境では、エラーログがサイトの円滑な運用を妨げないようにします。

Bedrockをベースとして、Composerを使用してWPackagist経由でWordPressプラグインをインストールできるようになりました。

WPackagistは、WordPressテーマとプラグインリポジトリのミラーです。 これが必要なのは、デフォルトではほとんどのプラグインとテーマをComposerでインストールできないためです。 ミラーは、Composerを使用してプラグインを管理できるように、各プラグインに必要なファイルを追加します。

BedrockベースのWordPressインストールにWooCommerceをインストールする場合は、最初にWooCommerceを要求する必要があり、composerはwpackagist-plugin / woocommerceを要求し、次にComposerに依存関係をインストールするように指示する必要があります。

これで、WordPressインストールの管理エリアに移動してWooCommerceをアクティブ化し、サイトを構築することができます。 新しいバージョンがリリースされたときにWooCommerceを更新する、またはWordPressを更新するには、composerupdateを実行する必要があります。

これは、Composerベースのプロジェクトが少し問題になる可能性がある場所です。 WordPress管理者を介して更新を実行すると、Composerが期待するものとWordPressがインストールしたものとの間に不一致が生じます。 Composerを使用する場合は、Composerを更新ツールとして使用し続け、WordPress管理者を介して作業しないでください。

いつComposerを使用する必要がありますか？

なぜComposerがWordPress開発のための素晴らしいツールなのかと多くの人が質問していると思います。 WordPressはComposerを念頭に置いて構築されていないため、WordPressを操作するには、いくつかのフープを飛び越えてうまく機能させる必要があります。

プラグインとテーマの開発者にとって、Composerを使用すると、より広いPHPエコシステムから取り込む必要のある依存関係を簡単に処理できるという明確なケースがあります。 WordPress開発者にとって、議論はあまり明確ではありません。 Rootsと同じように、Composerを使用してサイト全体を管理することを好む人もいます。 これにより、Gitで管理するファイルの数を減らすことができますが、それは私にとって説得力のあるケースのようには思えませんでした。

私が気に入っているのは、Composerを使用すると、環境ごとに異なる依存関係を簡単に設定できることです。 その後、デプロイメントプロセスを使用して、これらの依存関係を環境にデプロイでき、手動で管理する必要はありません。

開発者は、クライアントのニーズも考慮する必要があります。 サイトを長期的に管理するための開発チームがいない場合は、非標準のWordPressインストールで問題が発生する可能性があります。 場合によっては、ホストは、WordPressをインストールして使用する通常の方法を使用していないため、サポートが利用できないことを通知することがあります。 クライアントにサービスを提供するときは、使用するクールなテクノロジーと、クライアントが長期的に処理できるテクノロジーとのバランスを常にとる必要があります。

この理由だけで、私はフルサイトプロジェクトでComposerを使用していません。 私のクライアントは何年にもわたって日々それらを管理するつもりであり、私は余分な障壁を設けたくありません。 私たちは両方とも、彼らのサイトが今後何年にもわたってスムーズに運営されることを望んでいます。

PHPスキルを最新のテクノロジーでアップグレードすることを検討している場合は、ComposerがWordPressワークフローにどのように適合するかを確認する必要があります。