¿Hay una longitud máxima de babosa?

Un cliente acaba de crear una publicación con una barra muy larga (90 caracteres), sin caracteres especiales (aparte de guiones), etc.

Cada vez que se hacía clic en el enlace a esa publicación, incluidos los enlaces "Vista previa" o "Ver esta publicación" desde el back-end del administrador, se generaba un 404.

Una vez que recortamos manualmente la babosa, todo funcionó como se esperaba. Es esta una característica o un error"?

EDITAR: una nota para todos aquellos que hablan sobre los límites de DB.

Si llegara al límite del campo DB, entonces la babosa misma se truncaría. Piénsalo un segundo. En el caso de la mayoría de las instalaciones de WP, wp_posts.post_name es VARCHAR (200). Entonces, digamos que alguien escribe un título con> 200 caracteres. ¿Lo que pasa? La babosa se trunca a 200 caracteres y se almacena en wp_posts.post_name. No es que alguien entre y escriba el título completo de la publicación en la barra de direcciones del navegador, sustituyendo los espacios con guiones, ¿verdad? La URL está siendo generada por WordPress, y está obteniendo la URL de la tabla wp_posts.post_name y simplemente poniéndola en el atributo href de la etiqueta de anclaje. Entonces no habrá una disparidad allí. Todo el asunto DB es un arenque rojo.

En cualquier caso, la babosa en cuestión es solo 90 caracteres, por lo que no tiene nada que ver con los límites de DB.

¿Hay alguna limitación conocida sobre la reescritura?

slug

— Tom Auger
fuente

Puede usar una herramienta gratuita como MySQL workbench para verificar el tipo de datos (y la longitud máxima, si corresponde) de cualquier campo de wordpress como se define en la tabla / columna de wordpress correspondiente

— Jordi Cabot

Respuestas:

Debido a la estructura de la tabla wp_posts, la longitud de la columna post_name (la columna para las babosas) es igual a 200 caracteres.

— Eugene Manuilov
fuente

@TomAuger & Eugene: ¿puede confirmar el problema, porque Tom dice que la babosa tenía 90 caracteres? Soy consciente de que el límite es 200, pero esto no cuenta la URL de inicio, ¿verdad?

— brasofilo

@ Eugene, exactamente. 200 caracteres Mi babosa tenía exactamente 90 caracteres, así que no estamos alcanzando el límite de DB.

— Tom Auger

Supongo que no tiene un límite en sí mismo, pero la propiedad del campo en la base de datos para las babosas podría establecerse en una longitud máxima.

¡Así que revisa la base de datos!

— Fredrik Weiland
fuente

@ El que votó en contra: la respuesta es correcta . Por lo tanto, volví a votar.

— kaiser

Probablemente el problema ni siquiera estaba relacionado directamente con WordPress / base de datos ...

Pero la longitud de la URL superó los 255 caracteres (y no a todos los navegadores les gusta).

Lo que sucedió aquí podría haber sido una URL de más de 255 caracteres, que fue truncada por la barra de direcciones del navegador al abrirla ... causando la recuperación de un enlace permanente incorrecto ... que resultó en un 4o4.

Asumible, la longitud máxima de la bala podría ser:

255 - la longitud de (Protocolo + FQDN + estructura de enlace permanente) ...

basado en el límite duro de un navegador.

Pero no puede ser más de 200 caracteres ...

basado en el tamaño del campo post_name.

Incluso si algo más podría haber causado el 4o4 en este caso particular.

Podría haber sido un personaje que no estaba correctamente codificado en url, las razones para 4o4 son infinitas ... ¿alguna vez se consideró un clúster defectuoso en HDD o un módulo RAM defectuoso? :)

— Martin Zeitler
fuente

El GUID no es la URL. Simplemente parece uno, pero no se usa para leer una solicitud. Si mueve WordPress de un dominio a otro, el GUID no cambiará. Ver core.trac.wordpress.org/ticket/6492 y core.trac.wordpress.org/ticket/10857 .

— fuxia

Erm, ¿para qué más que fines de identificación se debe usar una identificación única? Quiero decir, la pregunta básicamente es: ¿Cuál es la razón por la que se lanza un 4o4 en este caso?

— Martin Zeitler

El 404 y el GUID no están relacionados, creo. WordPress simplemente no usa el GUID cuando busca una publicación que coincida con una URL.

— fuxia

Piensa que tienes razón en eso ... post_name y GUID se pueden excluir como fuente del problema: lo que queda son enlaces permanentes y reescrituras. Sin archivos de registro de Apache ni nada, esto es solo una suposición;)

— Martin Zeitler

@syslogic Creo que la reescritura es probablemente la causa y requiere más investigación. La URL, incluida la parte http: //, todavía tenía menos de 128 caracteres, por lo que no creo que esté alcanzando un límite estricto del navegador en la longitud de la URL.

— Tom Auger