¿Existe una longitud máxima para los slugs?
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?

@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?

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? :)

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.

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?

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.

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 ;)

@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.
