🍤 👩‍🎓 🔫 composerを使用してCMSのモジュールを管理する 👩‍❤️‍💋‍👨 👩🏿‍🎤 🎴

こんにちは友人！ PHPで人気のある依存関係マネージャーの出現は、PHPコミュニティの生活の中で最も重要なイベントの1つです。 Composerは時間を「以前」に分けました。自己記述ライブラリがzipアーカイブにあるか、単にフォルダーに散らばって「ペン」でコピーされ、まれにgitまたはPEARが使用され、「あと」で作曲家を使用したときです。しかし、特定のCMSで作業しているが、作曲家が何であるかを「知らない」場合はどうでしょうか。

まえがき

私は小さなWebスタジオでチームリーダーとして働いており、約1年前、チームでベストプラクティスを使用するためのアプローチを再検討する必要がありました。機能の70％以上が標準（Webサイト、オンラインストア）と呼ばれるプロジェクトの開発には、1C-Bitrixを使用します。すべての一般的なCMS 1C-Bitrixと同様に、モジュール構造を持ち、サードパーティのモジュールのインストールをサポートします。良さそうに聞こえますが、実際には少し異なります。独自のモジュールを開発し、ソースコードを必要なフォルダーにコピーして、コントロールパネルでモジュールを1つずつインストールすることでアーカイブに保存するか、このために提供されている1C-Bitrix Marketplaceサイトでモジュールを公開できます。モジュールを公開するには、パートナーシップ契約を締結し、責任を説明する契約に署名するだけです。また、モジュールの依存関係や、依存関係のチェーンのインストールについても話していません。

この問題は、「以前」に開発されたすべてのCMSに固有のものです。それは小さなモジュールの開発をやる気にさせ（「この単純な機能」はモジュールに包まれるべきではないと思われます）、別のドキュメントが必要です。

この記事では、チーム/会社のストレージとベストプラクティスの使用を整理する方法を説明します。これは、同様の問題に直面している人、CMSを使用してWebサイトを開発している人、独自のCMSを開発している人、PHPでプロジェクトを単純に開発している人にとって興味深いものです。行こう！

パート1 モジュールの公共配置

解決する必要がある最初のタスクは、モジュールの保存場所です。モジュールのソースコードは、git、mercurial、またはsvnリポジトリに保存できます。公開モジュールには、GitHubをお勧めします。 GitHubでは、ソースコードを簡単に表示し、Markdown形式のドキュメントを管理できます。 composerを使用するには、composer.jsonファイルを作成してデータを取り込む必要があります。これは、エディター、IDE、またはcomposer initコマンドを呼び出すことで実行できます。以下、基本的な機能と作曲家のコマンドについては詳しく説明しません。作曲家が初めての場合は、この記事を読んでください。

モジュールを作成し（たとえば、現在は空です）、GitHubにコードを投稿したら、 packagist.orgにモジュールを登録する必要があります。 Packagistは、GitHubフックを構成して、リポジトリに変更が加えられたときに、packagist.orgでモジュールに関する情報が更新されるように提供します。

パート2 設置ここで最も興味深い

確かに、あなたは作業するCMSに非常に精通しています。つまり、CMSにモジュールをインストールすることのすべての巧妙さを知っています。 1C-Bitrixでは、モジュールのインストールは2段階で行われます。

モジュールのソースコードを特定のディレクトリ<project_dir>/local/modules/<company_name>.<mod_mame>
RegisterModule関数（<company_name>。<mod_mame>）を呼び出します。原則として、すべてのモジュールのインストールアクションは、モジュールのインストールと削除を行うクラスのDoInstallメソッドで説明されます。 <project_dir>/local/modules/<company_name>.<mod_mame>/install/index.php

パート2は1です。パッケージを安全な場所に隠す

composerがプロジェクトのルートにあり、パッケージ内のフックを実行しない場合、composerはデフォルトですべてのパッケージを<project_dir>/vendor

ディレクトリにインストールします。しかし、それは簡単に変更できます。

composer.jsonファイルをプロジェクトルートに配置する必要があります。

 { "name": "sites/<sitename>", "description": "<SiteName>", "authors": [ { "name": "<developerName>", "email": "<developerEmail>" } ], "minimum-stability": "dev", "require": {}, "config": { "vendor-dir": "local/vendor" } }

1C-Bitrixでは、開発者によって書かれたコードは通常<project_dir>/local

ディレクトリに配置されます。したがって、 configセクションのエントリによってvendor

フォルダをそこに移動しました。これで、すべてのサードパーティパッケージがそこでホストされます。ただし、モジュールはディレクトリ<project_dir>/local/modules/<company_name>.<mod_mame>

に配置する必要があります。どうすればよいですか？

パート2 2。モジュールインストールプラグイン

Composerにはいくつかのタイプのパッケージがあり、そのうちの1つはcomposer-pluginがcomposer自体の拡張機能です。 CMSの必要に応じてモジュールをインストールするために、独自のプラグインを作成する必要があります。これを行うには、別のプロジェクトを作成し、 composer.jsonをそのルートに配置します。

 { "name": "<my_name>/installer", "description": "Plugin for custom installing", "type": "composer-plugin", "license": "MIT", "homepage": "<link to homepage github>", "version": "0.0.1", "authors": [ { "name": "<name>", "email": "<email>" } ], "require": { "composer-plugin-api": "^1.0" }, "require-dev": { "composer/composer": "^1.0" }, "autoload": { "psr-4": { "<my_name>\\installer\\": "" } }, "extra": { "class": "<my_name>\\installer\\Plugin" } }

このファイルには3つの重要なポイントがあります。

"type"： "composer-plugin" - 作曲家にプラグインであることを伝えます
autoload-自動ロードクラスのルールについて説明します
extra-どのクラスがプラグインであるかを示します

プラグインは2つのクラスで構成されます。

プラグイン自体。彼は作曲家に自分のインストーラーを追加します
インストーラー、モジュールのインストールに従事します

プラグインは単にインストーラーを追加します（ファイル： Plugin.php ）

 namespace company_name\installer; use Composer\Composer; use Composer\EventDispatcher\EventSubscriberInterface; use Composer\IO\IOInterface; use Composer\Plugin\PluginInterface; class Plugin implements PluginInterface { public function activate(Composer $composer, IOInterface $io) { $composer->getInstallationManager()->addInstaller(new Bitrix($io, $composer)); } }

次に、インストーラー自体（ company_name\installer\Bitrix

）。クラスは、 Composer\Installer\LibraryInstaller

を継承し、次のメソッドを含む必要があります。

サポート -インストーラーがこのタイプのパッケージをサポートする場合、trueを返します
getInstallPath-パッケージソースコードを配置するパスを返します
インストール/アンインストール/更新 -パッケージのインストール/アンインストール/更新フック

すべてのモジュールはbitrix-moduleタイプであり、インストーラーはそれらを使用する必要があります。

 public function supports($packageType) { return $packageType === 'bitrix-module'; }

モジュール名（ピリオドで区切られたcompany_nameとmod_nameで構成される）の整合性を維持し、パッケージに<my_name>/<company_name>.<mod_mame>

または<company_name>/<company_name>.<mod_mame>

。パッケージ名を取得してスラッシュで区切ると、2番目の部分はモジュールの名前になります

 public function getInstallPath(PackageInterface $package) { $name = explode("/", $package->getName()); return "local/modules/{$name[1]}/"; }

initBitrixおよびgetModuleメソッドは、1C-Bitrix APIと連携してモジュールをインストールします。更新方法は、使用しているCMSとモジュール更新のリリース方法、およびそれらの実行計画に基づいて実装されます（ファイル： Bitrix.php ）。

 namespace company_name\installer; use Composer\Installer\LibraryInstaller; use Composer\Package\PackageInterface; use Composer\Repository\InstalledRepositoryInterface; class Bitrix extends LibraryInstaller { public function supports($packageType) { return $packageType === 'bitrix-module'; } public function install(InstalledRepositoryInterface $repo, PackageInterface $package) { parent::install($repo, $package); $name = explode("/", $package->getName()); $this->initBitrix(); $module = $this->getModule($name[1]); $module->DoInstall(); } public function uninstall(InstalledRepositoryInterface $repo, PackageInterface $package) { $name = explode("/", $package->getName()); $this->initBitrix(); $module = $this->getModule($name[1]); $module->DoUninstall(); parent::uninstall($repo, $package); } public function getInstallPath(PackageInterface $package) { $name = explode("/", $package->getName()); return "local/modules/{$name[1]}/"; } protected function initBitrix() { $_SERVER['DOCUMENT_ROOT'] = __DIR__ . "/../../../../"; define('STOP_STATISTICS', true); define("NO_KEEP_STATISTIC", "Y"); define("NO_AGENT_STATISTIC","Y"); define("NOT_CHECK_PERMISSIONS", true); require_once($_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php'); $GLOBALS['APPLICATION']->RestartBuffer(); } protected function getModule($module) { include_once $_SERVER['DOCUMENT_ROOT'] . "/local/modules/" . $module . "/install/index.php"; $class = str_replace(".", "_", $module); $module = new $class(); return $module; } }

プラグインを確認したら、コードをGitHubにアップロードし、Packagistに登録できます。

パート2 3。モジュール

最初の部分で説明したモジュール自体に戻りましょう。というか、彼のcomposer.jsonに 。

 { "name": "<my_name>/<company_name>.<mod_mame>", "type": "bitrix-module", "description": "  ", "version": "1.0.0", "time": "11.09.2018", "minimum-stability": "dev", "license": "MIT", "homepage": "<link to homepage github>", "authors": [ { "name": "<name>", "email": "<email>" } ], "require": { "<my_name>/installer": "*" } }

モジュールの名前はCMSの要件に準拠する必要があり、インストーラーが動作するタイプを指定する必要があり（この場合はbitrix-module ）、依存関係ではモジュールにプラグインが必要です （ requireセクション）。モジュール自体を作成し、その動作を確認した後、GitHubにコードを入力し、Packagistに登録します。

パート2 4。の使用

プロジェクト（サイト）自体には、およそ次のcomposer.jsonがあることを思い出させてください

 { "name": "sites/<sitename>", "description": "<SiteName>", "authors": [ { "name": "<developerName>", "email": "<developerEmail>" } ], "minimum-stability": "dev", "require": {}, "config": { "vendor-dir": "local/vendor" } }

これで、必要なすべてのモジュールをrequireセクションにリストするか、コマンドを呼び出すことができます

 composer require "<my_name>/<company_name>.<mod_mame>" "*"

たとえば、SMSでパスワードを送信してプロジェクトに認証モジュールを追加する必要がある場合、完了した作業の有用性を十分に感じることができます。

モジュール自体には、承認ロジックを担当するコードが含まれています。SMS送信コードを含めることはできません。たとえば、通知モジュールなどの他のモジュールもSMSを送信するため、コードが重複しないようにSMSを個別のモジュールにする方がよいためです。 RESTサービスも同様です。他のモジュールでも使用できます。そして、この複雑なスキームのすべてで、モジュールがさらに4つを引っ張っても、そのインストールは同じように簡単なままです。 1つのコマンドを実行するだけです：

 composer require "<my_name>/<company_name>.<mod_mame>" "*"

そして、何をどの順序でダウンロードしてインストールするかを作曲家に決めさせます。

パート3。プライベートモジュール

友だち、上記のすべてで、モジュールがパブリックドメインにあることを好まない場合は、すぐに修正します。モジュールのhelloストレージを整理するには、2つのツールが必要です。

GitLabはGitHubの類似物であり、サーバーにダウンロードしてインストールできます。
Satisは、作曲家が使用できるリポジトリジェネレーターです。

開始するには、GitLabをインストールし、モジュールのソースコードをGitLabに転送します。次に、Satisをインストールし、 satis.jsonにすべてのモジュールを記述します

 { "name": "ropoName", "homepage": "https://composer.<company_name>.ru/", "repositories": [ { "type": "vcs", "url": "https://gitlab.<company_name>.ru/<my_name>/installer" }, { "type": "vcs", "url": "https://gitlab.<company_name>.ru/<my_name>/<company_name>.<mod_name>" } ], "config": { "gitlab-domains": [ "gitlab.<company_name>.ru" ], "gitlab-token": { "gitlab.<company_name>.ru": "GitLab Token" } }, "require-all": true }

GitLabでは、apiが利用できるトークンを作成し、 satis.jsonで指定する必要があります。これらすべての操作の後、次のコマンドを実行します。

 php bin/satis build satis.json ./web

そして、 Webフォルダーで、 https：// composer 。<company_name> .ru /。で公開できる静的リポジトリーを取得します。

サイトのcomposer.jsonは、 リポジトリセクションがあるという点でのみ異なります

 { "name": "sites/<sitename>", "description": "<SiteName>", "authors": [ { "name": "<developerName>", "email": "<developerEmail>" } ], "minimum-stability": "dev", "require": {}, "config": { "vendor-dir": "local/vendor" }, "repositories": [ { "type": "composer", "url": "https://composer.<company_name>.ru/" } ] }

あとがき

友人たち、この記事があなたの役に立つことを本当に願っています。また、どのCMSを使用するかは関係ありません。コードのストレージを正しく整理し、厳密に文書化し、「厚い」モジュールを多くの「薄い」フォーマット依存関係に分割することができ、モジュールのインストールまたは更新が困難になります。がんばって。

composerを使用してCMSのモジュールを管理する

まえがき

パート1 モジュールの公共配置

パート2 設置 ここで最も興味深い

パート2は1です。 パッケージを安全な場所に隠す

パート2 2。 モジュールインストールプラグイン

パート2 3。 モジュール

パート2 4。 の使用

パート3。 プライベートモジュール