Y a-t-il une longueur maximale de limace?
Un client vient de créer une publication avec un slug très long (90 caractères), sans caractères spéciaux (autres que des tirets), etc.
Chaque fois que le lien vers cet article a été cliqué, y compris les liens "Aperçu" ou "Afficher cet article" à partir du back-end de l'administrateur, un fichier 404 a été généré.
Une fois que nous avons coupé manuellement la limace, tout a fonctionné comme prévu. Est-ce une fonctionnalité ou un bug"?
EDIT: une note pour tous ceux qui parlent des limites de base de données.
Si j'atteignais la limite du champ de base de données, le slug lui-même serait tronqué. Réfléchis-y une seconde. Dans le cas de la plupart des WP installations, wp_posts.post_name est VARCHAR (200). Donc, disons que quelqu'un tape un titre avec plus de 200 caractères. Ce qui se produit? Le slug est tronqué à 200 caractères et stocké dans wp_posts.post_name. Ce n'est pas comme si quelqu'un entrait et tapait le titre complet de la publication dans la barre d'adresse du navigateur, en remplaçant les espaces par des tirets, n'est-ce pas? L'URL est générée par WordPress. L'URL est obtenue à partir de la table wp_posts.post_name et elle est simplement insérée dans l'attribut href de la balise anchor. Donc, il n'y aura pas de disparité là-bas. Toute la chose DB est un hareng rouge.
Dans tous les cas, le slug en question ne contient que 90 caractères, ce qui n’a rien à voir avec les limites de base de données.
Existe-t-il des limites connues concernant la réécriture?
En raison de la structure de la table wp_posts, la longueur de la colonne post_name (la colonne pour les slugs) est égale à 200 caractères.
Je suppose qu'il n'a pas de limite par lui-même, mais la propriété du champ dans la base de données pour les slugs peut être définie sur une longueur maximale.
Alors vérifiez la base de données!
Probablement le problème n'était même pas directement lié à WordPress/base de données ...
Mais la longueur de l'URL dépassait 255 caractères (et tous les navigateurs Web ne font pas comme ça).
Ce qui s'est passé ici aurait pu être une URL de plus de 255 caractères, tronquée par la barre d'adresse du navigateur lors de son ouverture ... provoquant la récupération d'un permalien incorrect ... entraînant un 4o4.
Donc, on peut supposer que la longueur maximale du slug pourrait être:
255 - la longueur de (protocole + nom de domaine complet + structure de lien permanent) ...
- basé sur la limite stricte d'un navigateur.
Mais il ne peut pas être plus long que 200 caractères ...
- basé sur la taille du champ du post_name.
Même si quelque chose d'autre aurait pu causer le 4o4 dans ce cas particulier.
C’était peut-être un personnage qui n’avait pas non plus été correctement codé en url, les raisons pour les 4o4 sont plutôt infinies ... avez-vous déjà considéré un mauvais cluster sur le disque dur ou un module défectueux RAM? :)