Resumo: O Push Wizard do WP STAGING copia as alterações do Staging — ficheiros, tabelas da base de dados ou ambos — para o site em produção. Faz primeiro o Backup do site em produção (Passo 1), escolhe o que enviar nos Passos 2-3 e inicia o push. Se o push falhar, consulta a secção de resolução de problemas abaixo.
Este artigo explica como enviar um site de Staging para o site em produção e migrar modificações do site de Staging para o site em produção com o WP STAGING | PRO. Se ainda não criaste um, vê como criar um site de Staging WordPress antes de seguires este guia.
Se queres converter o teu site de Staging no site em produção com a versão básica do WP STAGING, lê este artigo para um método de migração alternativo se o Push Wizard não estiver disponível.
O que precisas de enviar?
Antes de abrires o Push Wizard, decide o que mover para produção. Isto determina os passos que precisas.
| Objetivo | Enviar base de dados? | Enviar ficheiros? | Ir para |
|---|---|---|---|
| Implementar novas publicações, menus ou definições de Plugins | Sim | Opcional | Enviar apenas alterações da base de dados |
| Implementar uma atualização de Theme ou Plugin | Não | Sim | Enviar apenas ficheiros |
| Site completo: ficheiros + base de dados juntos | Sim | Sim | Enviar todo o site de Staging para produção |
| Apenas tabelas selecionadas (ex. excluir encomendas WooCommerce) | Sim (seletivo) | Opcional | Passo 2: selecionar as tabelas da base de dados |
Vídeo: migrar o site de Staging WordPress para o site em produção
O vídeo abaixo mostra como o WP STAGING | PRO envia dados do site de Staging para o de produção.
O WP STAGING | PRO pode enviar todos os ficheiros de media, Themes, Plugins e dados da base de dados de um site de Staging WordPress de volta para um site em produção.
Insights: Para obter uma compreensão técnica fundamental de como o WP STAGING move o teu site de Staging para o site em produção e para perceberes as diferenças entre ficheiros e dados da base de dados, lê os artigos abaixo:
– Como o WP STAGING faz a migração do WordPress
– A estrutura da base de dados do WordPress
Contents
- O que precisas de enviar?
- Vídeo: migrar o site de Staging WordPress para o site em produção
- Antes do push: checklist pré-voo
- Enviar todo o site de Staging para produção
- Enviar apenas alterações da base de dados
- Enviar apenas ficheiros (Themes, Plugins, media)
- O que fazer se o push falhar
- Depois do push: checklist de verificação
- Artigos relacionados
Antes do push: checklist pré-voo
Confirma tudo o seguinte antes de executar o Push Wizard:
- O site em produção está ativo e acessível no respetivo URL (ex.:
https://example.com). - O site de Staging foi criado com o WP STAGING e contém as alterações que queres implementar.
- O WP STAGING | PRO está instalado e ativado no site em produção.
- As versões do núcleo do WordPress no Staging e em produção são idênticas.
Faz sempre Backup do site em produção antes de iniciar o push. Um Backup permite-te restaurar a produção em minutos se algo correr mal durante o push.
Enviar todo o site de Staging para produção
Usa este caminho quando queres enviar ficheiros e tabelas da base de dados numa única operação.
Passo 1: fazer Backup do site em produção e do de Staging
Faz Backup do site em produção antes de iniciar o push usando a ferramenta de Backup integrada do WP STAGING | PRO.
Vai a WP STAGING > Backup & Migration > Create New Backup. Introduz um nome e clica em Start Backup. Quando o Backup terminar, guarda uma cópia local via Actions > Download.
Passo 2: selecionar as tabelas da base de dados
Vai ao teu Site em produção > WP STAGING > Start / STAGING.
Se tens vários sites de Staging, seleciona o que queres transferir e clica no botão Push Changes.
Clica em Database Tables e seleciona todas as tabelas que queres enviar do Staging para produção. Qualquer tabela selecionada vai sobrescrever completamente a sua homóloga no site em produção.
Para perceber que tabelas da base de dados incluir antes do push, a referência da estrutura da base de dados WordPress lista todas as tabelas do núcleo e o que armazenam.
Desseleciona uma tabela específica para a excluir do push.
Se tens um sistema de loja como o WooCommerce, não queres sobrescrever encomendas e dados de clientes no site em produção. Nos links abaixo, vais encontrar uma descrição das tabelas WooCommerce na base de dados, qual a tabela que precisas de excluir para não sobrescreveres dados transacionais da loja em produção, e como exportar e importar encomendas WooCommerce e dados de utilizadores para o teu site de Staging.
Nota: Se estás apenas a enviar atualizações de ficheiros de Plugins ou Themes, não precisas de enviar nenhuma tabela da base de dados. No entanto, se alteraste definições, criaste publicações, atribuíste menus ou instalaste novos Plugins no Staging, essas ações ficam registadas na base de dados e tens de enviar as tabelas relevantes.
Passo 3: selecionar Plugins, Themes e ficheiros de media
Clica em Select Files e escolhe todas as pastas de Plugins, media e Themes que queres copiar para produção.
Também podes especificar pastas adicionais introduzindo os caminhos absolutos completos na área de texto.
Passo 4: excluir tabelas ou ficheiros do push
Duas opções controlam o que é removido do site em produção durante o push:
- Uninstall all plugins on the production site — remove Plugins de produção que já não existem no Staging.
- Delete the wp-content/uploads folder — limpa os uploads de produção antes de copiar a pasta uploads do Staging.
Se ambas as opções estiverem desativadas, nada é apagado da produção. Um Plugin removido no Staging será desativado em produção mas permanecerá instalado e pode ser reativado manualmente.
Passo 5: iniciar o processo de push
Clica em Push Staging Site to Live site para iniciar o push.
Quando o push terminar, recarrega o teu site. Todas as alterações do Staging vão estar em produção.
Nota: Por vezes o WordPress exige que voltes a iniciar sessão depois de um push completo. Isto acontece quando os dados de sessão da base de dados do Staging substituem a sessão de produção — é comportamento normal.
Enviar apenas alterações da base de dados
Se as tuas alterações estão limitadas a conteúdo, definições ou configuração de Plugins — e não alteraste ficheiros de Themes nem de Plugins — envia apenas as tabelas da base de dados.
No Push Wizard, abre Database Tables e seleciona apenas as tabelas que contêm as tuas alterações. Deixa todas as pastas de ficheiros dessellecionadas em Select Files. É mais rápido, reduz o risco e deixa os ficheiros em produção intactos.
Para perceber que tabelas da base de dados incluir antes do push, a referência da estrutura da base de dados lista todas as tabelas do núcleo WordPress e o que armazenam.
Utilizadores WooCommerce: Exclui as tabelas de encomendas e clientes WooCommerce ao enviar o Staging de uma loja. Enviar essas tabelas iria sobrescrever os dados de transações em produção. O callout WooCommerce no Passo 2 lista as tabelas específicas a saltar.
Enviar apenas ficheiros (Themes, Plugins, media)
Se atualizaste ou testaste um Theme ou Plugin no Staging e confirmaste que funciona, envia apenas os ficheiros alterados — não é necessário push da base de dados.
No Push Wizard, deixa Database Tables completamente dessellecionado. Em Select Files, escolhe apenas as pastas que mudaram: por exemplo, wp-content/themes/your-theme para uma atualização de Theme, ou wp-content/plugins/plugin-name para um único Plugin.
Depois do push, remove manualmente Plugins exclusivos do Staging após o push para produção se instalaste ferramentas só de desenvolvimento no Staging que não devem correr em produção.
O que fazer se o push falhar
Na nossa fila de suporte, as razões mais comuns para um push estagnar ou produzir erros enquadram-se em quatro categorias.
O push estagna em bases de dados grandes
Se o processo de push fica pendurado ou expira durante a cópia de tabelas da base de dados, a causa mais comum é uma definição max_allowed_packet demasiado pequena no MySQL. Este limite controla o tamanho máximo de uma única query da base de dados; quando uma linha de tabela o excede — valores de options serializados e publicações com imagens base64 embutidas são os culpados típicos — o push para a meio.
Solução: aumenta o max_allowed_packet na tua configuração MySQL ou pede ao teu fornecedor de Hosting para o aumentar. Vê também limites de configuração PHP que podem interromper um push — diretivas como memory_limit e max_input_vars também podem causar timeouts ao enviar bibliotecas de media grandes.
Conteúdo misto ou URLs partidos após o push
Se o site em produção mostra imagens partidas ou avisos de conteúdo misto após o push, o domínio do Staging continua presente em algumas linhas da base de dados. O WP STAGING substitui URLs durante o push, mas valores serializados em tabelas de Plugins personalizadas podem passar despercebidos.
Solução: executa uma pesquisa-e-substituição na base de dados para trocar o domínio do Staging pelo de produção. Erros de REST API que aparecem após o push para produção são frequentemente causados pelo mesmo desalinhamento de URL; resolver a substituição de domínio resolve ambos.
O administrador não consegue iniciar sessão após o push
Se enviaste toda a base de dados e não consegues iniciar sessão na administração de produção, a tabela de utilizadores do Staging substituiu a de produção e as credenciais originais de admin já não correspondem.
Solução: repõe a palavra-passe do admin diretamente no MySQL usando a ferramenta de gestão de base de dados do teu fornecedor de Hosting (por exemplo phpMyAdmin). Em alternativa, resolve quaisquer problemas de início de sessão no site de Staging primeiro, depois faz novo push.
Ecrã branco ou erro fatal após o push
Um ecrã branco imediatamente após o push significa normalmente que um Plugin que funcionava no Staging é incompatível com o ambiente de servidor de produção — tipicamente uma diferença de versão de PHP ou um desalinhamento de configuração de servidor.
Ativa o log de debug do WordPress para identificar o Plugin: adiciona define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); ao wp-config.php. O log de erros aparece em wp-content/debug.log. Depois de identificares e resolveres o Plugin incompatível, remove as constantes de debug.
Depois do push: checklist de verificação
Passa por estas verificações antes de considerares o push concluído:
- [ ] Visita a página inicial de produção — confirma que o novo conteúdo ou design está visível.
- [ ] Inicia sessão na administração de produção — confirma que as credenciais funcionam.
- [ ] Verifica
https://your-domain.com/wp-json/— uma resposta JSON confirma que a REST API está saudável. - [ ] Abre as ferramentas de programador do navegador → Consola — sem avisos de conteúdo misto.
- [ ] Testa quaisquer formulários, fluxos de checkout ou funcionalidades críticas.
- [ ] Remove manualmente Plugins exclusivos do Staging após o push para produção que não devem correr em produção.
- [ ] Pede reindexação no Google Search Console se mudou conteúdo significativo.
Artigos relacionados
- Início rápido: como enviar um novo Theme do Staging para o site em produção
- Enviar um site de Staging para o site em produção
- Criar um ambiente Dev > Staging. Criar um site de Staging e copiá-lo para outro site de Staging antes do lançamento
- Dicas para fazer Backup de site WordPress em produção e Staging
- Movi o site para um novo servidor – não consigo enviar o site de Staging
