it-swarm-es.com

¿Cuál es la mejor práctica para evitar conflictos de nombres de módulos, temas o perfiles?

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

Por ejemplo, el tema y el perfil de un sitio se denominan 'dennis'

Esto causa problemas con los servidores de funciones y (sospecho) con Aegir.

Ahora ... es relativamente fácil cambiar el nombre de cualquiera de estos (aunque, por varias razones, es notablemente más fácil cambiar el nombre del perfil). ¿Existe algún tipo de mejor práctica aquí, es decir, es normal llamar al tema dennis_theme o al perfil dennis_profile? ¿Debo aplicar esta convención a ambos, o solo a uno?

5
Parsingphase

En mi oficina normalmente tenemos una clave de sitio que se usa para la mayoría de las cosas.

  • Cliente: Acme Company & Co
  • Clave: acme
  • Carpeta del sitio:/ruta/a/WebServer/sites/acme
  • Módulos personalizados: acme_tweaks, acme_forms, acme_blocks, acme_settings
  • Tema: acme_theme
  • Repo: acme.git
  • etc ...

Para el código que reutilizamos de un sitio a otro, nos aseguramos de que sea generalizado y ambiguo para el cliente y luego lo agregamos a algunos módulos comunes que forman parte de nuestro conjunto de módulos predeterminados, como:

  • theme_tweaks
  • template_suggestions

Nuestra regla es que, a menos que pueda aplicarse a todos los sitios de nuestros clientes (al menos en el futuro), no debería ingresar theme_tweaks pero en acme_tweaks etc.

10
electblake

Una forma de evitar conflictos de nombres para 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 usado para "personalizaciones de Drupal.org", que es el proyecto que contiene módulos usados ​​específicamente en drupal.org, es drupalorg, mientras que un proyecto similar contiene módulos personalizados para groups.drupal. org es groupsdrupalorg.

También puede evitar el uso del dominio de nivel superior, si cree que no creará módulos para sitios con un nombre de dominio que difiera solo para el dominio de nivel superior (por ejemplo, bingo.com y bingo.it).

1
kiamlaluno

Por supuesto, usar un proyecto 'nombre_máquina' como espacio de nombres ayudará. Lo primero que averiguo es cuál de los módulos, los perfiles de instalación, los temas (y los archivos MAKE) lanzaré al público (github, drupal.org, etc.). Los que voy a publicar obtienen nombres genéricos, mientras que los otros obtienen PROJECTNAME_short_description como nombre.

Para un proyecto de la comunidad de hackers que estoy desarrollando, el subtema zen genérico que desarrollé se llama 'Conway', mientras que el tema real (usando Conway como tema base) se llama 'hacker_theme'. Lo mismo ocurre con hacker_event_feature, hacker_install_profile, hacker_distro (una kit - característica específica de distribución compatible, equivalente al módulo projectname_tweaks que veo en todas partes).

1
Capi Etheriel