Best Practice zur Vermeidung von Modul- / Themen- / Profilnamen -Konflikten?

Question

Wir haben derzeit unseren Code so verwaltet, dass jede Website ein eigenes Thema und ein eigenes Installationsprofil hat. Diese haben sich natürlich so entwickelt, dass die Namen dieser Elemente (und ihrer Verzeichnisse) tendenziell gleich sind.

Zum Beispiel werden das Thema und das Profil einer Site "Dennis" bezeichnet

Dies führt zu Problemen mit Feature -Servern und (ich verdächtige) mit Aegir.

Jetzt ... ist es relativ einfach, eine dieser Weise umzubenennen (obwohl es aus verschiedenen Gründen merklich einfacher ist, das Profil umzubenennen). Gibt es hier eine Art Best Practice, dh ist es normal, das Thema Dennis_TheMe oder das Profil Dennis_profile zu nennen? Sollte ich diese Konvention auf beide oder nur auf einen anwenden?

Answer 1

In meinem Büro haben wir normalerweise einen Site -Schlüssel, der für die meisten Dinge verwendet wird.

• Kunde: ACME Company & Co.
• Schlüssel: ACME
• Site -Ordner:/path/to/webserver/sites/acme
• Benutzerdefinierte Module: acme_tweaks, acme_forms, acme_blocks, acme_settings
• Thema: acme_theme
• Repo: acme.git
• etc...

Für den Code, den wir von Site zu Site wiederverwenden, stellen wir sicher, dass er verallgemeinert und kunden -mehrdeutig ist, und fügen ihn dann zu einigen gängigen Modulen hinzu, die Teil unseres Standardmoduls sind - z. B.:

• theme_tweaks
• template_suggestions

Unsere Regel ist, dass es nicht hineingehen sollte theme_tweaks aber in acme_tweaks usw.

Answer 2

Eine Möglichkeit, Namenskollisionen für benutzerdefinierte Module zu vermeiden, die für bestimmte Websites verwendet werden, besteht darin, den Site -Namen zu verwenden, um den Modulnamen zu erstellen. Zum Beispiel ist der kurze Name, der für "Drupal.org -Anpassungen" verwendet wird und das Projekt enthält, das speziell auf Drupal.org verwendet wird Drupalorg, während ein ähnliches Projekt mit benutzerdefinierten Modulen für Groups.drupal.org ist Gruppendrupalorg.

Sie können es auch vermeiden, die Domäne der obersten Ebene zu verwenden, wenn Sie der Meinung sind, dass Sie keine Module für Websites mit einem Domainnamen erstellen, der nur für die Domäne der obersten Ebene (z. B. bingo.com und bingo.it) unterschiedlich ist.

Answer 3

Natürlich hilft es mit einem Projekt 'machine_name' als Namespace. Was ich zuerst herausfinde, ist, welche der Module, Installationsprofile, Themen (und Makefiles) ich an die Öffentlichkeit veröffentlichen (Github, Drupal.org usw.). Diejenigen, die ich veröffentlichen werde, erhalten generische Namen, während die anderen ProjectName_Short_Description als Name erhalten.

Für ein Hacker Community-Projekt, das ich entwickle, heißt das generische Zen-Unterthema, das ich entwickelt habe, als "Conway", während das tatsächliche Thema (mit Conway als Basisthema) als "hacker_theme" bezeichnet wird. Gleiches gilt für hacker_event_feature, hacker_install_profile, hacker_distro (a Kit-Compliant Distribution Spezifisches Feature, entspricht dem Projekt von ProjectName_TWeaks, das ich überall sehe).