¿Existe una longitud máxima para los slugs?

23 may 2012, 18:34:49
Vistas: 17.2K
Votos: 14

Un cliente creó una publicación con un slug extremadamente largo (90 caracteres), sin caracteres especiales (excepto guiones).

Cada vez que se hacía clic en el enlace de esa publicación, incluyendo los enlaces "Vista previa" o "Ver esta publicación" desde el panel de administración, se generaba un error 404.

Cuando recortamos manualmente el slug, todo funcionó correctamente. ¿Esto es una "función" o un "error"?

EDIT: Una nota para todos los que hablan sobre límites de base de datos.

Si estuviéramos alcanzando el límite del campo en la base de datos, entonces el slug mismo sería truncado. Piensen en esto por un segundo. En la mayoría de instalaciones de WP, wp_posts.post_name es VARCHAR(200). Entonces, digamos que alguien escribe un título con más de 200 caracteres. ¿Qué pasa? El slug se trunca a 200 caracteres y se almacena en wp_posts.post_name. No es como si alguien fuera a escribir 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 obtiene la URL desde la tabla wp_posts.post_name y simplemente la coloca en el atributo href de la etiqueta de anclaje. Así que no va a haber una disparidad ahí. Todo el tema de la base de datos es una pista falsa.

En cualquier caso, el slug en cuestión solo tiene 90 caracteres, así que no tiene nada que ver con límites de base de datos.

¿Existen limitaciones conocidas relacionadas con las reescrituras?

1
Comentarios

Puedes usar una herramienta gratuita como MySQL Workbench para verificar el tipo de dato (y la longitud máxima si la hay) de cualquier campo de WordPress como está definido en la tabla/columna correspondiente de WordPress

Jordi Cabot Jordi Cabot
23 may 2012 19:13:11
Todas las respuestas a la pregunta 3
2
11

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

23 may 2012 18:48:16
Comentarios

@TomAuger & Eugene - ¿pueden confirmar el problema? Porque Tom dice que el slug tenía 90 caracteres. Sé que el límite es de 200, pero esto no incluye la URL de inicio, ¿verdad?

brasofilo brasofilo
23 may 2012 19:39:40

@Eugene, exactamente. 200 caracteres. Mi slug tenía exactamente 90 caracteres, así que no estamos alcanzando el límite de la base de datos.

Tom Auger Tom Auger
23 may 2012 23:13:21
1

Supongo que por sí mismo no tiene un límite, pero la propiedad del campo en la base de datos para los slugs podría estar configurada con una longitud máxima.

¡Así que revisa la base de datos!

23 may 2012 18:50:54
Comentarios

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

kaiser kaiser
23 may 2012 22:32:13
6

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

Pero la longitud de la URL excedía los 255 caracteres (y no todos los navegadores web manejan bien esto).

Lo que pudo haber ocurrido aquí es que había 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... lo que resultó en un error 404.

Así que, asumiendo, la longitud máxima del slug podría ser:

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

  • basado en un límite estricto del navegador.

Pero no puede ser mayor de 200 caracteres...

  • basado en el tamaño del campo post_name.

Incluso si algo más pudo haber causado el 404 en este caso particular.

También pudo ser un carácter que no fue codificado correctamente con url_encode, las razones para errores 404 son bastante infinitas... ¿alguna vez consideraste un cluster defectuoso en el disco duro o un módulo de RAM dañado? :)

30 may 2012 07:28:42
Comentarios

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

fuxia fuxia
30 may 2012 07:41:59

Bueno, ¿para qué más que para propósitos de identificación debería usarse un ID único entonces? Quiero decir, la pregunta básicamente es: ¿Cuál es la razón por la que se muestra un error 404 en este caso?

Martin Zeitler Martin Zeitler
30 may 2012 08:32:37

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

fuxia fuxia
30 may 2012 08:46:30

Creo que tienes razón en eso... post_name y GUID pueden excluirse como fuente del problema - lo que queda son los enlaces permanentes y las reescrituras. Sin los archivos de registro de Apache o cualquier otra cosa, esto es solo adivinar ;)

Martin Zeitler Martin Zeitler
30 may 2012 08:58:46

@syslogic Creo que las reescrituras son probablemente la causa y merecen una investigación más profunda. La URL, incluyendo la parte http://, todavía tenía menos de 128 caracteres, así que no creo que esté alcanzando un límite duro del navegador en la longitud de la URL.

Tom Auger Tom Auger
31 may 2012 16:59:28

@TomAuger si es tan corto, mi conclusión podría no aplicar - solo quería señalar esa posibilidad también. Aparentemente esta pregunta no puede responderse sin acceso FTP/mySQL.

Martin Zeitler Martin Zeitler
31 may 2012 18:20:27
Mostrar los 1 comentarios restantes