Existe um comprimento máximo de lesma?

Um cliente acabou de criar uma postagem com uma lesma muito longa (90 caracteres), sem caracteres especiais (exceto hífens) etc.

Sempre que o link para essa postagem foi clicado, incluindo os links "Visualizar" ou "Visualizar esta postagem" no back-end do administrador, um 404 foi gerado.

Depois que aparamos a lesma manualmente, tudo funcionou como esperado. Isso é um recurso ou um erro"?

EDIT: uma nota para todos aqueles que falam sobre limites de banco de dados.

Se eu estivesse atingindo o limite do campo DB, a lesma em si seria truncada. Pense nisso por um segundo. No caso da maioria das instalações WP, wp_posts.post_name é VARCHAR (200). Então, digamos que alguém digite um título com> 200 caracteres. O que acontece? A lesma é truncada para 200 caracteres e armazenada em wp_posts.post_name. Não é como se alguém estivesse digitando o título completo da postagem na barra de endereços do navegador, substituindo os espaços por traços, certo? A URL está sendo gerada pelo WordPress e está recebendo a URL da tabela wp_posts.post_name e apenas colocando isso no atributo href da tag anchor. Portanto, não haverá uma disparidade lá. A coisa toda do DB é um arenque vermelho.

De qualquer forma, a lesma em questão é de apenas 90 caracteres, portanto, não tem nada a ver com os limites do banco de dados.

Existem limitações conhecidas em relação à reescrita?

slug Tom Auger
fonte

Você pode usar uma ferramenta gratuita como o MySQL Workbench para verificar o tipo de dados (e comprimento máximo se houver) de qualquer campo wordpress como definido na tabela wordpress / coluna correspondente

Jordi Cabot

Respostas:

Devido à estrutura da tabela wp_posts, o comprimento da coluna post_name (a coluna para slugs) é igual a 200 caracteres.

Eugene Manuilov
fonte

@ TomAuger e Eugene - você pode confirmar o problema, porque Tom diz que a lesma tinha 90 caracteres. Estou ciente de que o limite é 200, mas isso não conta com o URL inicial, não é?

Brasofilo

@ Eugene, exatamente. 200 caracteres. Minha lesma tinha exatamente 90 caracteres, por isso não estamos atingindo o limite de DB.

Tom Auger

Eu acho que ele não tem um limite por si próprio, mas a propriedade do campo no banco de dados para lesmas pode ser definida para um comprimento máximo.

Portanto, verifique o banco de dados!

Fredrik Weiland
fonte

@ Aquele que votou negativamente: a resposta está correta . Portanto, eu fui re-votado.

Kaiser #

Provavelmente, o problema nem sequer estava diretamente relacionado ao WordPress / banco de dados ...

Mas o comprimento do URL excedeu 255 caracteres (e nem todos os navegadores da Web fazem isso).

O que aconteceu aqui pode ter sido um URL com mais de 255 caracteres, que foi truncado pela barra de endereços do navegador ao abri-lo ... causando a recuperação de um permalink incorreto ... que resultou em um 4o4.

Portanto, presumível, o comprimento máximo da lesma pode ser:

255 - o comprimento da (Protocolo + FQDN + estrutura do link permanente) ...

com base no limite rígido de um navegador.

Mas não pode ter mais de 200 caracteres ...

com base no tamanho do campo post_name.

Mesmo que algo mais possa ter causado o 4o4 nesse caso específico.

Poderia ter sido um personagem que também não foi codificado corretamente, os motivos para 4o4 são infinitos ... já considerado um cluster ruim no disco rígido ou um módulo de RAM com defeito? :)

Martin Zeitler
fonte

O GUID não é o URL. Por acaso, parece um, mas não é usado para ler uma solicitação. Se você mover o WordPress de um domínio para outro, o GUID não será alterado. Consulte core.trac.wordpress.org/ticket/6492 e core.trac.wordpress.org/ticket/10857 .

fuxia

Erm, para que outros propósitos de identificação deve ser usado um ID único? Quero dizer, a pergunta é basicamente: qual é a razão pela qual um 4o4 é lançado neste caso?

Martin Zeitler

O 404 e o GUID não estão relacionados, eu acho. O WordPress simplesmente não usa o GUID quando procura uma postagem que corresponda a uma URL.

fuxia

Pense que você está certo nisso ... post_name e GUID podem ser excluídos como fonte do problema - o que resta são permalinks e reescritas. Sem Apache arquivos de log ou qualquer coisa isto é apenas adivinhando ao redor;)

Martin Zeitler

@ syslogic eu acho que reescreve é provavelmente a causa e tem uma investigação mais aprofundada. O URL, incluindo a parte http: //, ainda estava abaixo de 128 caracteres, portanto, não acho que esteja atingindo um limite rígido de navegador no tamanho do URL.

Tom Auger