A versão duplicada de um site local (WordPress) não está disponível on-line em um ambiente Nginx

Question

No meu ambiente Ubuntu 16.04 Nginx, tentei criar uma versão de teste online de um site WordPress local. O site original funciona bem e é acessado em HTTPS (o símbolo de bloqueio é verde em todas as páginas).

Meu estado atual e problema

Quando navego até my_ip_addrres/test chego a uma página 404 no site original (o site local que desejo duplicar), apesar de o URL permanecer my_ip_addrres/test . Além disso, todos os links do menu principal nessa página 404 com my_ip_addrres/test URL apontam para o site original.

Meu estado final desejado

Quando eu navegar para my_ip_addrres/test em qualquer navegador, acessarei a versão duplicada do site original e operarei da mesma forma que operaria o site original, para que eu possa ir para my_ip_addrres/test/wp-admin , faça o login e altere o site de teste.

O que eu fiz até agora para duplicar o site original

Eu basicamente fiz tudo com os seguintes comandos bash. Por favor, use estes se você deseja reproduzir no seu final:

cd /var/www/html/
read domain # Domain of the site for duplication.
read -s rps # Password for Mysql root user.
read -s sps # Password for Mysql DB user.

cp -r ./${domain} ./test/
sed -i "s/${domain}/test"/g ./test/wp-config.php
cp -r /etc/nginx/sites-available/${domain}.conf /etc/nginx/sites-available/test.conf
sed -i "s/${domain}/test"/g /etc/nginx/sites-available/test.conf
ln -s /etc/nginx/sites-available/test.conf /etc/nginx/sites-enabled/test.conf

echo "CREATE USER 'test'@'localhost' IDENTIFIED BY \"${sps}\";" | mysql -u root -p"${rps}"
echo "CREATE database test;" | mysql -u root -p"${rps}"
echo "GRANT ALL PRIVILEGES ON test.* TO test@localhost;" | mysql -u root -p"${rps}"

mysqldump -u root -p"${rps}" "${domain}" > test.sql
mysql -u test -p"${sps}" test < ./test.sql

cd test 
wp search-replace "${domain}" "MY_IP_ADDRESS/test" --allow-root

Mais detalhes

1) Eu tive cerca de 1300 substituições no banco de dados depois de executar o comando WP-CLI de pesquisa e substituição acima.

2) /var/www/html/test/wp-config.php :

define('DB_NAME', 'test');
define('DB_USER', 'test');

Nginx confs

• /etc/nginx/nginx.conf
• Conf do site original (domínio omitido)
• /etc/nginx/sites-available/test.conf (eu mudei manualmente e reiniciei o servidor)

Registros:

nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

tail /var/log/nginx/error.log
tail /var/log/nginx/access.log

• As duas caudas não mostram erros em relação a /var/www/html/test/ .

Minha pergunta

O que continua a ser uma causa possível para o site de teste não subir de my_ip_addrres/test ? Como um novato Nginx, eu realmente sinto que tentei tudo no arsenal ...

    

Answer 1

I really don't need anything beyond accessing it directly from the IP

Opções :

1. Basta poupar uma dor de cabeça e meia e usar um nome de domínio test.example.com. Você nem precisa publicar registros DNS válidos apenas edite o arquivo HOSTS local. E adicione uma diretiva de nome de servidor ao arquivo test.conf.
2. Você precisa garantir que a configuração de teste seja a primeira configuração carregada. Altere o nome do arquivo nos sites habilitados para 000-test.conf Isso significa que qualquer pessoa que fizer algo bobo verá o seu site de teste.
3. Adicione uma diretiva de nome do servidor ao test.conf com o IP do servidor
4. Incluir manualmente os arquivos de configuração individuais em ordem, em vez de todo o sites-enabled

Explicação

Coloque um arquivo HelloWorld.html em /var/www/html/example.com/test/ . Navegue até IP_ADDRESS/test/HelloWorld.html e você verá o conteúdo do seu arquivo. Como suas configurações não têm server { ... } com servername que corresponde a http://YOUR_IP/ , ele usa o primeiro server { ... } como padrão. Estatisticamente falando example.com.conf é carregado antes de test.conf

Nginx Está procurando int% errado root para o seu arquivo porque o site principal é o padrão.

Recomendação

Use a opção 1 ou 3. Seu site ativo deve provavelmente ser o site padrão que os visitantes veem. Eu optaria pela opção 1 porque permite que você "oculte" ainda mais o seu site de teste. A opção 3 fará o " link " mas, por motivos acima, ainda prefiro a opção 1.