O que dá errado ao mover um site WordPress do local para o online

O site está perfeito no seu laptop. Todas as páginas carregam, todas as imagens estão nítidas e o checkout funciona. Então, você o envia para o servidor online, o abre em um navegador e algo está errado.

Os ambientes local e online são mais diferentes do que parecem. Essa lacuna é onde a maioria dos problemas acontece.

Duplicator é um plugin de backup e migração do WordPress rodando em mais de 1,5 milhão de sites. Uma parcela significativa dos sites que rodam Duplicator Pro são ambientes locais ou de desenvolvimento, perto de 1 em cada 10. Isso é muita gente construindo em um laptop e enviando para um servidor online.

Analisamos os tickets de suporte de pessoas que estavam movendo sites de servidores locais para servidores ativos. As falhas são consistentes, e uma delas aparece com muito mais frequência aqui do que em qualquer outro lugar em nossos dados.

Esses números refletem o volume de tickets de suporte e dados de instalação anonimizados, não o número de clientes ou vendas.

Sumário

Principais Conclusões

Veja o que os tickets dizem sobre mover um site WordPress do desenvolvimento local para um servidor ativo. Todos os números vêm dos próprios registros do Duplicator.

• Quase 1 em cada 10 sites executando o Duplicator Pro são ambientes locais ou de desenvolvimento. Construir localmente primeiro é uma prática comum, não um caso excepcional.
• Problemas de local para ativo representam cerca de 1 em cada 8 de todos os tickets de suporte de migração. Para um único cenário, essa é uma grande parcela.
• SSL é a falha característica dessa transição. Ela aparece em cerca de 1 em cada 5 tickets de local para ativo, aproximadamente quinze vezes mais frequentemente do que em tickets de migração em geral.
• Incompatibilidades de versão do PHP ocorrem cerca de três vezes mais aqui do que em outras migrações porque as ferramentas locais usam PHP moderno, e muitos hosts ativos ficam para trás.
• O problema único mais comum é um limite do host impedindo a instalação, não uma falha na própria movimentação.
• Quase toda falha remonta a uma diferença entre os dois ambientes, não à transferência.

Resumindo: Seu laptop e seu servidor ativo geralmente discordam sobre quatro coisas: versão do PHP, SSL, permissões de arquivo e o domínio do site. Resolva essas questões antes de mover, e a transição ocorrerá sem problemas.

Uma ressalva que molda como ler isto. Estes são tickets de suporte, então eles mostram onde a transição de local para ativo falha, não com que frequência ela falha.

Muitas dessas movimentações ocorrem bem e nunca geram um ticket. E o número de 1 em 10 descreve sites executando o Duplicator Pro, não o WordPress como um todo.

Por que Local e Online São Mais Distantes do Que Parecem

Um ambiente WordPress local é construído para testes privados. Um servidor ativo é construído para a internet pública. Esses são trabalhos diferentes, e as configurações refletem isso.

Quatro diferenças causam quase tudo neste relatório:

• Versão do PHP. Ferramentas locais e hosts web ativos podem rodar em versões padrão de PHP diferentes.
• SSL. O local roda em http:// simples ou em um certificado autoassinado. O ativo espera um certificado real.
• Permissões de arquivo. O local é permissivo porque você é o único usuário. O ativo é mais restrito.
• O domínio. Seu site se conhece como algo como meudominio.local. Após a movimentação, esse nome não existe mais.

Seja você usando Local, MAMP, XAMPP, Docker, ou uma configuração simples de localhost, os modos de falha são os mesmos porque a lacuna está entre os ambientes, e não entre as ferramentas.

O Problema do SSL Que Ninguém Avisa Sobre

O site aparece no servidor ativo, e o cadeado está faltando. Ou o layout está quebrado porque metade das folhas de estilo se recusaram a carregar. Ou o navegador exibe um aviso de conteúdo misto, e você não tem ideia do que ele está se referindo.

Esta é a falha mais distinta em todo o conjunto de dados. Problemas de SSL aparecem em cerca de 1 em cada 5 tickets de local para produção, em comparação com aproximadamente 1 em cada 70 em tickets de migração em geral. Isso é cerca de quinze vezes a taxa normal, e a razão se resume ao timing em vez da própria mudança.

Uma ferramenta de migração reescreve o domínio do seu site durante a instalação. mysite.local se torna yoursite.com em todo o banco de dados, inclusive dentro de dados serializados. Essa parte está resolvida.

O protocolo é uma questão separada. Se o SSL não estiver ativo em seu host de produção no momento da migração, então http://yoursite.com é o endereço correto do site naquele momento. É isso que é gravado no banco de dados.

Ative o certificado depois, e seu site agora está servindo via HTTPS enquanto seu próprio banco de dados ainda diz http://. Todos os ativos salvos durante o desenvolvimento local herdam o mesmo problema, pois nenhum deles jamais precisou de HTTPS.

Nada falhou. O site foi movido para o endereço que tinha no momento.

A correção é principalmente sobre fazer as coisas na ordem certa:

• Ative o SSL no host de produção antes de migrar. A maioria dos hosts emite um certificado gratuito, geralmente em uma seção chamada SSL, SSL/TLS ou Segurança no painel de controle de hospedagem. Faça isso primeiro, e a instalação gravará https:// desde o início.
• Se você já migrou, atualize os URLs do site. Você os encontrará em Configurações » Geral no painel do WordPress, nos campos Endereço do WordPress e Endereço do Site.
• Execute uma busca e substituição para referências http:// deixadas do desenvolvimento local para que os links de ativos antigos correspondam ao novo protocolo.
• Verifique se há conteúdo misturado. Carregue o site de produção, abra o console do desenvolvedor do seu navegador e procure por avisos sobre recursos inseguros. Eles indicarão os arquivos exatos que ainda estão sendo carregados via http://.

Resolva o SSL antes da mudança, e um número surpreendente de problemas nunca acontece.

O Que Quebra em Migrações de Local para Online

O SSL é a razão principal pela qual as migrações de local para produção falham, mas não é a única. Veja quais outros erros aparecem, as causas e como resolvê-los.

O que dá errado	Aproximadamente com que frequência	O que está por trás disso	Como é resolvido
Um limite do host impede a instalação	Mais comum	O tempo limite do PHP ou o limite de memória do servidor de produção cortando a extração, o que seu laptop nunca impôs	Aumente max_execution_time e memory_limit no host
O site não está seguro após a mudança	Cerca de 1 em 5	O SSL não estava ativo no host no momento da mudança, então o endereço salvo ainda é http://	Ative o SSL no host antes de migrar, depois confirme se os URLs do site usam https://
A importação do banco de dados falha	Cerca de 1 em 7	As credenciais do banco de dados de produção não correspondem ao que o host criou	Insira o nome de usuário, nome e senha corretos do banco de dados durante a instalação
As permissões de arquivo bloqueiam a escrita	Cerca de 1 em 8	O ambiente local é permissivo, o de produção não é, então a propriedade e o acesso de escrita subitamente importam	Defina as pastas para 755 e os arquivos para 644 no destino
Você não consegue fazer login depois que ele está no ar	Cerca de 1 em 9	A URL do site salvo não corresponde ao endereço ativo, causando um loop de redirecionamento	Corrija o Endereço do WordPress e o Endereço do Site, em seguida, limpe os cookies
Erros de PHP aparecem no site ativo	Cerca de 1 em 11	A ferramenta local usa uma versão mais recente do PHP do que o servidor, então funções são depreciadas ou ausentes	Combine as versões do PHP em ambas as pontas antes de migrar
Algumas referências locais sobrevivem	Cerca de 1 em 16	URLs codificadas em arquivos de tema, código personalizado, caches ou serviços de terceiros, fora do banco de dados	Procure no tema e no código personalizado pelo domínio local, em seguida, limpe todos os caches

Leia a terceira coluna e o padrão é difícil de perder. Quase nada aqui é causado pela transferência. É causado pela configuração diferente do servidor ativo em comparação com o seu laptop.

Quando um Limite do Host Interrompe a Instalação

Você inicia a instalação no servidor ativo, ela processa por um tempo e depois para.

Este é o problema único mais comum nos tickets de local para ativo, e é um limite do host em vez de uma migração quebrada. O tempo limite de PHP ou o limite de memória do servidor interrompe o processo durante a extração, que é a etapa mais pesada. Máquinas locais não têm esse limite, então uma compilação que funcionou bem no seu laptop pode atingir um obstáculo em hospedagem compartilhada.

Aumente max_execution_time e memory_limit no servidor de destino. Estes ficam no painel de controle do seu host, muitas vezes em Opções de PHP ou Editor MultiPHP INI, e o suporte do seu host pode aumentá-los rapidamente se você não os encontrar.

É aqui também que a ferramenta que você usa faz a diferença.

Um arquivo zip padrão precisa ser descompactado em uma única execução contínua. Em um servidor com um limite de execução curto, isso é um problema.

Se a descompactação demorar mais do que o host permite, o processo é encerrado no meio e você fica com um site parcialmente descompactado e sem um erro claro.

DupArchive é o formato de arquivo de backup personalizado da Duplicator, projetado para ser descompactado em pedaços menores. Ele funciona através do site em blocos, então nenhuma execução única precisa se estender além do limite do host.

É isso que permite que o Duplicator lide com sites grandes, incluindo migrações reais de 400GB, em servidores que engasgariam com um arquivo convencional.

O instalador independente resolve um problema relacionado na outra ponta. Ele não precisa que o WordPress já exista no destino, então você pode mover uma compilação local para um servidor completamente vazio sem configurar nada primeiro.

O PHP é Mais Novo no Seu Laptop do Que no Seu Host

Tudo funciona localmente, então o site ativo gera erros em páginas que usam recursos específicos de plugin ou tema.

Isso aparece cerca de três vezes mais em migrações de local para ativo do que em outras migrações, e se resume a como as ferramentas são empacotadas.

Ambientes de desenvolvimento local usam uma versão atual do PHP. Muitos hosts ativos ainda usam algo mais antigo por padrão, então funções que funcionaram no seu laptop são depreciadas ou ausentes no servidor.

Verifique ambos antes de migrar. Na sua ferramenta local, a versão do PHP geralmente é mostrada no painel de configurações do site.

No servidor, procure por Versão do PHP, Selecionar Versão do PHP ou Gerenciador MultiPHP. Combine-as e compile com base na versão que você realmente implantará.

A Importação do Banco de Dados Falha

O site ativo carrega um erro sobre o estabelecimento de uma conexão com o banco de dados, ou a instalação para na etapa do banco de dados.

Após uma migração, isso é quase sempre um problema de credenciais e não um banco de dados corrompido. O nome, usuário ou senha não correspondem ao que o servidor ativo criou.

Obtenha o nome do banco de dados, nome de usuário, senha e valor do host da sua conta de hospedagem ativa e insira-os cuidadosamente durante a etapa de instalação. Se o site já estiver no ar e falhando, esses valores estão em wp-config.php na pasta raiz do seu site, acessível através do gerenciador de arquivos do seu host ou um cliente FTP.

Permissões de Arquivo Não São Transferidas

A instalação para com um erro dizendo que não pode gravar um arquivo ou criar uma pasta.

Ambientes locais são permissivos porque você é a única pessoa usando-os. Servidores ativos são mais rigorosos. Propriedade e acesso de escrita que nunca importaram no seu laptop começam a importar aqui.

Defina as pastas para 755 e os arquivos para 644 no destino. Você pode alterar as permissões de arquivo através de um cliente FTP ou do gerenciador de arquivos do seu host, ambos mostram uma opção de permissões ou CHMOD ao clicar com o botão direito em uma pasta. A documentação do seu host confirmará o usuário correto do servidor web se você tiver dúvidas.

Você Não Consegue Fazer Login Após a Publicação

A migração termina, você tenta fazer login e a página de login te redireciona de volta ou entra em loop.

Isso causa mais pânico do que merece. Quase nunca significa que a migração falhou. O URL do site armazenado no banco de dados não corresponde a onde o site agora reside, então o WordPress continua redirecionando você para um endereço que não existe mais.

Corrija os campos Endereço do WordPress e Endereço do Site em Configurações » Geral, e então limpe seus cookies.

Se você não conseguir acessar o painel de controle de forma alguma, pode definir ambos os valores temporariamente em wp-config.php.

Algumas Referências Locais Sobrevivem à Migração

A maioria dos links funciona, mas algo ainda aponta para mysite.local.

As referências do banco de dados são reescritas durante a instalação. O que sobrevive é tudo o que reside fora do banco de dados: um URL codificado em um arquivo de tema ou tema filho, um caminho escrito em código personalizado, uma página em cache ou um serviço de terceiros ainda apontando para o seu endereço de desenvolvimento.

Pesquise no seu tema e código personalizado pelo domínio local, limpe qualquer plugin de cache e o cache do servidor do seu host, então recarregue. Se um serviço como CDN ou um formulário externo estiver envolvido, atualize o endereço do site nesse serviço também.

Uma Verificação Pré-Voo Antes de Você Enviar o Local para o Online

Você pode evitar a maioria dos erros do WordPress de local para produção com cerca de cinco minutos de preparação.

• Ative o SSL no servidor ativo. Este é o item de maior valor na lista, e fazê-lo primeiro é o que o faz funcionar.
• Compare as versões do PHP na sua ferramenta local e no seu servidor ativo, e combine-as.
• Tenha as credenciais do seu banco de dados ativo em mãos antes de iniciar a instalação.
• Saiba o URL ativo e espere que os endereços do site mudem com ele.
• Tenha o login do seu administrador pronto para que um loop de redirecionamento não o bloqueie do seu próprio site.

Se você quiser o guia passo a passo completo para a migração em si, nosso guia sobre migrar um site WordPress local para um servidor online detalha o processo. Este relatório trata das diferenças entre os dois ambientes e como resolvê-las com antecedência.

Duplicator Pro ajuda mais nas partes que falham aqui. O instalador autônomo move um site para um servidor em branco, mesmo um sem o WordPress instalado, e o DupArchive lida com grandes compilações locais sem travar na etapa de extração.

Perguntas Frequentes (FAQs)

A Lacuna Entre Seu Laptop e Seu Servidor

Todo problema neste relatório vem do mesmo lugar. Seu ambiente local e seu servidor online discordam sobre PHP, SSL, permissões ou o próprio nome do site. A migração é onde essas discordâncias surgem todas de uma vez.

Isso vale a pena reafirmar claramente porque muda a forma como você se prepara. A migração não é a parte arriscada. A incompatibilidade é.

Antes de compilar o site local, verifique a versão do PHP do host online e ative seu certificado SSL. Desenvolva contra o ambiente para o qual você vai implantar, e a maior parte deste relatório nunca se aplicará a você.

Antes do Seu Próximo Lançamento, Tenha um Caminho de Volta

Um site que falha no primeiro dia online é uma tarde ruim. Um site que falha sem uma cópia limpa para recorrer é muito pior.

Duplicator Pro é usado por mais de 1,5 milhão de profissionais WordPress para fazer backup, migrar e recuperar seus sites. Seu instalador autônomo move uma compilação local para um servidor em branco, e suas ferramentas de recuperação o colocam de volta se um lançamento der errado.

Enquanto você está aqui, estes outros recursos do WordPress valem a pena conferir:

• O que mais de 8.000 tickets de suporte revelam sobre por que as migrações do WordPress falham
• O que quebra os backups do WordPress: lições de mais de 1.400 tickets de suporte
• Seu Checklist Completo de Migração do WordPress (Do Início ao Fim)
• Como Mover um Site WordPress para um Novo Hospedeiro
• Como Restaurar um Site WordPress a Partir de um Backup