Las mejores prácticas para evitar enfrentamientos módulo / tema / nombre de perfil?

Question

Actualmente tenemos nuestro código administrado de tal manera que cada sitio tiene su propio tema y el perfil de instalación. Estos han evolucionado naturalmente, de tal manera que los nombres de estos artículos (y sus directorios) tienden a ser los mismos.

Por ejemplo, el tema y el perfil de un sitio son ambos llamados 'Dennis'

Esto causa problemas con los servidores de funciones, y (estoy sospechando) con Aegir.

Ahora ... es relativamente fácil de cambiar el nombre de cualquiera de ellos (aunque, por diversas razones, que es notablemente más fácil de cambiar el nombre del perfil). ¿Hay alguna especie de mejores prácticas aquí, es decir, es normal que llame a la dennis_theme tema, o la dennis_profile perfil? Debería aplicar esta convención para ambos, o sólo para uno?

Answer 1

En mi oficina que por lo general tienen un sitio clave que se usa para la mayoría de las cosas.

• Cliente: Compañía Acme & Co
• Clave: Acme
• Carpeta del sitio: ruta / / a / WebServer / sitios / acme
• Los módulos personalizados: acme_tweaks, acme_forms, acme_blocks, acme_settings
• Tema: acme_theme
• Repo: acme.git
• etc ...

Para código que nos re-utilización de un sitio a otro, nos aseguramos de que se generalizó y el cliente ambigua y luego añadirlo a algunos módulos comunes que forman parte de nuestro conjunto de módulo por defecto - como por ejemplo:

• theme_tweaks
• template_suggestions

Nuestra regla es que a menos que se puede aplicar a todos nuestros sitios del cliente (al menos en movimiento hacia adelante), entonces no debería ir en theme_tweaks pero en acme_tweaks etc.

Answer 2

Una manera de evitar conflictos de nombres de módulos personalizados que se utilizan para sitios específicos, es utilizar el nombre del sitio para crear el nombre del módulo. Por ejemplo, el nombre corto utiliza para "Drupal.org personalizaciones", que es el proyecto que contiene módulos utilizados específicamente en drupal.org, es drupalorg , mientras que un proyecto similar que contiene módulos personalizados para groups.drupal. org es groupsdrupalorg .

También puede evitar usar el dominio de nivel superior, si se piensa que no va a crear módulos para los sitios con un nombre de dominio que se diferencian sólo por el dominio de nivel superior (por ejemplo bingo.com y bingo.it).

Answer 3

Por supuesto, el uso de un 'machine_name' proyecto como un espacio de nombres ayudará. Lo que averiguar primero es cuál de los módulos, instalar perfiles, temas (y los archivos make) Voy a liberar al público (github, drupal.org, etc). Los que más me liberará reciben nombres genéricos, mientras que los otros reciben PROJECTNAME_short_description como nombre.

Para un proyecto de comunidad hacker que estoy desarrollando, el subtema zen genérico he desarrollado se llama 'Conway', mientras que el tema real (usando Conway como un tema de base) se llama 'hacker_theme'. Lo mismo va para hacker_event_feature, hacker_install_profile, hacker_distro (a kit según norma característica específica de distribución, equivalente a los projectname_tweaks Módulo I ver todas partes).