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:

	Premium	Padrão
PHP Workers	Igual ao seu ambiente de produção	1
CPU	12	1
RAM	8 GB	8 GB
CDN	Sim	Não
Edge Caching	Sim, pode ser ativado	Não

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 fácil possível. No MyKinsta, clique em Sites WordPress na navegação à esquerda. Você verá uma lista de seus sites/instalações. Selecione o site para o qual você deseja criar um ambiente de teste, clique na caixa Ir para ou pesquisar e selecione 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 ele estiver pronto, clique na caixa Ir para ou pesquisar e selecione 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 o ambiente para o ambiente de produção ou de teste

Você pode mover seu ambiente de teste WordPress para o ambiente de produção se estiver satisfeito com as alterações feitas e quiser que elas sejam aplicadas ao seu site de produção.

Você também pode mover seu ambiente ativo para o seu ambiente de teste. Isso é útil para atualizar o ambiente de teste para refletir as alterações feitas em seu ambiente ativo.

Com o recurso de mover seletivamente, você tem controle granular sobre o que mover. Especificamente, você pode mover:

• somente seus arquivos,
• somente o seu banco de dados,
• arquivos e pastas específicos,
• tabelas específicas do banco de dados,
• tudo.

A opção de mover ambientes pode ser feito com apenas alguns cliques, mas leia as observações abaixo antes de continuar. Elas contêm informações essenciais sobre o processo.

Observações importantes

• Recomendamos que você use a funcionalidade Mover Seletivamente com cautela, especialmente ao mover do ambiente de teste para o ambiente de produção. Inicie o processo em horários de pouco tráfego e tenha um desenvolvedor disponível caso surja algum problema. Se precisar da ajuda de um desenvolvedor, há vários locais onde você pode contratá-lo.
• Criamos um backup automaticamente para que você possa reverter o processo conforme necessário. Observação: Caso o seu site ativo for um site de eCommerce ou outro site dinâmico, que muda rapidamente, os dados poderão ser perdidos entre o momento em que você mover e o momento em que o backup for restaurado.
• As configurações do ambiente (redirecionamentos, geolocalização, configuração do PHP e do Nginx, etc.) são incluídas ao mover (mesmo que você selecione somente Arquivos ou Banco de dados) e substituirão completamente as configurações do ambiente.
• Após a conclusão de um envio do ambiente de teste para o ambiente de produção, limpe qualquer cache integrado no tema ou nos plugins, limpe o cache do navegador e teste o site para garantir que ele esteja funcionando conforme o esperado.
• Ao mover seu banco de dados, se você marcar a opção Executar Pesquisa e Substituição, o domínio será automaticamente substituído pelo domínio do ambiente para o qual você está movendo.
• Se você selecionar a opção Todos os arquivos e pastas, todos os arquivos serão movidos, inclusive plugins, temas e arquivos dentro de wp-content/uploads.
• Qualquer URL codificada diretamente no código do seu tema ou plugin precisará ser atualizada para a URL do ambiente.
• Se a proteção por senha (.htpasswd) estiver ativa no ambiente de origem, ela não será aplicada ao ambiente de destino. Você deve habilitá-la no ambiente de destino após o mover.
• Quando você usa WooCommerce, o MyKinsta não diferencia entre novos pedidos de clientes e os antigos ao mover o ambiente de teste para produção. Quando você inicia a opção de mover para produção, se você mover todos os arquivos e pastas, o MyKinsta copia seu site de teste para o site de produção exatamente como está, substituindo arquivos e o banco de dados. Para contornar isso, você pode:
  • Mover o site de teste para o site ativo com a opção de mover seletivamente e mover apenas arquivos para que seu banco de dados não seja substituído.
  • Mover seletivamente as tabelas do banco de dados e excluir as tabelas necessárias do WooCommerce.
  • Mover os arquivos de banco de dados da versão de produção para a versão de teste antes de mover a versão de teste para a versão de produção para garantir que você tenha os dados mais atualizados.
• 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. Você deverá discutir essa tarefa com seu desenvolvedor web. Se você não tiver um ou não tiver certeza, consulte nosso artigo sobre como contratar um desenvolvedor do WordPress.
• Quando você colocar o ambiente de teste em produção, verifique novamente o site de teste e resolva todos os erros antes de colocá-lo em produção.
• Os ambientes de teste destinam-se apenas a desenvolvimento e testes. Eles não foram projetados para serem usados como sites de produção, e pode haver coisas que não funcionem como esperado. A Kinsta não se responsabiliza se você tentar usar um ambiente de teste para um site ativo.
• O envio de um ambiente não afeta o ambiente do qual você está fazendo o envio, e ele permanecerá separado dos outros ambientes. Depois de mover um site de teste para o site ativo, você pode continuar desenvolvendo e testando as alterações no ambiente de teste sem afetar o site ativo até que você transfira as alterações para o site ativo novamente.
• O envio do site de teste para o site ativo não interferirá no CDN da Kinsta se ele estiver em execução no seu site ativo, mas recomendamos que você limpe o cache do CDN após mover (WordPress Sites > nome do site > Cache > CDN > Limpar cache CDN).
• Mova o site de teste para o site ativo com cuidado se o seu site for uma rede multisite. O envio do banco de dados pode ou não funcionar, dependendo de como o multisite está configurado. Se você usar o envio seletivo e o envio de Todas as tabelas do banco de dados ou Todas as tabelas do banco de dados e Todos os arquivos e pastas, todo o conteúdo do banco de dados será enviado para o ar e afetará todos os sites (o site principal e os subsites) na sua rede multisite.
• Se você usar uma configuração não padrão do WordPress, como Bedrock ou Trellis, a Kinsta poderá não conseguir localizar a variável DB_PASSWORD e, portanto, não conseguirá atualizar a senha do banco de dados quando você mover o ambiente de teste para o ar. Nesse cenário, quando você colocar o ambiente no ar, deverá atualizar manualmente o arquivo no qual define o DB_PASSWORD com a nova senha do banco de dados, conforme definido no MyKinsta.

Mover um ambiente com a opção de mover seletivamente

Siga as etapas abaixo para mover seu ambiente para outro ambiente. O fluxo de trabalho para envio seletivo permite que você escolha o que mover.

1. Selecione seu ambiente

Faça login no MyKinsta, clique em Sites WordPress e clique no ambiente do qual você deseja mover. Se você adicionou um ambiente de teste Premium, terá mais de um ambiente de teste para escolher.

2. Mover ambiente

No ambiente, clique em Mover Seletivamente e selecione Mover o ambiente para no menu suspenso.

3. Selecione quais arquivos e tabelas do banco de dados você deseja mover

No pop-up/modal Mover o ambiente para que aparece, escolha uma das seguintes opções:

• Arquivos > Todos os arquivos e pastas: Move todos os arquivos e pastas para o ambiente selecionado.
• Arquivos > Arquivos e pastas específicos: Escolha exatamente quais arquivos e pastas você deseja mover para o ambiente selecionado. Você pode usar a área de texto para definir um caminho/pasta/arquivo específico a ser enviado. Para obter mais informações sobre a finalidade de cada arquivo no WordPress, consulte o nosso Guia completo sobre arquivos do WordPress e como usá-los.
• Banco de dados > Todas as tabelas do banco de dados: Move todas as tabelas do banco de dados para o ambiente selecionado.
• Banco de dados > Tabelas específicas do banco de dados: Escolha exatamente quais tabelas do banco de dados você deseja mover para o ambiente selecionado. Para obter mais informações sobre o banco de dados do WordPress, consulte Guia para iniciantes no banco de dados do WordPress: O que é e como acessá-lo.

Digite o nome do site para confirmar e clique em Mover para o ambiente.

Alguns aspectos que você deve ter em mente são:

• O tempo necessário para que o processo seja concluído depende do tamanho do seu site.
• O MyKinsta notificará você quando o processo for concluído.
• Ao mover do ambiente de teste para Produção, seu site sofrerá alguns segundos de inatividade nos estágios finais do processo.
• As configurações do ambiente (redirecionamentos, geolocalização, configuração do PHP e do Nginx, etc.) são incluídas ao mover (mesmo que apenas Arquivos ou Bancos de Dados sejam selecionados) e substituirão completamente as configurações do ambiente.

Casos de uso e exemplos de fluxos de trabalho

Abaixo, descrevemos alguns exemplos de quando você pode querer mover apenas arquivos, apenas o banco de dados ou ambos.

Mover somente os arquivos e pastas

• Alterações feitas diretamente nos arquivos de tema (incluindo HTML, CSS ou PHP) que não salvam nenhum dado no banco de dados.
• Carregamento de um arquivo que não precisa ser incluído na Biblioteca de mídia do WordPress.
• Se você tiver um plugin personalizado em seu site e fizer alterações nos arquivos que não afetam o banco de dados (não salvam nem alteram dados no banco de dados).

Mover arquivos e pastas específicos

• Se você fizer alterações em um único tema, poderá mover a pasta específica do tema dentro da pasta themes.
• Se você testar uma nova versão de um plugin no ambiente de teste, poderá mover a pasta específica do plugin para a pasta plugins.
• Você pode mover alterações para a versão ativa de definições ou arquivos de configuração específicos definindo o caminho/pasta/arquivo a ser enviado na área de texto.

Mover somente o 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 outros: comentários, novo conteúdo, compras em sites de eCommerce, inscrições em sites de membros e artigos em fóruns.

• Criação ou edição de um novo artigo ou página que não inclua nenhuma mídia carregada (imagem, vídeo ou outros arquivos carregados).
• Alterações de layout em uma página ou artigo feitas por meio de um plugin do construtor.
• Alteração do título ou da tagline do site.

Mover tabelas específicas do banco de dados

• Se você testar um plugin ou tema personalizado do WordPress no ambiente de teste que exija uma atualização específica da tabela do banco de dados em seu ambiente de produção.
• Se você reorganizar tabelas de dados específicas ou corrigir problemas com as tabelas em seu ambiente de teste e quiser mover apenas as novas tabelas para o ambiente de produção.
• Se você alterar os dados relacionados ao usuário ou as funções do usuário no ambiente de teste e quiser mover apenas as tabelas do banco de dados do usuário para o ambiente de produção.

Mover tudo

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 outros: comentários, novo conteúdo, compras em sites de eCommerce, inscrições em sites de membros e artigos em fóruns.

• Criação de novo conteúdo que inclua mídia carregada (imagem, vídeo ou outros arquivos carregados).
• Alterações no seu tema feitas no Customizer e nos arquivos do tema.
• Instalação e teste de um novo plugin ou de uma versão atualizada de um plugin.

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.

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 PHP workers, 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 você tiver um multisite de subdiretório (exemplo.com, exemplo.com/subsite1, exemplo.com/subsite2), ele funcionará bem com nosso ambiente de teste.
• Se for um multisite de subdomínio (exemplo.com, subsite1.exemplo.com, subsite2.exemplo.com), ele funcionará bem, desde que os subsites não exijam HTTPS.
  • Se for um Multisite de subdomínio que exija HTTPS, você precisará adicionar um domínio personalizado com um certificado SSL wildcard ao seu site de teste para que os subdomínios possam ser cobertos por um certificado SSL. Isso ocorre porque o certificado SSL fornecido para a URL de teste padrão só pode cobrir o subdomínio de teste (por exemplo, stg-sitename-environmentname.kinsta.cloud), portanto, qualquer nível de subdomínio adicional (por exemplo, subsite.stg-sitename-environmentname.kinsta.cloud) não pode ser coberto.
• 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 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. Alterne para o ambiente que você deseja renomear e clique no ícone de edição (lápis) na seção Nome do ambiente 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 de dados não esteja 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.