non-core(コアにバンドルされていないモジュール)モジュールをDrupal 7。私の提案する構造:
私は推測します、これのための最良のアプローチは以下のようにsites/all/modules
内に3つのフォルダを作ることです:
sites/all/modules/contrib
sites/all/modules/custom
sites/all/modules/local
現在、モジュールをインストールするには2つの方法があります。
新しいモジュールを手動でインストールしている間、すべて問題ありません。ディレクトリに移動して、そこにモジュールを配置するだけです。
しかし新しくダウンロードしたモジュールを管理パネルからsites/all/modules/contrib
にインストールする方法は?
さらに、非コアモジュールを整理するためのより良いアプローチはありますか?
モジュールフォルダを明確に保つことは、開発の重要な部分です。これは私の一般的な構造です:
contrib
— Drupal.orgのモジュールcustom
—このプロジェクト用に開発されたモジュールfeatures
—機能主導の開発用にエクスポートされた機能unstable
—サンドボックス、フォーク、不安定、パッチ適用済みモジュールパッチ/フォークを整理する方法の例をいくつか示します。
しかし、新しくダウンロードしたモジュールをadmin-panelの `sites/all/modules/contribにインストールする方法。
drush dl views rules # will download Views and Rules into sites/all/modules/contrib automatically if contrib folder exists.
プロジェクトのダウンロード先を--destination
に指定することもできます。
あなたが提案する構造は機能します。
ただし、原則として、ダウンロードしたコントリビュートされたモジュールは変更しないでください。モジュールをフォークすることにより、ローカルコピーはアイランドになり、提供されたモジュールに追加された将来のバグ修正やその他の改善の恩恵を受けることが難しくなります。
通常の方法は、ダウンロードしたモジュールの場合はsites/all/modules/
-contrib
の下に2つのサブディレクトリを、自己開発したモジュールの場合はcustom
を使用することです。ダウンロードしたモジュールをcontrib
に配置するには、管理パネルの代わりにdrushを使用してダウンロードおよびインストールします。
ただし、提供されたモジュールを微調整する必要がある場合があります。
カスタムバージョンをフォークするだけでなく、Drupal.orgのモジュールの課題キューにユースケースと要件を提示し、 patch をアップロードして、モジュールの機能を拡張してユースケースをカバーする必要があります。これを行うことで、Drupalコミュニティに貢献し、モジュールの他のユーザーによって作成された提案されたパッチに関するレビューと提案から利益を得ます。
ただし、パッチがモジュールの公式コードベースに組み込まれるまでに時間がかかる場合があります。当面は、パッチファイルのコピーを保持し、gitを使用して、モジュールのリリースされるモジュールの新しいバージョンに適用します。メンテナ。運が悪い場合は、モジュールが大幅に変更された場合にパッチを再ロールする必要があるかもしれませんが、これは自分でローカルフォークを維持するよりも良い選択肢です。
管理モジュールインストーラーを使用するときに、モジュールをインストールする/ sites/all/modules内のサブディレクトリを選択できるmodule_installモジュールがあります。
https://www.drupal.org/project/module_install
必要なサブディレクトリを作成し、モジュールをインストールして(ベストプラクティスに従いたい場合は、手動で/ sites/all/modules/contribに配置してください)、それを有効にします。