Ambientes de Teste

Cada instalação de WordPress na Kinsta pode ter seu próprio ambiente de teste gratuito do WordPress, completamente separado do site de produção. Isso é ótimo para você testar novas versões do WordPress, plugins, código e trabalho de desenvolvimento geral. Crie um site de desenvolvimento em minutos e compartilhe com sua equipe.

Se você deseja adicionar ambientes de teste adicionais, precisa de um ambiente de teste que se aproxime mais do seu ambiente de produção ou precisa realizar testes, ou desenvolvimento de sites que demandem muitos recursos, confira nosso complemento de ambiente de teste Premium.

Ambiente de teste padrão vs Premium

Você pode adicionar até 5 ambientes de teste Premium, que incluem mais recursos e muito mais funcionalidades do que o ambiente Padrão. A tabela a seguir mostra as diferenças entre nossos ambientes de teste Padrão e Premium:

Saiba mais sobre nosso complemento de ambientes de teste Premium.

Crie um ambiente de teste Padrão ou Premium

Tornamos a criação de um site de teste WordPress o mais simples possível. No MyKinsta, clique em Sites WordPress no menu de navegação à esquerda. Você verá uma lista dos seus sites/instalações. Selecione o site para o qual deseja criar um ambiente de teste, clique no tipo de ambiente, por exemplo, Produção, e selecione Criar novo ambiente. Você também pode clicar em Ir para ou usar a caixa de pesquisa e selecionar Criar novo ambiente.

Na janela modal/pop-up Criar novo ambiente que aparece, selecione o ambientePadrão ou Premium e clique em Continuar.

Em seguida, você será solicitado a selecionar o tipo de ambiente que deseja criar. Há três opções.

1. Clonar um ambiente existente: Essa opção permite que você clone um ambiente existente (de produção ou qualquer ambiente de teste Premium) para o novo ambiente de teste.
2. Instalar um novo WordPress: Essa opção instala um site WordPress em branco totalmente funcional, pronto para você usar imediatamente.
3. Ambiente vazio (sem WordPress): Essa opção instala todo o software necessário para executar um site WordPress (servidor web, PHP, MySQL, etc.), mas não instala o WordPress propriamente dito. Essa é uma boa opção para usuários que estão migrando para a Kinsta com o Duplicator ou configurando uma instalação do Bedrock/Trellis com uma estrutura de arquivos personalizada.

Opção 1 – Clonar um ambiente existente

A opção Clonar um ambiente existente permite que você clone qualquer ambiente existente (ambiente de produção ou de teste Premium) para o novo ambiente de teste.

• Nome do ambiente: Digite um nome para o nome do ambiente de teste; ele deve ter entre 3 e 12 caracteres.
• Ambiente a ser clonado: Escolha um ambiente existente para clonar no novo ambiente de teste.

Opção dois – Instalar novo WordPress

A opção Instalar novo WordPress inclui vários campos para você personalizar seu site. Veja a seguir o que você precisa saber sobre cada campo.

• Nome do ambiente: Digite um nome para o ambiente de teste; ele deve ter entre 3 e 12 caracteres.
• Título do site WordPress: Isso permite que você defina o título do site para o seu site WordPress. Dependendo do seu tema, ele ficará visível para os visitantes do site na aba do navegador e em outros locais. Você pode alterar o título do site nas configurações do WordPress após a criação do site.
• Nome de usuário do administrador do WordPress: Você usará esse nome para fazer login na instalação do WordPress. Você poderá adicionar outros usuários posteriormente. Recomendamos que você escolha outro nome de usuário que não seja “admin” para obter o máximo de segurança.
• Senha de administrador do WordPress: Você usará essa senha para fazer login na sua instalação. Aplicamos automaticamente senhas fortes para proteger os usuários. Você pode usar a opção gerar nova senha (ícone de recarga) se quiser uma nova senha. Veja como você pode alterar sua senha do WordPress mais tarde.
• E-mail do administrador do WordPress: O WordPress usa o endereço de e-mail do administrador para mover notificações importantes.
• Selecione um idioma: Selecione o idioma que você gostaria de usar no WordPress. Você não precisa escrever conteúdo no mesmo idioma da interface do WordPress, portanto, fique à vontade para escolher seu idioma nativo, mesmo que esteja escrevendo conteúdo em inglês.
• Instalar o WordPress multisite: Selecione essa caixa se você quiser criar uma instalação WordPress Multisite. Uma vez selecionada, você pode escolher entre uma instalação de subdomínio ou subdiretório.
• Instalar o WooCommerce: Se você estiver criando um site de eCommerce, o WooCommerce é o plugin de eCommerce mais popular que existe. Marque essa caixa para instalá-lo automaticamente.
• Instalar o Yoast SEO: O Yoast SEO é o plugin de SEO mais popular para WordPress, com mais de 3 milhões de instalações e uma classificação de 5 em 5 estrelas. Marque essa caixa para instalá-lo automaticamente.
• Instale o Easy Digital Downloads: Se você estiver criando um site para vender produtos digitais, o Easy Digital Downloads é uma solução completa de eCommerce para a venda de produtos digitais. Marque essa caixa para instalá-lo automaticamente.

Opção três – Ambiente vazio (sem WordPress)

A opção Ambiente vazio é útil para usuários que precisam de um ambiente vazio para migração do Duplicator ou teste de instalação personalizada do Bedrock/Trellis.

• Nome do ambiente: Digite um nome para o ambiente de teste; ele deve ter entre 3 e 12 caracteres.

Criação do ambiente de teste

Quando você estiver pronto, clique em Continuar. Se você estiver criando um ambiente de teste Premium, confirme a assinatura recorrente e clique em Criar ambiente Premium.

Acesso ao seu ambiente de teste

A criação do novo ambiente pode levar alguns minutos. Quando estiver pronto, dentro do site, clique no tipo de ambiente (por exemplo, Produção) e selecione o ambiente de teste. Você também pode clicar em Ir para ou usar a caixa de pesquisa para selecionar o ambiente.

Você também pode acessar o ambiente de teste na lista Sites WordPress.

Cada ambiente tem um círculo codificado por cores ao lado de seu nome: Verde para Produção, preto para Teste Padrão e laranja para Teste Premium. Você terá um painel de controle separado com informações de conexão, DNS, backups, ferramentas e plugins para o seu ambiente de teste.

Para acessar rapidamente o site de teste, vá para a aba Domínios no ambiente de teste e clique no link Abrir URL. Você também pode acessar rapidamente o administrador do WordPress do seu site de teste clicando no link Abrir administrador do WordPress.

Estrutura de URL e domínio

A estrutura de URL padrão do seu ambiente de teste segue este formato:

• Padrão: https://stg-sitename-environmentname.kinsta.cloud
• Premium: https://env-sitename-environmentname.kinsta.cloud

Se você tiver um site de teste mais antigo, seu URL poderá se parecer com um destes:

• https://staging-sitename-environmentname.kinsta.cloud
• https://staging-sitename.kinsta.cloud
• https://staging-sitename.kinsta.com

Você também pode adicionar um domínio personalizado ao seu site de teste se preferir usar um domínio personalizado.

Observações adicionais

Se você tiver o SSL ativado no site ativo e clonar o site para teste, o SSL também será ativado no site de teste.

Você pode iniciar o phpMyAdmin diretamente no MyKinsta. Na aba Informações, clique no link Abrir phpMyAdmin. A estrutura de URL para o phpMyAdmin staging segue este formato:

https://mysqleditor-stg-sitename-environmentname.kinsta.cloud

Atualizar o ambiente de teste

Se você fizer alterações no seu site de produção após criar o ambiente de teste e quiser refletir essas alterações no ambiente de teste, pode usar o mover seletivamente para atualizar o ambiente de teste. Dessa forma, você não precisa excluir e recriar o ambiente de teste, economizando tempo e mantendo qualquer backup do ambiente de teste.

Mover ambiente para produção

Quando estiver pronto para mover o ambiente de teste para o ambiente de produção, siga as etapas descritas em Mover ambientes. Você também pode mover qualquer ambiente, de produção ou de teste para outro site.

Excluir e atualizar o ambiente de teste

Se você precisar remover seu site de teste, vá para Sites WordPress e selecione o ambiente de teste que deseja remover. Role até a parte inferior da página e clique em Excluir ambiente.

Na janela modal/pop-up exibida, confirme que você entende o que será excluído, digite o nome do site seguido de um traço e a palavra “staging” (SITENAME-environmentname) no campo fornecido e clique em Excluir ambiente.

Para atualizar seu ambiente de teste, exclua, crie um novo e escolha a Opção 1 – Clonar um ambiente existente. Esse ambiente de teste recém-clonado conterá a versão mais recente do seu banco de dados de produção e arquivos para teste.

Como alternativa, você pode restaurar um backup do site de produção para o ambiente de teste. A vantagem desse método é que, se você tiver adicionado um domínio personalizado, ele não será excluído e você não precisará adicioná-lo sempre que atualizar o ambiente de teste.

Restaurar um backup do WordPress para o ambiente de teste

Você pode restaurar seu site WordPress a partir de um backup diretamente no ambiente de teste existente. Veja como restaurar um backup do WordPress para o ambiente de teste. Observação: todos os backups do ambiente de teste permanecerão intactos quando você restaurar um backup ativo para o ambiente de teste.

Reiniciar o ambiente de teste

Em determinadas situações, podemos interromper um ambiente de teste como parte de um processo de solução de problemas do servidor. Se você perceber que seu ambiente de teste foi interrompido e ver um erro 501 não implementado, um erro 502 ou um erro 521 ao visitar seu site, poderá reiniciar o ambiente de teste no MyKinsta acessando a página de informações do seu site e clicando em Iniciar ambiente de teste.

Se você não conseguir reiniciar seu ambiente de teste ou não vir o botão no MyKinsta, abra um novo bate-papo com nossa equipe de suporte para obter mais assistência.

Remover um ambiente de teste

Depois de concluir seus testes ou desenvolvimento, você pode remover o ambiente de teste. Se você usar um complemento de ambiente de teste Premium, só será cobrado pelo tempo em que ele estiver ativo; quando você excluir o ambiente de teste Premium, isso cancelará o complemento e interromperá a cobrança adicional.

Se você remover o complemento de ambiente de teste premium e estiver nos primeiros 30 dias do seu plano de Hospedagem para WordPress, uma taxa rateada será adicionada à sua próxima fatura, proporcional ao período em que o complemento esteve ativo. Se o seu plano de hospedagem para WordPress estiver ativo há mais de 30 dias, você receberá um crédito rateado referente às taxas do complemento, proporcional aos dias restantes do período de cobrança atual. Esse crédito será automaticamente usado para abater valores devidos à Kinsta na sua próxima fatura. Para mais informações, consulte nossa Garantia de Reembolso da Hospedagem para WordPress.

No MyKinsta, clique em Sites WordPress e selecione o ambiente que você deseja remover.

Role até a parte inferior da página e clique em Excluir ambiente.

Na janela modal/pop-up exibida, confirme que você entende o que será excluído, digite o nome do site seguido de um traço e o nome do ambiente (SITENAME-EnvironmentName) no campo fornecido e clique em Excluir ambiente.

Se você estiver usando um ambiente de teste Premium, depois que o ambiente de teste for excluído, a assinatura do complemento será automaticamente removida de Empresa > Meu plano no MyKinsta.

Observações importantes

Quando você usa o ambiente de teste, há várias coisas importantes que devem ser observadas.

1. Configurações de cache de página para sites de teste

Como os ambientes de teste são para fins de desenvolvimento, depuração e testes, o cache de página inteira e o OPcache da Kinsta são desativados por padrão. Se você executar testes de velocidade do site, verá tempos de carregamento acima da média, pois as páginas não estão sendo servidas a partir do cache. Se você quiser habilitar o cache em um site de teste no ambiente de teste, clique em Cache > Cache do servidor > Habilitar. Quando o cache estiver ativado em um site de teste, a opção Limpar cache será habilitada e poderá ser usada para limpar o cache. Se você tiver um ambiente de teste Premium, também poderá habilitar o CDN e o Edge Caching.

2. Credenciais do ambiente de teste

Se o ambiente de teste for um clone do seu site de produção, as credenciais de login do administrador do WordPress serão as mesmas para os sites ativo e de teste, a menos que você as altere após criar o ambiente de teste.

3. SEO

Por padrão, a indexação é desativada para os sites de teste, para que eles não prejudiquem o SEO do seu site ativo/produção. Isso é feito com a combinação de uma configuração do WordPress e um cabeçalho HTTP que adicionamos automaticamente.

Você pode ver a configuração do WordPress acessando Configurações > Leitura no painel do WordPress do seu site de teste. A opção para desencorajar os mecanismos de pesquisa de indexar o site está marcada ao lado de Visibilidade do mecanismo de pesquisa.

As URLs temporárias da Kinsta e as URLs de teste também têm um cabeçalho HTTP X-Robots-Tag: noindex, nofollow, nosnippet, noarchive de restrição de robôs, o que significa que as URLs temporárias não serão indexados pelos mecanismos de pesquisa. Esses cabeçalhos não podem ser removidos das URLs temporárias da Kinsta ou das URLs de teste. Se você precisar que esses cabeçalhos sejam removidos do site de teste, será necessário adicionar um domínio personalizado a ele.

4. Plugins

Se você usa plugins de agendamento social, como CoSchedule ou Social Networks Auto Poster, é recomendável desativar esses plugins em seu site de teste. Caso contrário, você poderá começar a compartilhar nas redes sociais usando a URL de teste, que será semelhante a: https://stg-sitename-environmentname.kinsta.cloud. Isso pode distorcer suas análises.

Alguns plugins, como o plugin Jetpack, serão executados automaticamente no modo de teste nos ambientes de teste da Kinsta. Você verá uma mensagem: “Você está executando o Jetpack em um servidor de teste” Enquanto estiver no modo de teste, seu site de teste agirá como seu site de produção em praticamente todos os aspectos, exceto que nenhum dado é passado para o WordPress.com e você não pode desconectar o site de teste (para evitar um problema que levaria a problemas com seu site de produção).

Os plugins licenciados por nome de domínio podem exigir um domínio personalizado (em vez de um subdomínio de teste da Kinsta) para que você funcione corretamente. Observação: depois de adicionar um nome de domínio personalizado ao seu site de teste, talvez seja necessário atualizar as configurações onde você gerencia a licença do plugin ou entrar em contato com a equipe de suporte do plugin.

5. Anote a URL de login

Se você clonar seu site para a fase de teste e usar um plugin do WordPress que altere a URL de login padrão, a parte personalizada do URL será copiada para o site de teste. Exemplo: http://stg-sitename-environmentname.kinsta.cloud/yourcustomlogin

6. O ambiente de teste deve ser usado somente para desenvolvimento/testes

O ambiente de teste padrão tem apenas 2 threads PHP, não tem a opção de habilitar o CDN da Kinsta e pode entrar em suspensão após 24 horas de inatividade. Portanto, ele deve ser usado apenas para desenvolvimento e testes. Os ambientes de teste (Padrão e Premium) não foram projetados para serem usados em sites de produção, e pode haver coisas que não funcionem corretamente. A Kinsta não se responsabiliza se você tentar usar um ambiente de teste para um site ativo.

7. Espaço em disco excluído do total do plano

Para que você tenha o máximo de espaço possível, os sites de teste são excluídos de nossos relatórios ao calcular o uso total de espaço em disco. Somente os sites ativos contam para o uso do espaço em disco.

8. Cron jobs

Os Cron jobs do servidor do ambiente de produção não estão ativos no ambiente de teste (mesmo que você clone o site ativo para a teste), portanto, os trabalhos cron do site ativo não serão disparados no ambiente de teste. Além disso, se você modificar o crontab no ambiente de teste e mover o ambiente de teste para o ambiente ativo, ele substituirá o crontab do ambiente ativo.

9. Multisite

Se você estiver executando uma rede multisite de WordPress, ela poderá ou não funcionar com nosso ambiente de teste, dependendo de como o multisite estiver configurado.

• Se for um multisite de subdiretório (exemplo.com, exemplo.com/subsite1, exemplo.com/subsite2) ou de subdomínio (exemplo.com, subsite1.exemplo.com, subsite2.exemplo.com), funcionará normalmente com nosso ambiente de teste. Todos os subdomínios são cobertos pelo certificado SSL gratuito da Kinsta.
• Se for um multisite mapeado por domínio (carrega diferentes subsites em domínios completamente diferentes, por exemplo, exemplo.com, example1.com, example2.com), ele não funcionará sem uma configuração manual significativa.
  • Opção 1: Desative o mapeamento de domínio e volte à configuração padrão de subdiretório/subdomínio. Faça uma pesquisa e substituição no banco de dados manualmente.
  • Opção2: Configure subdomínios de teste para cada domínio ativo, adicione todos eles ao site de teste e execute manualmente uma pesquisa e substituição no banco de dados.

10. E-mail

Os ambientes de teste têm o envio de e-mails (e-mail transacional) ativado por padrão. Se você fizer um pedido no site de teste, receberá e-mails relacionados do site de teste. Se não quiser que os e-mails transacionais sejam enviados do seu ambiente de teste, você poderá usar um plugin como Disable Emails para impedir que o site envie e-mails.

PERGUNTAS FREQUENTES

O que é rateio?

Quando rateamos um serviço como o complemento de ambiente de teste Premium, isso significa que você será cobrado com base no tempo em que o serviço esteve em uso nesse ciclo de fatura mensal.

Exemplo de rateio

Você tem um novo recurso a ser implementado em seu site e deseja testá-lo com todo o poder do seu plano. Você cria um ambiente de teste Premium, adiciona o novo recurso e o testa por 1 hora. Tudo parece ótimo, então você transfere a alteração para o ambiente ativo e exclui o ambiente de teste Premium.

• 1 mês de um ambiente de teste Premium custa US$ 20.
• Com base em um mês de 30 dias, esse ciclo de cobrança tem um total de 720 horas.
  30 * 24 = 720
• Cada hora de uso custa US$ 0,03.
  $20 / 720 = $0.03
• Sua próxima fatura incluirá os US$ 0,03 devidos pela 1 hora em que um ambiente de teste Premium foi adicionado ao seu plano.

Exemplo de rateio

Você compra um ambiente de teste Premium no meio do seu ciclo de cobrança mensal e o utiliza até o final desse ciclo. Você será cobrado por meio mês de uso (aproximadamente US$ 10, rateados até o segundo).

Posso alterar o nome de um ambiente de teste?

Sim. Altere para o ambiente que deseja renomear e, na página Informações, clique no ícone de edição (lápis) no campo Nome do ambiente.

Digite o novo nome e clique em Renomear ambiente.

Isso mudará o nome do ambiente mostrado no seletor de ambiente, mas não afetará o domínio kinsta.cloud gerado durante a criação inicial do ambiente.

Posso restaurar um backup em um ambiente de teste?

Sim, mas você deve criar um ambiente de teste Padrão ou Premium primeiro. No passado, era possível criar um ambiente de teste automaticamente ao restaurar um backup. Com a introdução dos Ambientes de teste Premium, você precisará primeiro criar o ambiente de teste antes de restaurar um backup.

Você também pode mover alterações do seu site de produção (ativo) para o site de teste e, se quiser atualizar apenas determinados arquivos ou tabelas do banco de dados, poderá mover seletivamente.

Quem tem acesso aos ambientes de teste Premium?

Os desenvolvedores e administradores de sites têm acesso aos ambientes de teste Premium que foram criados, mas não podem criar ou excluir um ambiente de teste Premium. Somente o proprietário ou o administrador da empresa pode criar, ou excluir um ambiente de teste Premium.

O ambiente de teste utiliza meu espaço em disco?

Não. Para que você tenha o máximo de espaço possível, os sites de teste são excluídos de nossos relatórios ao calcular o uso total de espaço em disco. Somente os sites ativos contam para o limite de espaço em disco que você tem.

Se eu testar um plugin no ambiente de teste e mover apenas os arquivos para o ambiente ativo, ele criará as tabelas do banco de dados correspondentes para o plugin?

Se você instalar um plugin em seu site de teste que nunca tenha sido instalado no site ativo, o envio apenas dos arquivos do ambiente de teste para o ativo não criará as tabelas do banco de dados para esse plugin.

Isso também significa que todas as configurações que você definiu no plugin não serão enviadas para o site ativo (a menos que as configurações sejam salvas em um arquivo fora do banco de dados, como em um arquivo JSON, por exemplo).

Dependendo de como o plugin é codificado, a ativação (primeiro a desativação, se necessário) do plugin no site ativo pode criar a estrutura do banco de dados.

Se eu mover somente os arquivos para o site ativo, isso significa que o banco de dados antigo (em teste) não substituirá o banco de dados ativo e somente os arquivos serão substituídos?

Sim, ao mover somente os arquivos, isso significa que o banco de dados no site ativo permanecerá inalterado e somente os arquivos no site ativo serão substituídos.

Isso significa que posso trabalhar em alterações de design no meu site de teste e transferi-las para o site ativo sem perder novos assinantes ou clientes no site ativo?

Sim, contanto que as alterações sejam feitas somente nos arquivos (nenhuma alteração feita no painel do WordPress, incluindo configurações de plugin, tema ou personalizador), você pode enviá-las com segurança para o site ativo sem mover o banco de dados. Quando você mover as alterações para o ar, selecione Arquivos e certifique-se de que o Banco dedados nãoesteja selecionado.

Posso excluir ou sincronizar pedidos, ou dados do WooCommerce ao mover da fase de teste para a produção?

Sim, quando você mover da fase de testes para a produção com a opção de mover seletivamente, poderá mover apenas arquivos para que seu banco de dados não seja substituído, ou pode mover seletivo de tabelas do banco de dados e excluir as tabelas necessárias do WooCommerce. Para obter informações sobre o que está incluído em cada tabela do banco de dados do WooCommerce, consulte a Descrição do banco de dados do WooCommerce. Se você não tiver certeza de quais tabelas mover, recomendamos que trabalhe com um desenvolvedor.

Posso transferir apenas um site da versão de teste para a versão de produção se eu tiver um Multisite?

Sim, quando você move o ambiente teste para a produção com a opção de mover seletivamente, pode optar por mover apenas as tabelas do banco de dados de um dos subsites. Para saber quais tabelas do banco de dados estão incluídas no WordPress, consulte o Guia para iniciantes no banco de dados do WordPress: O que é e como acessá-lo. Nos arquivos, as pastas de plugins e temas são compartilhadas em todos os sites, mas a pasta de uploads pode ser separada por site; portanto, você pode optar por mover apenas os uploads para o subsite necessário. Se você não tiver certeza de quais tabelas ou arquivos devem ser enviados, recomendamos que trabalhe com um desenvolvedor.

Posso usar a opção de mover seletivamente para alterar a versão do PHP do meu site?

Sim, você pode usar o ambiente de teste para testar e mover uma nova versão do PHP para o ambiente ativo, mas não é estritamente necessário mover do ambiente de teste para o ambiente ativo para atualizar a versão do PHP. Aqui está uma breve introdução de como você poderia alterar a versão do PHP sem mover do ambiente de teste para a produção:

1. Crie um site de teste.
2. Vá para o site de teste e altere a versão do PHP no site de teste.
3. Se tudo estiver bem e funcionando conforme o esperado no site de teste (certifique-se de testar seu site completamente), mude a versão do PHP no site ativo.

Fiz alterações de CSS no painel do WordPress e enviei os arquivos. Por que não estou vendo minhas alterações, mesmo depois de limpar todo o cache?

Dependendo do tipo de alteração feita e de onde essas informações estão armazenadas, talvez você precise mover o banco de dados ou fazer essas alterações manualmente no site ativo. Por exemplo, se você adicionou ou editou CSS em um bloco, ou widget no painel do WordPress, isso provavelmente seria salvo no banco de dados.

Se você fizer alterações em algo no painel do WordPress, com exceção das alterações feitas com o Theme Editor (Appearance > Theme Editor), essas informações geralmente são armazenadas no banco de dados.

Observação: todas as alterações no banco de dados do site ativo desde que o site de teste foi criado serão perdidas, incluindo, entre outras: comentários, novo conteúdo, compras em sites de eCommerce, inscrições em sites de membros e artigos em fóruns. Nesse caso, recomendamos que você faça as mesmas alterações manualmente no site ativo em vez de mover o banco de dados.

Como a opção de mover seletivamente funciona em uma rede multisite?

Se você usar a opção de mover seletivamente para mover apenas os arquivos, ele funcionará bem, independentemente do tipo de rede multisite. Se você mover apenas o banco de dados ou o banco de dados e os arquivos, isso poderá ou não funcionar, dependendo de como o multisite estiver configurado:

• Se for um multisite de subdiretório (exemplo.com, exemplo.com/subsite1, exemplo.com/subsite2), o Mover para produção funcionará como esperado.
• Se for um multisite de subdomínio (exemplo.com, subsite1.exemplo.com, subsite2.exemplo.com), funcionará bem, desde que os subsites não exijam HTTPS.
• Se for um multisite mapeado por domínio (carrega diferentes subsites em domínios completamente diferentes, por exemplo, exemplo.com, example1.com, example2.com), ele não funcionará sem uma configuração manual significativa.
  • Opção 1: Desative o mapeamento de domínio e volte à configuração padrão de subdiretório/subdomínio. Faça uma pesquisa e substituição no banco de dados manualmente.
  • Opção 2: Configure subdomínios de teste para cada domínio ativo, adicione todos eles ao site de teste e execute uma pesquisa e substituição no banco de dados manualmente para atualizar cada domínio depois de mover o ambiente de teste para o ativo.