Les meilleures pratiques pour éviter le module / thème / conflits de noms de profil?

Question

Nous avons actuellement notre code managé tel que chaque site a son propre thème et installer le profil. Celles-ci ont naturellement évolué manière telle que les noms de ces éléments (et leurs répertoires) ont tendance à être les mêmes.

Par exemple, un thème de site et de profil sont tous deux appelés « dennis »

Cela provoque des problèmes avec les serveurs de fonctionnalités, et (je soupçonnant) avec Aegir.

Maintenant ... il est relativement facile de renommer l'une de ces (bien que, pour diverses raisons, il est nettement plus facile de renommer le profil). Y at-il sorte de bonnes pratiques ici, à savoir est-il normal d'appeler le thème dennis_theme, ou le profil dennis_profile? Dois-je appliquer cette convention à la fois, ou juste un?

Answer 1

Dans mon bureau, nous avons généralement une clé de site qui obtient utilisé pour la plupart des choses.

• Client: Acme Company & Co
• Clé: Acme
• Site dossier: Chemin / / vers / WebServer / sites / acme
• Modules personnalisés: acme_tweaks, acme_forms, acme_blocks, acme_settings
• Thème: acme_theme
• Repo: acme.git
• etc ...

Pour le code que nous réutilisons d'un site à nous assurer qu'il est généralisé et le client ambigu et puis l'ajouter à certains modules communs qui font partie de notre jeu de modules par défaut - tels que:

• theme_tweaks
• template_suggestions

Notre règle est que si elle peut être appliquée à tous les sites de nos clients (au moins aller de l'avant), il ne devrait pas aller dans theme_tweaks mais dans acme_tweaks etc.

Answer 2

Un moyen de conflits de noms d'éviter des modules personnalisés qui sont utilisés pour les sites spécifiques, est d'utiliser le nom du site pour créer le nom du module. Par exemple, le nom court utilisé pour « Drupal.org personnalisations », qui est le projet contenant des modules utilisés spécifiquement sur drupal.org, est drupalorg , tandis qu'un projet similaire contenant des modules personnalisés pour groups.drupal. org est groupsdrupalorg .

Vous pouvez également éviter d'utiliser le domaine de niveau supérieur, si vous pensez que vous ne serez pas créer des modules pour les sites avec un nom de domaine qui ne diffèrent que pour le domaine de niveau supérieur (par exemple bingo.com et bingo.it).

Answer 3

Bien sûr, utiliser un projet « machine_name » comme un espace vous aidera. Ce que je figure en premier est celui des modules, installer des profils, des thèmes (et makefiles) Je sortirai au public (github, drupal.org, etc.). Ceux que je publierons obtenir des noms génériques, tandis que les autres se PROJECTNAME_short_description comme nom.

Pour un projet communautaire hacker je développe, le sous-thème zen générique j'ai développé est appelé « Conway », alors que le thème réel (en utilisant Conway comme thème de base) est appelée « hacker_theme ». Même chose pour hacker_event_feature, hacker_install_profile, hacker_distro (kit fonction spécifique de distribution compatibles avec la norme, le module équivalent aux projectname_tweaks I voir partout).