DataFirefly Staging Pro: guia completo

O Staging Pro cria uma cópia completa da sua loja (ficheiros + base de dados) numa subpasta protegida do seu alojamento atual, sem nenhum timeout graças ao seu motor de cópia por lotes. Testa módulos, temas e atualizações em total segurança, e envia depois as suas alterações para produção tabela a tabela, com cópia de segurança automática e rollback num clique. Este guia cobre a instalação, a criação de um staging, as opções de proteção, o push para a produção e o rollback.

Instalação

1. Transfira o arquivo dfstagingpro.zip a partir da sua conta DataFirefly.
2. Back-office PrestaShop → Módulos → Carregar um módulo → envie o ZIP.
3. Na instalação, o módulo cria as suas tabelas df_staging_env e df_staging_log, regista os seus hooks e adiciona o separador Parâmetros avançados → Staging Pro.

Como funciona o staging

Um ambiente de staging é criado numa subpasta na raiz da sua loja (por exemplo /staging-v2/) e usa um prefixo de tabelas dedicado (por exemplo dfs1_) na mesma base de dados que a produção. Não precisa portanto nem de um segundo servidor, nem de um novo acesso MySQL, nem de uma configuração DNS.

O motor de cópia trabalha por lotes de alguns segundos e devolve depois o controlo, retomando exatamente onde tinha parado: cópia dos ficheiros através de uma fila de espera persistente, clonagem da base de dados por pacotes de linhas. Uma loja de vários gigabytes é assim clonada sem erro, mesmo num alojamento partilhado com um max_execution_time baixo.

Criar um staging

Aceda a Parâmetros avançados → Staging Pro, e depois ao painel de criação:

1. Introduza um nome (apenas minúsculas, algarismos e hífens, por exemplo v2). O URL do staging será a-sua-loja.pt/staging-v2/.
2. Escolha as suas opções de proteção e de cópia (ver abaixo).
3. Clique em Criar. O progresso é apresentado em direto com uma barra de avanço.

No fim do processo, o URL do staging e, se for o caso, as credenciais htpasswd são apresentados na linha do ambiente.

Opções de proteção e de cópia

• Proteger com .htpasswd: acrescenta uma autenticação HTTP (utilizador staging). A palavra-passe pode ser introduzida ou gerada automaticamente, e apresentada depois no painel.
• Desativar os e-mails: corta os e-mails de saída do staging (PS_MAIL_METHOD = 3). Nenhum risco de escrever a um cliente real.
• Desativar os pagamentos: desativa e remove dos hooks os módulos de pagamento conhecidos no staging.
• Ignorar as estatísticas: exclui da cópia as tabelas volumosas e não essenciais (ligações, registos, carrinhos abandonados…) para uma cópia muito mais rápida.
• Sem dados de clientes: cria vazias no staging as tabelas de clientes, moradas de clientes, encomendas, carrinhos, mensagens, visitantes, newsletter e registos RGPD. As moradas de fornecedores, fabricantes e armazéns são mantidas, bem como as tabelas de configuração das encomendas (estados, modelos de mensagens, estados de devolução, regras de carrinho). Ver a secção dedicada mais abaixo.
• Symlink da pasta img/: cria uma ligação simbólica para as imagens em vez de as copiar, para uma enorme poupança de espaço em disco.
• Modo de manutenção: coloca o staging em manutenção com o seu IP de administração na lista branca.

O motor de cópia por lotes

A criação de um staging encadeia várias etapas, cada uma com orçamento de tempo e retomada automaticamente: preparação, cópia dos ficheiros, clonagem da base de dados, reescrita dos URLs, configuração e proteção, e depois finalização. A reescrita de URL cobre shop_url, a configuração (incluindo os valores serializados e JSON, tratados sem corrupção), bem como os conteúdos CMS, produtos, categorias, marcas, fornecedores e lojas físicas.

Atualizar, multiambiente e eliminação

• Refresh: reconstrói um staging existente a partir do estado atual da produção (eliminação e depois recriação da pasta e do prefixo), num clique.
• Multiambiente: crie tantos stagings quantos forem necessários (v2, hotfix, teste-modulo…), cada um independente.
• Eliminação: elimina a pasta e as tabelas de um ambiente de forma orçamentada, sem timeout.

Enviar para a produção

Uma vez validados os seus testes, o botão Push permite enviar as suas alterações para produção, tabela a tabela:

1. Clique em Push na linha do ambiente: a lista das tabelas é apresentada, com o número de linhas de cada uma.
2. Assinale com precisão as tabelas a transferir.
3. Confirme. Antes de cada substituição, a tabela de produção correspondente é guardada automaticamente através de uma renomeação com carimbo temporal para um prefixo dfbak{carimbo}_.

Os URLs são reescritos no sentido staging → produção durante a transferência. As tabelas críticas (shop_url, configuration, shop, sessões e tabelas do módulo) estão protegidas e nunca podem ser enviadas.

Rollback

O botão Rollback restaura a produção a partir da última cópia de segurança de push, num clique. O módulo renomeia as tabelas de cópia de segurança dfbak…_ para retomarem o seu lugar de origem.

Salvaguardas e registo

• Todas as ações são bloqueadas se a loja atual for ela própria um staging, para evitar manipulações em cascata.
• Está disponível um registo detalhado por ambiente através do botão Logs.
• Como o robots.txt numa subpasta não é honrado pelos motores, a verdadeira proteção anti-indexação assenta no cabeçalho X-Robots-Tag e na meta noindex; a opção .htpasswd continua a ser a proteção mais segura.

Compatibilidade e notas técnicas

• PrestaShop 8.0 a 9.x, compatível com alojamento partilhado e multilingue.
• Controlador de administração legacy (sem controlador Symfony) para a compatibilidade PS8/PS9.
• Endpoints AJAX do back-office através do 4.º argumento de getAdminLink(); renderização JSON por um método dedicado.
• Staging = subpasta na raiz + prefixo de tabelas dfs{id}_ na mesma base MySQL.
• Cópias de segurança de push com carimbo temporal sob o prefixo dfbak{YmdHis}_, a limpar após validação.

Staging sem dados de clientes

A opção Sem dados de clientes, disponível desde a versão 1.1.0, cria o staging sem qualquer dado pessoal. As tabelas em causa são criadas com a sua estrutura exata, mas ficam vazias. É a escolha recomendada para confiar um staging a um prestador externo, para um teste de tema ou de módulo que não toque no processo de compra, e para limitar a superfície RGPD dos seus ambientes de teste.

O que não é copiado

• Clientes, grupos de clientes, tópicos e mensagens do apoio ao cliente, sessões de clientes, visitantes e estatísticas de ligação.
• Encomendas e toda a família associada: detalhes, histórico, faturas, pagamentos, transportadoras, regras de carrinho aplicadas, notas de crédito e devoluções.
• Carrinhos, produtos dos carrinhos, listas de desejos, mensagens, inscrições na newsletter, registos RGPD e registos de e-mails.
• Moradas dos clientes: a tabela address é copiada com um filtro, apenas as linhas associadas a um cliente ficam de fora.

O que é mantido

• Moradas de fornecedores, fabricantes, armazéns e lojas físicas.
• Tabelas de configuração das encomendas: estados de encomenda e as suas traduções, modelos de mensagens, estados de devolução, tipos de notas de crédito.
• Regras de carrinho, vales de desconto, transportadoras, impostos e todo o catálogo.
• Colaboradores do back-office: entra no staging com as suas credenciais habituais.

Autenticação HTTP e alojamentos cPanel / LiteSpeed

Desde a versão 1.0.1, o ficheiro .htpasswd é gerado no formato APR1-MD5 (o do comando htpasswd -m), lido pelo Apache, LiteSpeed e nginx. A versão 1.0.0 usava bcrypt, que o LiteSpeed (muito comum por trás do cPanel em alojamentos partilhados) não sabe ler: o staging respondia então 404 em todas as suas páginas.

O bloco de proteção acrescenta também uma página de erro 401 inline. No cPanel, o erro 401 é redirecionado globalmente para /401.shtml, uma página que não existe no PrestaShop: o subpedido cai no dispatcher da produção e devolve a sua página 404, de modo que o navegador nunca mostra a caixa de início de sessão. A página inline contorna esse redirecionamento.

Por fim, a linha ErrorDocument 404 do .htaccess copiado é reescrita para a subpasta de staging: um erro no staging mostra a página 404 do staging, e não a da produção.

Autoverificação na criação

No fim da configuração, o módulo envia um pedido HEAD ao robots.txt do staging, com as credenciais se a proteção estiver ativa, e depois sem credenciais para verificar que o servidor responde 401. O resultado é registado nos logs do ambiente:

• 200 com credenciais e 401 sem: está tudo em ordem.
• O servidor recusa o bloco de autenticação: o módulo retira o bloco e o .htpasswd, desativa a opção e mostra «Ready with warning» na linha do ambiente. O staging fica então acessível sem palavra-passe; ative o modo de manutenção.
• Código 0: o servidor não consegue chamar-se a si próprio (pedidos de saída bloqueados). Abra o URL do staging manualmente.

FAQ e resolução de problemas

O módulo funciona num alojamento partilhado? Sim. O motor de cópia por lotes com retoma automática evita qualquer timeout, seja qual for o max_execution_time do servidor.

A criação foi interrompida, o que fazer? Reabra o painel do Staging Pro: o ambiente retoma automaticamente a cópia onde tinha parado.

O staging pode enviar e-mails aos meus clientes? Não, se a opção «Desativar os e-mails» estiver ativa (recomendado): os e-mails de saída são cortados no staging.

Depois de um push, como anular? Use o botão Rollback, que restaura a última cópia de segurança automática. Lembre-se depois de limpar as tabelas dfbak* obsoletas.

Posso criar vários stagings ao mesmo tempo? Sim, o número de ambientes é ilimitado e cada um é totalmente independente.

O staging responde 404 em todo o lado, ou a caixa de início de sessão não aparece? É o sintoma corrigido na 1.0.1 nos alojamentos cPanel / LiteSpeed. Atualize o módulo e relance um Refresh do ambiente; consulte a secção «Autenticação HTTP e alojamentos cPanel / LiteSpeed» acima.

Posso criar um staging sem os dados dos meus clientes? Sim, assinale «Sem dados de clientes» na criação. Consulte a secção «Staging sem dados de clientes» acima.

Histórico de versões

1.1.0 (4 de setembro de 2026)

• Nova opção «Sem dados de clientes»: clientes, moradas de clientes, encomendas, carrinhos, mensagens, visitantes, newsletter e registos RGPD criados vazios no staging.
• As moradas de fornecedores, fabricantes e armazéns são mantidas, bem como as tabelas de configuração das encomendas.
• Salvaguarda de envio: estas tabelas são retiradas da lista e recusadas do lado do servidor num staging criado sem dados de clientes.

1.0.1 (3 de setembro de 2026)

• Proteção htpasswd: hash gerado em APR1-MD5, compatível com Apache e LiteSpeed (o bcrypt era rejeitado em alguns alojamentos cPanel, tornando o staging inacessível).
• Caixa de início de sessão HTTP: página 401 inline, para os alojamentos que redirecionam os erros 401 para uma página inexistente.
• Linha ErrorDocument do .htaccess reescrita para a subpasta de staging.
• Autoverificação no fim da criação: controlo HTTP do staging, remoção automática da proteção se o servidor a recusar e aviso no painel.

1.0.0 (11 de junho de 2026)

Primeira versão pública.