Languages: English • Français • 日本語 한국어 • ລາວ • myanmar • Nederlands • Português do Brasil • ไทย • 中文(简体) • 中文(繁體) • (Add your language)

Ajuda ao Usuário WordPress Referência da Ajuda Contextual - Este artigo é acessado a partir da Ajuda Contextual do WordPress PT-BR. Procure nosso Fórum Oficial se precisar de mais ajuda sobre este assunto.

Links permanentes são as URLs de cada postagem, categoria e outras listagens do blog. O link permanente é usado quando alguém quer apontar para o seu site, ou quando alguém quer enviar por e-mail o endereço de algum artigo seu. O URL de cada postagem deve ser fixa, ou seja permanente e nunca mudar.

Tipos de links permanentes

Existem três tipos básicos de links permanentes no WordPress:

• Padrão "Feio"
• Links Permanentes Legíveis
• Quase Legível

Veja sobre cada um desses tipos de configuração:

Padrão "Feio"

O padrão de links do WordPress é algo como:

http://examplo.com/?p=N

onde N é o número ID da postagem. Funciona em todos os ambientes de servidor, mas ele não é tão agradável como algumas das outras opções.

Links Permanentes Legíveis

Usando mod_rewrite ou lighttpd tenha links legíveis em seu site. Há muitos formatos disponíveis:

http://examplo.com/categoria/nome-da-postagem/
or  http://examplo.com/2011/janeiro/14/nome-da-postagem

Algumas pessoas eliminam alguns ou todos os elementos de data (dia, mês, ano) para ter um formato mais curto.

Exigências para o servidor:

• Servidor Apache com módulo mod_rewrite instalado.
• WordPress Em diretório próprio
  • Opção FollowSymLinks ativada
  • FileInfo directives ativado (ex:. AllowOverride FileInfo ou AllowOverride All)
  • Um arquivo .htaccess (se inexistente, o WordPress poderá criar um ser tiver permissão)
  • Se quer permitir o WordPress de escrever no arquivo .htaccess ele deve ter permissão de escrita.

• Para lighttpd, veja External Resources (em inglês)

• Usuários de Mac usando o WordPress localmente, devem editar o arquivo httpd.conf mudando a linha AllowOverride para ler AllowOverride All no Directory "/Library/WebServer/Documents". Para Mac OS X 10.5.x e superior, este arquivo está em /private/etc/apache2/users/[seu-nomedeusuario].conf, ou em /etc/httpd/httpd.conf.

Quando criar ou atualizar uma estrutura de links permanentes "bonito", o Wordpress vai gerar regras de re-escrita e tentar inseri-los no arquivo .htaccess. Se não puder, ele vai dizer algo como Atualize seu arquivo .htaccess agora. e mostrar as regras para que você copie e cole no arquivo (colocá-los no final do arquivo).

No WordPress 2.0+, você provavelmente precisará fazer isso apenas uma vez, porque o WordPress faz a re-escrita internamente . Se você transferir o seu diretório do WordPress (endereço do blog ), será preciso repetir este passo.

WordPress age normalmente com arquivos .htaccess existentes e não irá excluir qualquer regras de Re-escrita existentes ou de outras diretivas. Se você tiver outras regras mod_rewrite, adicione antes das que o WordPress criar.

Quase Legível

PATHINFO é quase parecido com mod_rewrite com uma exceção: /index.php fica inserido antes do endereço:

http://examplo.com/index.php/2011/01/14/nome-da-postagem/

Links mod_rewrite são quase o mesmo que "links legíveis" e são igualmente flexíveis. Qualquer coisa que mod_rewrite pode fazer, PathInfo pode fazer, com a ajuda de index.php.

Existe um plugin útil que exibe o tipo de link permanente que está sendo usado e informações detalhadas sobre as regras internas de reescrita usadas pelo WordPress.

Estrutura de Links permanentes

No painel Configurações em Opções → Links Permanentes, você pode escolher uma das estruturas ou criar a sua própria "estrutura personalizada", utilizando as tags estrutura.

Atenção:

Nunca coloque o URL do site no slot permalinks. Você deve usar uma das marcas de estrutura, ou uma combinação de tags apenas.

Para ativar Links permanentes com PathInfo, inicie sua estrutura de Links permanentes com index.php /.

Tags de estrutura

Atenção:

Nunca coloque o URL do site no slot links permanentes. Você deve usar uma das marcas de estrutura, ou uma combinação de tags apenas!

Você pode usar essas tags para personalizar o Links permanentes legíveis ou quase legíveis.

Algumas sugestões:

• Termine a estrutura com %post_id% ou %postname% (Ex.: /%year%/%monthnum%/%day%/%postname%/ em inglês mesmo!) assim cada link aponta para uma postagem individual.
• Por questões de performance, não é uma boa idéia começar com o nome de categoria, tag, autor, ou nome da postagem. A razão é que estes são campos de texto então se usar como o início do seu Link permanente, pode levar mais tempo para o WordPress distinguir entre URL de postagens e URLs de páginas (que usam "slug da página" como URL), para compensar, WordPress armazena informações extras no banco de dados. Sites grandes com muitas postagens e páginas podem ter dificuldades com isso. Então, é aconselhável ter ao menos 2 segmentos de caminho na estrutura das postagens como /%post_id%/%post_name%/ que oferece melhor performance. Outros podem dizer que não é bom, já que deixa o URL menos legível. Veja Otto's technical writeup (em inglês) e wp-testers discussion (em inglês).

Tags de estrutura Deve ser usado em inglês, não traduza %month% para %mes%.

%year% 

Ano da postagem, em quatro dígitos 2011

%monthnum% 

Mês do ano 05

%day% 

Dia do mês por exemplo 28

%hour% 

Hora do dia, por exemplo 15

%minute% 

Minuto da hora, por exemplo 43

%second% 

Segundo, por exemplo 33

%postname% 

Versão de nome simples do título da postagem, conhecido também por post slug. Assim “Olha uma postagem em ação!” fica olha-uma-postagem-em-acao na URI.

%post_id% 

O número ID da postagem, por exemplo 423

%category% 

Versão saneada da categoria ou category slug.

%tag% 

Versão de nome simples da tag ou tag slug.(Não usar %tag% no início da estrutura por questões de performance).

%author% 

Versão de nome simples do nome autor. (Não usar %author% no início da estrutura por questões de performance).

base da categoria e da base Tag

A base da categoria e base tag são prefixos usados em URLs para a categoria e tag de arquivos, que se parecem com isto:

 examplo.net/wp/category_base/category_name
 examplo.net/wp/tag_base/tag_name

Os valores padrão para essas categorias são category e tag. Você pode alterá-los, mas você não se pode removê-los das URLs completamente.

Link permanentes personalizados funcionam na maioria dos sistemas sem quaisquer problemas, mas ainda existem algumas condições onde os problemas ocorrem.

%category%/%tag% em postagem com múltiplas categorias/tags

Quando se define múltiplas categorias para uma postagem, apenas uma é mostrada no link permanente e será a categoria que tiver o menor número ID. A postagem ainda é acessada por qualquer outra categoria que estiver, normalmente.

A mesma coisa se aplica ao uso do %tag% na sua estrutura de link permanente.

Links Legíveis sem mod_rewrite

Se você estiver usando IIS 7 e tem direitos de administrador no servidor, você pode usar Microsoft o URL Rewrite Module. Apesar de não ser totalmente compatível com mod_rewrite , ele dá suporte a links legíveis do WordPress. Uma vez instalado, abra o arquivo web.config na pasta do WordPress e adicione a seguinte regra para o elemento system.webServer:

<rewrite>
    <rules>
        <rule name="Main Rule" stopProcessing="true">
            <match url=".*" />
            <conditions logicalGrouping="MatchAll">
                <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
            </conditions>
            <action type="Rewrite" url="index.php/{R:0}" />
        </rule>
    </rules>
</rewrite>

Há um guia de instalação complete no IIS site. O módulo disponível são sistemas x64 e x86.

Se esta não é uma opção, tente usar PATHINFO; coloque index.php/ no início da sua estrtura de links permanentes, Configurações -> Links Permanentes:

 /index.php/%year%/%monthnum%/%day%/%postname%/

Esta opção pode não funcionar sempre, principalmente nos casos de WordPress no IIS 6. Para fazer isso funcionar no IIS, adicione essas duas linhas em um arquivo php.ini e armazenar esse arquivo em seu webroot:

 cgi.fix_pathinfo = 1
 cgi.force_redirect = 0

Outra solução existe usando o IIS redirecionamentos 404 personalizados. Ela requer que o seu servidor permita avocê adicionar um redirecionamento 404 personalizado, mas não exige a instalação de qualquer software mod_rewrite de terceiros e também não exige que a estrutura de link permanente começe com /index.php/.

O arquivo .htaccess ?

O arquivo index.php e .htaccess devem estar juntos no diretório indicado pelo endereço do Blog (URI) que está na sua página de administração Configurações -> Geral. Desde que o nome do arquivo começa com um ponto, o arquivo pode não ser visível através de um cliente FTP, a menos que você mude as preferências da ferramenta FTP para mostrar todos os arquivos, incluindo os arquivos ocultos.

Alguns servidores (por exemplo, Godaddy) pode não mostrar ou permitir que você edite arquivos .htaccess se você instalar o WordPress através da Godaddy Hosting Connection.

Criando e Editando (.htaccess)

Se você não tiver um arquivo .htaccess, crie um. Se você tiver acesso ao shell ou ssh para o servidor, uma simples comando touch .htaccess irá criar o arquivo. Se você estiver usando o FTP para transferir arquivos, crie um arquivo no computador local, por exemplo, um arquivo de texto vazio e nomeie 1.htaccess, envie o arquivo para a pasta raiz do seu WordPress e o renomeie para .htaccess.

Você ainda pode editar o arquivo .htaccess através do cliente FTP, shell, pelo cPanel do seu servidor e ou o administrador de arquivos do seu servidor.

A seguinte regra de re-escrita, pode ser usada no seu arquivo .htaccess:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Se seu arquivo .htaccess contiver erros, será preciso excluir o arquivo através do cliente FTP ou pelo serviço do seu servidor.

Atualizando .htaccess

Se o WordPress não pode atualizar automaticamente seu arquivo .htaccess, ele vai dizer algo como Se seu arquivo .htaccess fosse gravável, poderíamos fazer isso automaticamente, mas não é ... .

Se você quiser deixar o WordPress fazer isso, você precisará mudar as permissões do seu arquivo. As permissões necessárias dependerá da configuração do seu servidor. Tente adicionar permissões para o proprietário, então o grupo, então todo, testando depois de cada mudança, uma vez que o WordPress precise editar o arquivo com sucesso, não adicione qualquer outra permissões de gravação.

Depois de aplicar as regras de re-escrita, você deve alterar as permissões para algo mais seguro como 660 ou 644 para impedir que outras pessoas no servidor possam ter acesso a ele.

Na internet, você tem muitos sites ensinando como alterar a permissão de arquivos, como no Youtube: Dando permissão de arquivos via cPanel, ou Modificando permissões

Corrigindo Problemas de Geração de .htaccess

Se a sua instalação do WordPress não gera uma arquivo .htaccess ou não grava as novas regras em seu arquivo existente, então existem algumas razões que podem estar causando isso. Trabalhe passo a passo e continue para a próxima etapa somente se a etapa anterior não funcionar:

1. Mude as permissões do arquivo - Mude a permissão do arquivo .htaccess para 666 temporariamente, só até o WordPress conseguir escrever no arquivo. Depois mude a permissão novamente para 660.
2. Bloqueio do Servidor - Seu Servidor pode ter bloqueado a variável SERVER_SOFTWARE e isso faz com que a geração de arquivo .htaccess pelo WordPress não funcione. Se você tiver certeza que seu servidor está rodando o Apache, você pode forçar o WordPress acreditar que o servidor está executando o Apache mudando o arquivo wp-includes/vars.php. Siga os passos abaixo para implementar essas mudanças:

• Abra o arquivo wp-includes/vars.php usando o editor do WordPress mesmo ou o do servidor.
• Procure por

  $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

  and replace it with

  // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

• Adicione uma linha nova após

  // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

  e digite

  $is_apache = 1;

Usários de XAMPP (Windows)

Algumas versões do XAMPP não habilitam o mod_rewrite por padrão(tmesmo que seja compiledo em Apache). Para habilitar — e assim o WordPress conseguir criar o .htaccess — abra oa rquivo apache/conf/httpd.conf e remova os comentários da linha LoadModule rewrite_module modules/mod_rewrite.so (ou seja, delete o sinal cerquilha/libra no começo da linha.

Links Permanentes, .htaccess e MS Frontpage

Uma nota sobre o Microsoft Frontpage: muitos servidores (compartilhados e dedicados), mantido e construído por várias empresas de hospedagem vêm com mod_frontpage compilado com o Apache e em muitos casos com o Frontpage Server Extensions instalado em cada servidor virtual. Isso é mais comum do que muitos/a maioria das distribuições binárias mais usadas no processo de construção do servidor, na maioria das empresas de hospedagem atuais incluindo ambos mod_fronpage e extensões de servidor. Mesmo se você não estiver usando o Frontpage, por causa da maneira que as extensões interagem com Apache (e o arquivo httpd.conf), você provavelmente vai ter algo parecido com um erro 500 ou a página em branco ao tentarver a instalação do WP (embora o painel de administração pode funcionar correctamente) simplesmente porque extensões extensions/mod_frontpage existem no seu servidor.

Wordpress irá funcionar corretamente com as extensões Frontpage instaladas, no entanto, os links permanentes não vão funcionar e qualquer mudança nos Links Permanentes através da interface do Wordpress causará a quebra do FrontPage Server Extensions devido à adição da regra mod_rewrite no arquivo .htaccess. Há, porém, agora uma correção para essa situação.

Consertos Rápidos, Frontpage ou Links Permanentes

Frontpage Extensions Se você não se importa com Links Permanentes e só quero fazer as extensões MS Frontpage funcionarem de novo, basta editar o arquivo .htaccess e remover a seção criada pelo WordPress com as regras de re-escrita.

Para usar Links Permanentes : Se você não se importa com o Frontpage (mas a sua empresa de hospedagem tem as extensões instaladas)

Você precisará remover (ou pedir a sua empresa de hospedagem para fazê-lo), o MS FrontPage Server Extensions, ou simplesmente editar o arquivo .htaccess removendo todas as linhas do Frontpage, deixando apenas o código mod_rewrite criado pelo WordPress .

Usando FrontPage e Links Permanentes Juntos

Finalmente, uma solução

Tem havido uma série de tópicos sobre esta questão nos fóruns de suporte e até agora, nenhuma solução para o problema.

Normalmente, em um servidor Unix com o Microsoft FrontPage Server Extensions instalado, o WordPress funciona muito bem e você será capaz de editar e publicar páginas (com o Microsoft FrontPage) -desde que- você faça uma alteração para os Links Permanentes (por exemplo, para o tipo baseado em data: 2005/04/etc). Costuma-se sugerir que este tipo de URI é o método recomendado pela W3C (ver http://www.w3.org/Provider/Style/URI).

Agora, o problema é que o FrontPage usa o arquivo .htaccess (onde o WordPress precisa também incluir regras de acesso) para a sua configuração de publicação e web criação. Logo que o código WordPress mod_rewrite é adicionado ao arquivo, duas coisas acontecem - os Links Permanentes não funcionam e as extensões de servidor do FrontPage ficam corrompidas.

A solução desde impasse é realmente simples:

Se você estiver usando, ou se deseja usar o FrontPage (ou se o seu pacote de hospedagem está pré-configurado dessa forma), juntamente com o WordPress, você precisa tomar as seguintes medidas no seu servidor ou pedir a sua empresa de hospedagem para fazê-las para você.

O Microsoft FrontPage cria o seguinte diretórios:

_vti_bin

Dentro deste diretórios ele também cria< pre>_vti_adm</pre> e

_vti_aut

Além de sua pasta raiz do site (ou o WordPress) em todos os diretórios que você vai encontrar arquivos .htaccess adicionais.

Em todas esses três e no diretório raiz, no topo de todas os arquivos .htaccess, você simplesmente precisa adicionar uma linha:

 Options +FollowSymlinks
 

Pode ou não ser já ter uma linha em cada arquivo com:

Options None

Edite e salve cada arquivo .htaccess e está feito! Agora tudo funciona perfeitamente, incluindo o FrontPage e os Links Permanentes de sua escolha.

Links Permanentes Longos

Ao utilizar Links Permanentes longons em mesanges de email, em comentários e em chats, alguns Links Permanentes são "cortados" ou apenas a primeira seção é realmente reconhecido como um link e o final visto como texto. Aqui está um exemplo.

Pode ficar assim:

Se clicar em um link cortado, o usuário recebe uma página de Erro 404 (não encontrado). Se você tem uma tendência a usar títulos de postagens muito compridos, siga estes passos para evitar este problema.

1. Certifique-se de que está usando mesmo Links Permanentes.

2. Edite seu arquivo .htaccess adicionando o seguinte:

 RewriteRule ^post/([0-9]+)?/?([0-9]+)?/?$ /index.php?p=$1&page=$2 [QSA]
 

3. Teste. Encontre o número ID de uma psotagem e adicione a seu link:

 http://exemplo.com/post/( D da postagem)
 

É importante notar também que a maioria dos softwares de e-mail não corta URLs que estiverem dentro de sinal de maior e menos (< e >), então quando colar URLs em e-mails, você deve escrevê-los assim:

Além disso, alguns clientes de email oferecem uma opção "pre-format" quando escrever e-mails de texto simples. Usando a opção "pre-format" quando colar links forçará o cliente de e-mail não inserir quebras de linha dentro dos links.

Corrigindo Outros Problemas

Se seu arquivo .htaccess está sendo gerado corretamente, mas os Links Permanentes não funcionam pode ser uma falha do sistema WordPress. Se os problemas persistirem, publique uma mensagem no Fórum Sobre Problemas e Funcionamento descrevendo o que acontece.

AllowOverride Não ativado

O servidor não tem a diretriz AllowOverride habilitada. Se a diretiva AllowOverride está configurada para None no seu arquivo Apache httpd.config , então o arquivo .htaccess será ignorado. Neste caso, o servidor não vai sequer tentar ler arquivos .htaccess do sistema. Quando essa diretiva é definido como all, então qualquer diretiva que tem o .htaccess é permitido. Exemplo de diretriz AllowOverride habilitado em httpd.config:

 <Directory />
    Options FollowSymLinks
    AllowOverride All
 </Directory>

No arquivo DocumentRoot:

 <Directory /var/www/html>
    # ... other directives...
    AllowOverride All
 </Directory>

Você também pode ter que alterar as configurações AllowOverride para o site. Este é certamente o caso quando se usa o Mac OS X Server, mas pode ser o mesmo com outros sistemas. Normalmente você pode encontrar os arquivos de configuração em /etc/httpd/sites/.

Se você não deseja definir AllowOverride para todos (como referido acima), então sua lista deve incluir a lista FileInfo . É necessário reiniciar o servidor Apache para qualquer alterações no arquivo httpd.config ter efeito. Para obter mais informações sobre quais substituições são permitidas , leia sobre Apache Core Features.

Navegação de Páginas não Funciona

Às vezes, a navegação para a segunda (e subseqüente) páginas pode não funcionar como esperado. Sua página pode gerar um link para uma página com uma dessas URIs:

 http://www.exemplo.com/page/2/
 http://www.exemplo.nome/category/categoryname/page/2/
 http://www.exemplo/year/month/day/page/2/
 http://www.exemplo/year/month/page/2/

O resultado de clicar em um desses links é que a página é carregada com todos os elementos (cabeçalho, barra lateral, rodapé), mas em vez de uma página de postagem, há uma mensagem de erro: "Desculpe, nenhum resultado nesse critério."

Isto é devido a uma falha no arquivo .htaccess gerado. Para corrigir isso, exclua o conteúdo de seu arquivo .htaccess e recrie o arquivo de novo através do Painel do WordPress.

Ou crie um novo arquivo .htaccess, enviando um arquivo de texto vazio para o servidor.

Se não resolver, procure ajuda no Fórum Sobre Problemas e Funcionamento descrevendo o que acontece.

Links Permanentes funcionam mas páginas não 

Algumas versões de PHP 4.4.x e 5.x tem um bug que causa a falha no mod_rewritese usado com Apache 2.x. Mais detalhes em http://bugs.php.net/bug.php?id=35096 and http://bugs.php.net/bug.php?id=35059 (em inglês).

Dicas e Truques

Evitando Interpretações de Link como Arquivo

Observe que mesmo que nunca se faça mais de uma postagem por dia mas mesmo assim se queira usar o formato de link %year%%monthnum%%day%, todos os links gerados serão interpretados como arquivo das postagens do dia. Use %year%%monthnum%%day%%hour% para assinalar uma única postagem.

Verificar Estrutura de Links Permanente

Uma maneira de verificar se o blog tem uma estrutura de Links Permanentes é inserir o código em um arquivo qualquer de seu tema atual:

if ( get_option('permalink_structure') != '' ) { echo 'Links Permanentes ativos!' }

Mais Ajuda

• Fórum de Suporte WordPress Brasil
• Tópicos sobre links permanentes no Fórum de Suporte

Links Externos

• .htaccess no Windows - Como criar um arquivo .htaccess no Windows para instalação local

Páginas da Ajuda acessada nos Painéis de Administração V ▪ E
Paineis	Painel Comentários ▪ Painel Discussão ▪ Painel Escrita ▪ Painel Exportar ▪ Painel Ferramentas-Disponíveis ▪ Painel Fundo ▪ Painel Geral| ▪ Painel Importar ▪ Painel Início ▪ Painel Leitura ▪ Painel Links Permanentes ▪ Painel Mídia ▪ Painel Mídia-Adicionar Nova ▪ Painel Menus ▪ Painel Meus Sites ▪ Painel Páginas-Todas as Páginas ▪ Painel Plugins-Instalados ▪ Painel Posts-Adicionar Novo ▪ Painel Rede ▪ Painel Tags ▪ Painel Temas ▪ Painel Todos os Links ▪ Painel Usuários-Seu perfil ▪ Painel Widgets
Recursos	Publique Isso ▪ Resumo ▪ Cabeçalhos Personalizados▪Campos Personalizados ▪ Formatos de Posts
Rede e Multisite	Crie uma Rede▪Depurando uma Rede WordPress
Desenvolvimento	API WordPress XML-RPC▪ Escrevendo um Plugin ▪ Funções e Capacidades ▪ Widgets em Temas
Outros	Atalhos de Teclado▪ Glossário ▪ Formatando Data e Hora ▪ Primeiros Passos com o WordPress ▪ Spam em Comentários ▪ Usando Links Permanentes ▪ Cookies