web-dev-qa-db-ja.com

モジュール/テーマ/プロファイル名の衝突を回避するためのベストプラクティス？

現在、各サイトに独自のテーマとインストールプロファイルがあるようにコードを管理しています。これらは、これらのアイテム（およびそれらのディレクトリ）の名前が同じになる傾向があるように自然に進化しました。

たとえば、あるサイトのテーマとプロファイルはどちらも「デニス」と呼ばれます

これにより、機能サーバーで問題が発生し、（疑わしい）Aegirで問題が発生します。

これらのいずれかの名前を変更するのは比較的簡単です（ただし、さまざまな理由により、プロファイルの名前を変更する方がはるかに簡単です）。ここにはなんらかのベストプラクティスがありますか。つまり、テーマdennis_themeまたはプロファイルdennis_profileを呼び出すのは普通ですか？この規則を両方に適用する必要がありますか、それとも1つだけに適用しますか？

coding-standards
5
Parsingphase

私のオフィスには通常、ほとんどのことに使用されるサイトキーがあります。

  • クライアント：Acme Company＆Co
  • キー：acme
  • サイトフォルダー：/ path/to/WebServer/sites/acme
  • カスタムモジュール：acme_tweaks、acme_forms、acme_blocks、acme_settings
  • テーマ：acme_theme
  • リポジトリ：acme.git
  • 等...

サイト間で再利用するコードについては、一般化され、クライアントがあいまいであることを確認してから、デフォルトのモジュールセットの一部であるいくつかの一般的なモジュールに追加します。

  • theme_tweaks
  • template_suggestions

私たちのルールは、それがすべてのクライアントサイトに適用できる場合（少なくとも先に進む場合）を除いて、theme_tweaksがacme_tweaksなど.

10
electblake

特定のサイトで使用されるカスタムモジュールの名前の競合を回避する方法は、サイト名を使用してモジュール名を作成することです。たとえば、drupal.orgで特に使用されるモジュールを含むプロジェクトである「Drupal.orgカスタマイズ」に使用される短い名前はdrupalorgですが、同様のプロジェクトはgroups.drupalのカスタムモジュールを含みます。 orgはgroupsdrupalorgです。

トップレベルドメイン（bingo.comとbingo.itなど）のみが異なるドメイン名を持つサイトのモジュールを作成しない場合は、トップレベルドメインの使用を避けることもできます。

1
kiamlaluno

もちろん、プロジェクト「machine_name」を名前空間として使用すると役立ちます。私が最初に理解するのは、どのモジュール、インストールプロファイル、テーマ（およびmakefile）を一般にリリースするか（github、drupal.orgなど）です。私がリリースするものは総称名を取得し、他のものは名前としてPROJECTNAME_short_descriptionを取得します。

私が開発しているハッカーコミュニティプロジェクトの場合、私が開発した一般的なzenサブテーマは「Conway」と呼ばれ、実際のテーマ（ベースのテーマとしてConwayを使用）は「hacker_theme」と呼ばれます。同じことがhacker_event_feature、hacker_install_profile、hacker_distro（ kit -準拠のディストリビューション固有の機能、どこにでもあるprojectname_tweaksモジュールに相当）にも当てはまります。

1
Capi Etheriel