Composer を使用して WordPress をインストールする方法: ステップ バイ ステップ インストール ガイド
公開: 2023-02-28はじめに: なぜ Composer ベースの WordPress なのか?
他のアプリケーションと同様に、コードとその依存関係に対して反復可能なビルドとコミット可能な更新を保証できる場合、WordPress サイトは最も安全です。 インフラストラクチャは、使用する PHP と MariaDB のバージョンを指定する一連の構成ファイルを通じてコミットされます。 これは、新しい機能を開発するときにプロジェクトの再現性を維持するための最良の方法です。
WordPress コア、およびそのテーマとプラグインは、理想的には同じように動作するはずですが、多くの場合、そうではありません。 WordPress の管理パネルには、これらすべてのコンポーネントが古くなった場合や、実行時に構成を変更するためにファイル システムへの書き込みアクセスが必要な場合に、これらすべてのコンポーネントを更新するためのワンクリック ボタンが用意されています。 ただし、この方法で開発すると、結果が生じます。
まず、実行時に常にファイル システムへの書き込みアクセス権があるとは限りません。 そのため、更新と構成の変更をこのメカニズムに依存することは、多くのホスティング ソリューションで完全に制限されています。 一方、現在ホストしている実行時に書き込みアクセス権を持っている場合、新しいモジュールまたはテーマをインストールすると、重要なセキュリティ リスクが発生します (ソースが不明な場合)。
しかし、おそらく最も重要なことは、実行時に WordPress を更新すると、サイトの状態がリポジトリ内のコードから切り離されることです。 プロジェクトのローカル クローンで新機能に取り組んでいる同僚は、ライブ サイトの背後にあるフル バージョンである可能性が非常に高いです。 このワークフローの結果、未知の (そしてテストされていない) 結果を伴うバグが発生する可能性があります。
Composer を使用する利点
上記の事実を考えると、Composer で WordPress サイトを管理することには明らかな利点があります。 まず、コミットされたファイル (composer.lock) で依存関係を明示的に定義できます。 このロック ファイルは、依存関係がインストールされると、依存関係の制約 (composer.json) のよりわかりやすいリストから生成され、プロジェクトのコミット履歴の一部になります。 それ以降、新しいブランチは、依存関係の同一のコレクションから正確なコミット ハッシュまで機能します。 その時点で、誰がプロジェクトに貢献したか、どこにデプロイされたかは関係ありません。どこにいても同じコードです。
また、Composer を使用すると、多くの外部コードをリポジトリにコミットする必要がなくなります。 WordPress の場合、Composer を使用しない場合、通常、テーマのすべてのコードをコミットする必要があり、WordPress コアとプラグイン自体のコードも自分のプロジェクトにコミットする必要があります。 リポジトリが不必要に大きくなり、複製が遅くなるだけでなく、これらのコピーを更新することは、誰も対処する必要のないジャグリング行為になります。
Composer を使用すると、依存関係をプロジェクトに追加して更新し、正確なバージョンをロックして、新しい各ブランチが同じ更新を取得できるようにすることができます。 実行時にデプロイされたサイトで更新が実行されていた場合は、最初に git pull を実行することを忘れないでください。
Composer を使用した WordPress コアのインストール
同様に、Composer を使用すると、依存関係として追加できるため、すべての WordPress をリポジトリにコミットする必要がなくなります。 これを行う方法はいくつかありますが (Bedrock のように)、構成とプロジェクトの構造に必要な仮定の数に応じて異なります。 最も単純なものは、John Bloch Composer フォークを使用して、WordPress のビルドにインストーラーを追加します。
$ composer require johnpbloch/wordpress-core-installer $ composer require johnpbloch/wordpress-core
上記のコマンドは composer.json ファイルを作成し、WordPress コアを WordPress ディレクトリにインストールします。 composer.json は次のようになります。
{
"必須": {
"johnpbloch/wordpress-core-installer": "^2.0",
"johnpbloch/wordpress-core": "^6.1"
}、
"構成": {
"プラグインを許可": {
"johnpbloch/wordpress-core-installer": true
}
}
}
WordPress フォルダに WordPress コアがあります。 ただし、Web サーバーがルート ディレクトリを参照できるように、index.php を WordPress ディレクトリの外にコピーする必要があります。
Composer で WordPress を完全に管理するには、デフォルトの WordPress/wp-content ではなく、wp-content 用に別のディレクトリを使用する必要があります。
プロジェクトのルートに wp-content という新しいディレクトリを作成しましょう。
WordPress フォルダから index.php をコピーします。 WordPress ディレクトリがある wp-blog-header.php ファイルの場所を変更する必要があります。
変更後、index.php は次のようになります。
<?php
define('WP_USE_THEMES', true);
require( dirname( __FILE__ ) . '/wordpress/wp-blog-header.php' );
次の内容の .htaccess ファイルをルート ディレクトリに作成する必要があります。
# ワードプレスを始める
<IfModule mod_rewrite.c>
RewriteEngine オン
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# ワードプレス終了
サンプルの wp-config.php ファイルをコピーして、次のコードを追加してみましょう。
$domain = 'mydomain.com;
define('WP_SITEURL', "https://{$domain}/wordpress");
define('WP_HOME',"https://{$domain}");
$httpHost = isset($_SERVER['HTTPS_HOST']) ? $_SERVER['HTTPS_HOST'] : $ドメイン;
define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/wp-content' );
define( 'WP_CONTENT_URL', 'https://' . $httpHost . '/wp-content' );
/** WordPress ディレクトリへの絶対パス。 */
if ( !defined('ABSPATH') ) {
define('ABSPATH', dirname(__FILE__) .'/ワードプレス');
}
WordPress コアは /WordPress にあるため、ABSPATH に WordPress を追加しました。
wp-config.php ファイルには機密データが含まれているため、 .gitignore ファイルを作成してリポジトリにコミットしません。
/wp-config.php /ワードプレス/ /wp-コンテンツ/ /ベンダー/
WordPress、wp-content、および vendor ディレクトリも無視して、.gitignore ファイルにも追加する必要があります。
注: wp-content に別の命名規則を追加する場合は、wp-content ディレクトリを変更する必要があります。
プロジェクトのルート ディレクトリは次のようになります。
。ギット .gitignore composer.lock composer.json ベンダー wp-config.php index.php ワードプレス
データベースを作成し、wp-config.php の詳細を変更する必要があります。 WordPress Web サイトは「mydomain.com」で呼び出され、WordPress バックエンドは mydomain.com/wordpress/wp-admin からアクセスできます。
WordPress リポジトリからプラグインとテーマを追加する
デフォルトでは、Composer は packagist.org リポジトリのみを参照します。 ただし、WordPress のプラグインとテーマは含まれていません。
WordPress プラグインとテーマを取り込めるようにするには、Composer を wpackagist.org リポジトリに向ける必要があります。 これを行うには、この構成のチャンクを composer.json ファイルに追加します。

"リポジトリ": [
{
"タイプ": "作曲者",
"url": "https://wpackagist.org",
"それだけ": [
"wpackagist-plugin/*",
「wpackagist-theme/*」
]
}
]、
また、プラグインとテーマを配置する場所を Composer に伝える必要があります。 これには、もう少し構成を composer.json に追加する必要があります。
"追加": {
"インストーラパス": {
"wp-content/mu-plugins/{$name}/": [
「type:wordpress-muplugin」
]、
"wp-content/plugins/{$name}/": [
「タイプ:ワードプレスプラグイン」
]、
"wp-content/themes/{$name}/": [
「タイプ:ワードプレスのテーマ」
]
}
}
これで、WordPress のインストールで行ったように、composer require コマンドを使用して、公式リポジトリから任意のプラグインまたはテーマをインストールできるようになりました。
# プラグインをインストールするには、次の形式を使用します。
composer require "wpackagist-plugin/:"
# テーマをインストールするには、次の形式を使用します。
composer require "wpackagist-theme/:"
バージョンの制約は複雑ですが、おそらく最も覚えやすい形式は * ワイルドカードを使用することです。 バージョン 2.x を使用して WP Migrate プラグインの無料バージョンをインストールするには、次のコマンドを実行します。
composer require "wpackagist-plugin/wp-migrate-db:2.*"
アップデートで常に最新バージョンを取得したい場合は、バージョン制約として * を使用できます。
composer require "wpackagist-plugin/wp-migrate-db:*"
このようなコマンドを初めて実行すると、「「composer/installers」を信頼してコードを実行するかどうか」を尋ねられる場合があります。 これは安全に実行できますが、Composer がコンピューター上でコードを実行できることに注意してください。
すべてが順調であれば、プラグインをインストールする必要があります (ただし、有効化はされていません)。 この時点で変更を Git にコミットすることもお勧めします。
カスタムまたはサードパーティのプラグインとテーマの追加
リポジトリからプラグインとテーマが必要な場合は、これで問題ありません。 しかし、wordpress.org リポジトリにないサードパーティのプラグインや独自のカスタム コードを追加したい場合はどうすればよいでしょうか? WordPress ディレクトリは Git にはありません。では、自分のものをどのようにバージョン管理していますか?
一部のテーマおよびプラグイン作成者は、プラグインのカスタム リポジトリをサポートしています。
また、一部のテーマとプラグインは、プラグイン用のリポジトリを使用することを許可されていません (有料プラグインなど)。
しかし、それが当てはまらない場合、ここでの秘訣は、.gitignore ファイルを使用して特定のディレクトリを選択的に無視解除し、それらのカスタム プラグインとテーマを composer.json に追加することです。
これらのプラグインを別のディレクトリに配置して、composer.json からインストールすることもできます。
.gitignore の plugins フォルダーを無視しているため、dist という別のフォルダーを作成する必要があります。
dist には有料のカスタム プラグインがあり、Composer からインストールできます。
- 距離/
- プラグイン/
- テーマ/
- mu-プラグイン/
カスタム プラグインとテーマを適切なフォルダにコピーする必要があります。
そして、dist/plugins に追加されたプラグインごとに composer.json を作成する必要があります。
現在、有料のadvanced-custom-fields-proがあります。 また、ワンクリック インストールと展開の自動化のために、composer を介してそのプラグインを追加したいと考えています。
そのプラグインを作成者の Web サイト ポータルからダウンロードし、そのプラグインを dist/plugins/advanced-custom-fields-pro フォルダーに抽出する必要があります。 そして同じフォルダに composer.json を以下の内容で作成し、
{
"name": "custom-plugins/acf-pro",
"説明": "高度なカスタム フィールド PRO",
"バージョン": "5.12.2",
"type": "wordpress-plugin",
"必須": {
"作曲家/インストーラー": "^1.0",
"johnpbloch/wordpress-core": ">=5.4"
}
}ここで、カスタム プレフィックスを使用してバージョンと名前を追加できます。 そして、ルート composer.json ファイルにコードを追加して、インストール中にこのプラグインを呼び出します。
「リポジトリ」: セクションの最後に次のコードを追加します。
"リポジトリ": [
{
"タイプ": "パス",
"url": "dist/plugins/*",
"オプション": {
"シンボリックリンク": false
}リポジトリセクションには他のエントリもあります。 このプラグインをインストールするには、2 つの方法があります。最初に、プラグイン名とバージョンを
"必須": {
"カスタムプラグイン/acf-pro": ">=5.12.2"
}または、次のコマンドを実行すると、プラグインがインストールされ、上記のエントリが composer.json に追加されます。
$ composer require custom-plugins/acf-pro
同様に、テーマと mu プラグインをインストールできます。
テーマについては、テーマ フォルダの場所を追加する必要があります。
"リポジトリ": [
{
"タイプ": "パス",
"url": "dist/themes/*",
"オプション": {
"シンボリックリンク": false
}名前とバージョンの詳細を指定して、カスタム テーマに composer.json を追加する必要があります。 その名前を使用して、 composer require コマンドを使用してテーマをインストールできます。
結論は
Composer を使用することは、WordPress の安全性、最新性、再現性を確保するための最も効果的なアプローチです。 Composer を使用すると、開発者はプロジェクトの依存関係を簡単に追加および更新し、正確なバージョンをロックして、新しい各ブランチが同じコードで動作するようにすることができます。
これらの利点により、Composer は WordPress プロジェクトを管理するための優れた選択肢であり、反復可能なビルドとコミット可能な更新を保証します。
Composer の使用を開始するのは、少々圧倒される可能性があることを理解しています。 ご不明な点がございましたら、お気軽にお問い合わせください。 WordPress を最大限に活用していただくために、私たちはここにいます。
参考文献:
- https://docs.platform.sh/guides/wordpress/composer.html
- https://deliciousbrains.com/storing-wordpress-in-git/
- https://time2hack.com/composer-wordpress-deployment/
