5

We currently have our code managed such that each site has its own theme and install profile. These have naturally evolved in such a way that the names of these items (and their directories) tend to be the same.

For example, one site's theme and profile are both called 'dennis'

This causes problems with feature servers, and (I'm suspecting) with Aegir.

Now... it's relatively easy to rename either of these (although, for various reasons it's noticeably easier to rename the profile). Is there any sort of best practice here, ie is it normal to call the theme dennis_theme, or the profile dennis_profile? Should I apply this convention to both, or just to one?

| improve this question | | | | |
10

In my office we usually have a site key that gets used for most things.

  • Client: Acme Company & Co
  • Key: acme
  • Site Folder: /path/to/WebServer/sites/acme
  • Custom Modules: acme_tweaks, acme_forms, acme_blocks, acme_settings
  • Theme: acme_theme
  • Repo: acme.git
  • etc...

For code that we re-use from site to site, we ensure that it's generalized and client ambiguous and then add it to some common modules that are part of our default module set - such as:

  • theme_tweaks
  • template_suggestions

Our rule is that unless it can be applied to all our client sites (at least moving forward) then it shouldn't go in theme_tweaks but in acme_tweaks etc.

| improve this answer | | | | |
1

A way to avoid name clashes for custom modules that are used for specific sites, is to use the site name to create the module name. For example, the short name used for "Drupal.org customizations," which is the project containing modules used specifically on drupal.org, is drupalorg, while a similar project containing custom modules for groups.drupal.org is groupsdrupalorg.

You could also avoid to use the top-level domain, if you think that you will not create modules for sites with a domain name that differ only for the top-level domain (e.g. bingo.com and bingo.it).

| improve this answer | | | | |
1

Of course using a project 'machine_name' as a namespace will help. What I figure out first is which of the modules, install profiles, themes (and makefiles) I will release to the public (github, drupal.org, etc). The ones I will release get generic names, while the other ones get PROJECTNAME_short_description as a name.

For a hacker community project I am developing, the generic zen sub-theme I developed is called 'Conway', while the actual theme (using Conway as a base theme) is called 'hacker_theme'. Same goes for hacker_event_feature, hacker_install_profile, hacker_distro (a kit-compliant distribution specific feature, equivalent to the projectname_tweaks module I see everywhere).

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.