Quando crias um site de staging predefinido, localizado numa subpasta, o WP STAGING define a opção “Permalinks” do site de staging como “Plain” e desativa a opção “Post name permalinks”. Isto serve para garantir que o site de staging abre corretamente em todos os tipos de servidores.
Contents
A versão Pro do WP STAGING tem a opção “Keep permalinks“. Sempre que crias um novo site de staging e ativas esta opção, o site de staging usa exatamente a mesma estrutura de permalinks do site em produção. Encontras esta opção em WP STAGING > Settings > Keep Permalinks.
Se ativares esta opção e o site de staging te redirecionar para o site em produção ou mostrar um erro 404, segue este artigo!
Em geral, podes usar permalinks simples num site de staging sem problemas. Muitas vezes, não há necessidade técnica de ativar permalinks personalizados para tirar partido de um site de staging.
Ainda assim, se queres ativar permalinks personalizados no teu site de staging para teres a mesma estrutura de links, vais primeiro precisar de determinar que servidor web está a correr no teu servidor ou plano de Hosting.
Precisas de aceder ao backend do teu site de staging WordPress para ativares os post name permalinks.
Se tentares aceder ao backend do site de staging e este te redirecionar para o site em produção, adiciona o slug wp-admin ao fim do URL, p. ex., https://example.com/stagingsite/wp-admin
Isso permite-te aceder ao wp-admin do teu site.
(Este redirecionamento pode acontecer se utilizas Plugins de idiomas como o WPML ou o Polylang, que adicionam um slug de idioma ao URL. Estes Plugins requerem frequentemente que os permalinks estejam ativados.)
Servidor web Apache
Se o servidor Apache serve o teu site, há grandes hipóteses de os permalinks amigáveis para pesquisa funcionarem sem trabalho adicional.
Basta ativares os permalinks na página:
Site de staging > wp-admin > Settings > Permalinks
É muito provável que funcione bem desde o início.
Se isto não der o resultado esperado e os links no site de staging devolverem um erro 400, cria um novo ficheiro .htaccess e coloca-o na raiz do site de staging utilizando um cliente FTP ou um Plugin de gestor de ficheiros.
O conteúdo desse ficheiro deve ser parecido com isto:
# BEGIN WordPress
RewriteEngine On
RewriteBase /staging/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /staging/index.php [L]
# END WordPressSubstitui o texto destacado staging pelo nome da subpasta onde o site de staging está localizado!
Servidor web Apache | Multisites
Normalmente, o WP STAGING trata de tudo e faz os ajustes necessários ao .htaccess se clonas um multisite WordPress.
As seguintes regras serão colocadas num ficheiro .htaccess na raiz do site de staging para multisites em subdomínio e em subpasta:
Multisite em subdomínio, p. ex., staging.example.com
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]Multisite em subpasta, p. ex., example.com/staging
RewriteEngine On
RewriteBase /staging/
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]Substitui o texto destacado staging pelo nome da subpasta onde o site de staging está localizado!
Servidor web Nginx
Se o teu site utiliza Nginx, tenta primeiro ativar os permalinks amigáveis para pesquisa no site de staging. Se isso não funcionar, segue os passos abaixo para ativar os permalinks no Nginx.
Abre o wp-admin e vai a Settings > Permalinks, depois seleciona Post name.
Para testar, abre a página inicial do teu site e clica em qualquer link.
Se a página abrir como esperado, está concluído. Se devolver um erro 404, segue os passos avançados abaixo:
Cria um novo server block no nginx.conf semelhante ao seguinte excerto:
location /staging{
try_files $uri $uri/ /staging/index.php?$args;
}Substitui o texto destacado staging pelo nome da subpasta onde o site de staging está localizado!
Altera também o caminho para o ficheiro do socket PHP, se for diferente no teu sistema. Isto serve apenas para te dar uma ideia do que mudar. Não uses estes valores ao pé da letra sem verificar se a tua configuração NGINX é diferente.
Tem em conta que precisas de acesso total ao servidor para seguires os passos acima. Se não percebes o que estas linhas fazem, pode ser melhor pedires a alguém que te ajude com as alterações ou manteres os permalinks desativados.
Depois disto, o servidor Nginx tem de ser reiniciado e podes usufruir do teu site de staging com permalinks personalizados ativados.
Isto vai exigir sempre que configures um bloco Nginx específico com o nome da pasta do site de staging.
Outra abordagem opcional é criar um server block e deixar o Nginx fazer uma reescrita automática sempre que o WordPress é carregado a partir de uma subpasta:
# Matches /<folder>/... – except for WP core folders
location ~ ^/(?!wp-admin|wp-content|wp-includes)([a-zA-Z0-9_-]+)(?:/|$) {
set $first_seg $1;
# First try static files/folders …
try_files $uri $uri/ @maybe_staging;
}
# Checks whether /<folder>/index.php exists; if so, rewrite there,
# otherwise fall back to the live front controller.
location @maybe_staging {
if (-f $document_root/$first_seg/index.php) {
rewrite ^ /$first_seg/index.php?$args last;
}
rewrite ^ /index.php?$args last;
}Multisites em servidor web NGINX
Os multisites do WordPress precisam de uma configuração ligeiramente diferente.
Em baixo, encontras um exemplo de nginx.conf para um multisite de staging numa subpasta.
Destacámos as partes relevantes. Depois de adicionares esta configuração ao teu nginx.conf, tens de reiniciar o servidor NGINX.
Se o teu servidor usa NGINX e não sabes onde adicionar esta configuração, pede ao teu fornecedor de Hosting.
Site de staging em subpasta, p. ex., example.com/staging
server {
listen 80; listen [::]:80;
server_name example.com/staging;
root /var/www/multi; # This is the path to your multisite website
if (!-e $request_filename) {
rewrite /wp-admin$ $scheme://$host$request_uri/ permanent;
rewrite ^/staging(/[^/]+)?(/wp-.*) /staging$2 last;
rewrite ^/staging(/[^/]+)?(/.*\.php)$ /staging$2 last;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location /staging/ {
try_files $uri $uri/ /staging/index.php?$args ;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_intercept_errors on;
fastcgi_pass php7-fpm;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;
}
}Substitui o texto destacado staging pelo nome da subpasta onde o site de staging está localizado!
Site de staging em subdomínio, p. ex., staging.example.com
Se o teu site de staging está num subdomínio, podes usar a mesma configuração de cima, mas precisas de uma pequena alteração:
server {
listen 80; listen [::]:80;
server_name staging.example.com;
# Below should be the path to your staging site
root /var/www/multi/staging;
if (!-e $request_filename) {
rewrite /wp-admin$ $scheme://$host$request_uri/ permanent;
rewrite ^/(/[^/]+)?(/wp-.*) /$2 last;
rewrite ^/(/[^/]+)?(/.*\.php)$ /$2 last;
}
location / {
try_files $uri $uri/ /staging/index.php?$args ;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_intercept_errors on;
fastcgi_pass php7-fpm;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT $realpath_root;
}
}Substitui o texto destacado staging pelo nome da subpasta onde o site de staging está localizado.
Bitnami (Apache)
Precisas de dar passos adicionais se utilizas o WordPress numa instância Bitnami.
Os post-name permalinks não são suportados de raiz nas instâncias WordPress Bitnami, porque o Bitnami não usa .htaccess na pasta raiz do site. Ignora qualquer ficheiro .htaccess que esteja aí.
O Bitnami não usa o ficheiro .htaccess predefinido na raiz do teu site; em vez disso, todas as configurações de htaccess são adicionadas a um ficheiro chamado: /opt/bitnami/apps/APPNAME/conf/htaccess.conf.
Por isso, se queres que os permalinks funcionem, vais ter de modificar o htaccess.conf
Vai a esse ficheiro e adiciona-lhe o seguinte:
<Directory /opt/bitnami/apps/wordpress/htdocs/STAGING>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /STAGING/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /STAGING/index.php [L]
</IfModule>
</Directory>Outra opção é manter os permalinks com a definição plain — assim, não precisas de alterar o htaccess.conf.
Microsoft Azure
O Azure utiliza o servidor Microsoft IIS e requer um web.config personalizado na raiz do diretório web do site de staging.
Primeiro, precisas de consultar o ficheiro web.config no site “em produção” e anotar o nome da regra desta linha:
<rule name="WordPress: http://wordpress-arc.azurewebsites.net" patternSyntax="Wildcard">É WordPress: http://wordpress-arc.azurewebsites.net neste exemplo.
Depois, cria um novo ficheiro web.config no diretório do site “de staging” com o seguinte:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<remove name="WordPress: http://wordpress-arc.azurewebsites.net"/>
<rule name="staging" patternSyntax="Wildcard">
<match url="*"/>
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
</conditions>
<action type="Rewrite" url="index.php"/>
</rule></rules>
</rewrite>
</system.webServer>
</configuration>Garante que esta linha:
<remove name="WordPress: http://wordpress-arc.azurewebsites.net"/>tem o mesmo nome de regra definido no ficheiro web.config do site em produção, que era WordPress: http://wordpress-arc.azurewebsites.net no nosso exemplo.
Microsoft IIS
- Primeiro, abre o ficheiro
web.configno diretório raiz do site em produção para anotares esta linha:
<rule name=”WordPress: https://example.com/” patternSyntax=”Wildcard”>
Especialmente o nome da regra:WordPress: https://example.com/ - Depois, cria um novo ficheiro
web.configno diretório do site de staging com este excerto de código:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<remove name="WordPress: https://example.com/" />
<rule name="WordPress: https://example.com/staging" patternSyntax="Wildcard">
<match url="*"/>
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
</conditions>
<action type="Rewrite" url="index.php"/>
</rule></rules>
</rewrite>
</system.webServer>
</configuration>Garante que a linha <remove name="WordPress: https://example.com/" /> tem o mesmo “name” do que aparece no web.config do site em produção.
E garante que esta linha <rule name="WordPress: https://example.com/staging" patternSyntax="Wildcard"> tem o nome correto do diretório do site de staging.
