Usando extensões de depuração / modo desenvolvedor, proteção suficiente

18

Existem algumas extensões legais para desenvolvedores do Magento que você normalmente não deseja ter em um sistema ativo.

Como você pode mantê-los no repositório do projeto, mas evitar que sejam expostos em uma loja ao vivo?

development debug developer-mode

— Alex
fonte

20

Existem duas técnicas relativamente novas para fazer isso:

Use o modman para poder controlar por si mesmo o que implantar para cada ambiente. Isso significa que você corremodman deploy [name-of-dev-extension] apenas no seu ambiente de desenvolvimento.
Use o magento-compositor com diferentes composer.jsoncenários para diferentes ambientes. E a maneira ainda mais fácil é especificar essas extensões como módulos dev e instalar o projeto usando a --require-devopção na sua máquina de desenvolvimento.

— user487772
fonte

11

+ Um para reffering para modman :) boa opção

— Toon Van Dooren

Você pode descrever mais como seria a implantação específica do ambiente? Quero dizer, onde mantenho a lista de módulos que implanto? Normalmente, tenho uma pasta com todos os módulos - e, novamente, tenho que separar o live e o development.

— Alex

@ Alex: por favor, veja minha edição.

— user487772

@ Tim: obrigado! Também editei sua resposta agora.

— 7283 Alex

@ Alex: Obrigado. Eu não sabia disso :-)

— user487772

10

Esses geralmente podem ser desativados convenientemente com um sinalizador de configuração, para que eles sejam tecnicamente ativos, mas não estejam fazendo nada. Se você definir esse sinalizador como false no app/etc/local.xmlseu sistema ativo, você estará bem.

— Fabian Schmengler
fonte

Esta é uma boa solução, a menos que você queira manter seu local.xmlarquivo em seu repositório. O que pode ser um caso.

— usar o seguinte comando

Grande resposta - local.xmlnão é geralmente no repo

— Alex

6

Veja o MageTrashApp, criado recentemente no Magento Hackathon em Berlim. Permite desativar os módulos através do painel de administração.

— Karen Baker
fonte

5

Uma maneira simples de fazer isso é desabilitar o módulo em / etc / modules, pressioná-lo, ignorar o arquivo localmente e habilitá-lo novamente.

— Toon Van Dooren
fonte

Nesse caso, você estará limitado a fazer modificações nos arquivos de inicialização de extensões (por exemplo, modificar dependências). Além disso, se você verificar, digamos na sua outra máquina, você terá que fazer todos esses truques mais uma vez. Pode ser ainda mais inconveniente com uma equipe de vários desenvolvedores.

— user487772

Se você ignorar o arquivo localmente, a única coisa que outros desenvolvedores precisam fazer é ativá-lo novamente. Isso leva apenas alguns segundos.

— precisa saber é o seguinte

Certo. Mas, novamente, eles precisam ignorá-lo localmente. E isso é para cada extensão para cada cópia de trabalho. Quero dizer, sua solução definitivamente funcionará, mas é um pouco inconveniente.

— user487772

verdade, eu acho que eu apenas olhei para ele da minha posição, eu costumo integrar apenas 1 ou 2 ferramentas de desenvolvimento :-)

— Toon Van Dooren

3

Eu acho que a melhor maneira de lidar com isso é manter todos esses módulos no codePool local e desativar todos os módulos locais ao vivo com essa linha no seu local.xml:

    <disable_local_modules>true</disable_local_modules>

Ou você pode "Desativar saída do módulo" no back-end em seu ambiente ativo. (Sistema -> Configuração -> Avançado). No entanto, isso não desativa completamente o módulo. Mas talvez seja o suficiente o suficiente para você querer esconder isso.

A única outra coisa que consigo pensar é escrever algum código que possa fazer isso. Basta verificar se está no modo de desenvolvedor ( Mage::getIsDeveloperMode()) e depois desativar os módulos. Encontrei mais alguns detalhes sobre como fazer isso aqui: /programming/6520634/magento-how-to-disable-module-programmatically

— Rick Kuipers
fonte

Todas as 3 soluções não são boas o suficiente. A desativação de localmódulos forçará você a mover todos os outros módulos do localcodePool para communitye também o fará em todas as extensões futuras. A desativação da saída dos módulos, como você disse, ainda permite que a extensão seja executada desacelerando sua loja. E a terceira solução exigirá modificações que serão substituídas pela atualização das extensões.

— user487772

2

@ Tim Concordo absolutamente. Deve haver uma maneira melhor de lidar com isso, deve haver uma configuração principal dos módulos de desativação / ativação no modo de desenvolvimento.

— precisa saber é o seguinte

3

Normalmente, eu apenas os coloco no meu ambiente de teste, mas não os faço no sistema de controle de versão, por exemplo, usando o .gitignorearquivo para excluí-los de serem considerados para confirmação.

— mpaepper
fonte

O OP enfatizou em manter as extensões no repositório.

— user487772

1

Há um slide na conferência Imagine 2011 de Erik Hansen. Ele declarou um código no slide que é o seguinte (para o modo de desenvolvedor)

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

aqui está, Erik habilitando uma configuração com base nos subdomínios que você pode personalizá-la.

— Oğuz Çelikdemir
fonte

o que isso tem a ver com módulos para desenvolvimento?

— Bryan Ruiz

Caro @bryan_ruiz, o sistema Magento verificando o MAGE_IS_DEVELOPER_MODE, ativo ou não. Confira o artigo de Alan. Magento Developer Mode

— Oğuz Çelikdemir

o que estou dizendo é que não entendo como isso se relaciona com a questão. O modo de desenvolvedor não habilita ou desabilita os módulos que ele está usando.

— precisa saber é o seguinte

Bryan, como especifiquei no meu comentário, você pode personalizar o código como sua solicitação. Obviamente, a ideia bruta não se encaixa na solicitação. Por exemplo, se você escreveu sua extensão depende de um parâmetro, pode verificar ou controlar o snippet acima!

— Oğuz Çelikdemir