Usando extensiones de depuración / modo desarrollador suficiente protección

18

Hay algunas extensiones agradables para desarrolladores de Magento que generalmente no desea tener en un sistema en vivo.

¿Cómo puede mantenerlos en el repositorio del proyecto pero evitar que se expongan en una tienda en vivo?

development debug developer-mode

— Alex
fuente

20

Hay dos técnicas relativamente nuevas para hacerlo:

Use modman para que pueda controlar por sí mismo qué implementar para cada entorno. Esto significa que modman deploy [name-of-dev-extension]solo se ejecuta en su entorno de desarrollo.
Utilice magento-composer con diferentes composer.jsonescenarios para diferentes entornos. Y una forma aún más fácil es especificar esas extensiones como módulos de desarrollo y luego instalar el proyecto usando el --require-devinterruptor en su máquina de desarrollo.

— usuario487772
fuente

1

+ uno para referirse a modman :) buena opción

— Toon Van Dooren

¿Puede describir más cómo se vería esa implementación específica del entorno? Quiero decir, ¿dónde guardo la lista de módulos que implemento? Por lo general, tengo una carpeta de todos los módulos, y de nuevo tengo que separar live y desarrollo.

— Alex

@ Alex: por favor vea mi edición.

— user487772

@Tim: gracias! También edité tu respuesta ahora.

— Alex

@ Alex: Gracias. No sabía esto :-)

— user487772

10

Por lo general, estos se pueden desactivar convenientemente con un indicador de configuración, por lo que son técnicamente activos pero no hacen nada. Si configura este indicador en falso en app/etc/local.xmlsu sistema en vivo, debería estar bien.

— Fabian Schmengler
fuente

Esta es una buena solución a menos que desee mantener su local.xmlarchivo en su repositorio. Que podría ser un caso.

— user487772

Gran respuesta - local.xmlgeneralmente no está en el repositorio

— Alex

6

Vea MageTrashApp que se creó recientemente en el Magento Hackathon en Berlín. Le permite desactivar módulos a través del panel de administración.

— Karen Baker
fuente

5

Una forma simple de hacer esto es deshabilitar el módulo en / etc / modules, presionarlo, ignorar el archivo localmente y habilitarlo nuevamente.

— Toon Van Dooren
fuente

En este caso, estará limitado a realizar modificaciones en el archivo bootstrap de extensiones (por ejemplo, modificar dependencias). Además, si va a revisar, digamos que en su otra máquina, tendrá que hacer todos esos trucos una vez más. Puede ser aún más inconveniente con un equipo de varios desarrolladores.

— user487772

Si ignora el archivo localmente, lo único que otros desarrolladores tienen que hacer es habilitarlo nuevamente. Esto toma solo unos segundos en mi humilde opinión.

— Toon Van Dooren

Correcto. Pero luego nuevamente tienen que ignorarlo localmente. Y esto es para cada extensión para cada copia de trabajo. Quiero decir que su solución definitivamente funcionará, pero es un poco incómoda.

— user487772

Es cierto, supongo que acabo de verlo desde mi posición, generalmente integro solo 1 o 2 herramientas de desarrollo :-)

— Toon Van Dooren

3

Creo que la mejor manera de lidiar con esto es mantener todos esos módulos en el codePool local y deshabilitar todos los módulos locales en vivo con esta línea en su local.xml:

    <disable_local_modules>true</disable_local_modules>

O puede hacer "Desactivar la salida del módulo" en el back-end de su entorno en vivo. (Sistema -> Configuración -> Avanzado). Sin embargo, esto no deshabilita por completo el módulo. Pero tal vez sea suficiente de querer esconderte de eso.

Lo único que se me ocurre es escribir algún código que pueda llevarlo a cabo. Simplemente verifique si está en modo desarrollador ( Mage::getIsDeveloperMode()) y luego deshabilite los módulos. Encontré algunos detalles más sobre cómo lograr esto aquí: /programming/6520634/magento-how-to-disable-module-programmatic

— Rick Kuipers
fuente

Las 3 soluciones no son lo suficientemente buenas. La desactivación de los localmódulos lo obligará a mover todos los demás módulos de localcodePool communityy también lo hará para todas las extensiones futuras. Deshabilitar la salida de los módulos como dijiste aún permite que la extensión se ejecute ralentizando tu tienda. Y la tercera solución requerirá modificaciones que se sobrescribirán con la actualización de las extensiones.

— user487772

2

@Tim estoy de acuerdo, absolutamente. Debería haber una mejor manera de lidiar con esto, debería haber una configuración central de los módulos de desactivación / habilitación cuando está en modo de desarrollo.

— Rick Kuipers el

3

Por lo general, solo los pongo en mi entorno de prueba, pero no los verifico en el sistema de control de versiones, por ejemplo, usando el .gitignorearchivo para excluirlos de ser considerados para comprometerse.

— mpaepper
fuente

OP enfatizó en mantener las extensiones en el repositorio.

— user487772

1

Hay una diapositiva en la conferencia Imagine 2011 de Erik Hansen. Indicó un código en la diapositiva que es el siguiente (para el modo desarrollador)

# File : index.php
if(preg_match('/^stage\.|\.dev$/', $_SERVER['HTTP_HOST'])) {
   $_SERVER['MAGE_IS_DEVELOPER_MODE'] = true;
}

aquí está, Erik habilita una configuración basada en los subdominios que puede personalizar usted mismo.

— Oğuz Çelikdemir
fuente

¿Qué tiene esto que ver con los módulos para el desarrollo?

— Bryan Ruiz

Estimado @bryan_ruiz, el sistema Magento verifica el MAGE_IS_DEVELOPER_MODE si está activo o no. Mira el artículo de Alan. Modo desarrollador Magento

— Oğuz Çelikdemir

Lo que digo es que no entiendo cómo se relaciona esto con la pregunta. el modo desarrollador no habilitará ni deshabilitará los módulos que está usando.

— Bryan Ruiz

Bryan, como lo especifiqué en mi comentario, puedes personalizar el código según tu solicitud. Por supuesto, la idea cruda no se ajusta a la solicitud. Por ejemplo, si escribió que su extensión depende de un parámetro, puede verificar o controlar el fragmento anterior.

— Oğuz Çelikdemir