Y a-t-il une longueur maximale de slug?

Un client vient de créer une publication avec un slug très long (90 caractères), pas de caractères spéciaux (autres que des tirets), etc.

Chaque fois que le lien vers cette publication a été cliqué, y compris les liens "Aperçu" ou "Afficher cette publication" du back-end Admin, un 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 DB.

Si j'atteignais la limite de champ DB, le slug lui-même serait tronqué. Réfléchis-y une seconde. Dans le cas de la plupart des installations WP, wp_posts.post_name est VARCHAR (200). Supposons donc que quelqu'un tape un titre avec> 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 du message dans la barre d'adresse du navigateur, en remplaçant les espaces par des tirets, non? L'URL est générée par WordPress, et elle obtient l'URL de la table wp_posts.post_name et la met simplement dans l'attribut href de la balise d'ancrage. Il n'y aura donc pas de disparité là-bas. Le tout DB est un hareng rouge.

Dans tous les cas, le slug en question n'est que de 90 caractères, donc cela n'a rien à voir avec les limites de DB.

Existe-t-il des limitations connues concernant la réécriture?

slug

— Tom Auger
source

Vous pouvez utiliser un outil gratuit comme MySQL Workbench pour vérifier le type de données (et la longueur maximale le cas échéant) de n'importe quel champ wordpress comme défini dans la table / colonne wordpress correspondante

— Jordi Cabot

Réponses:

En raison de la structure de la table wp_posts, la longueur de la colonne post_name (la colonne pour les limaces) est égale à 200 caractères.

— Eugene Manuilov
source

@ TomAuger & Eugene - pouvez-vous confirmer le problème, car Tom dit que la limace avait 90 caractères. Je suis conscient que la limite est de 200, mais cela ne compte pas l'URL d'accueil, n'est-ce pas?

— brasofilo

@Eugene, exactement. 200 caractères. Mon slug était exactement de 90 caractères, donc nous n'atteignons pas la limite de DB.

— Tom Auger

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 limaces peut être définie sur une longueur maximale.

Alors vérifiez la base de données!

— Fredrik Weiland
source

@ Celui qui a downvoté: La réponse est correcte . J'ai donc voté de nouveau.

— kaiser

Le problème n'était probablement 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 pourrait avoir été une URL de plus de 255 caractères, qui a été tronquée par la barre d'adresse du navigateur lors de son ouverture ... provoquant la récupération d'un mauvais permalien ... qui a abouti à un 4o4.

On peut donc supposer que la longueur maximale du slug pourrait être:

255 - la longueur de (Protocole + FQDN + structure de permalien) ...

basé sur la limite stricte d'un navigateur.

Mais il ne peut pas dépasser 200 caractères ...

en fonction de la taille du champ post_name.

Même si quelque chose d'autre aurait pu causer le 4o4 dans ce cas particulier.

Il aurait pu s'agir d'un personnage qui n'était pas correctement encodé en url également, les raisons des 4o4 sont infinies ... avez-vous déjà considéré un mauvais cluster sur le disque dur ou un module RAM défectueux? :)

— Martin Zeitler
source

Le GUID n'est pas l'URL. Il se trouve que cela ressemble à un, mais n'est pas utilisé pour lire une demande. Si vous déplacez WordPress d'un domaine vers un autre, le GUID ne sera pas modifié. Voir core.trac.wordpress.org/ticket/6492 et core.trac.wordpress.org/ticket/10857 .

— fuxia

Euh, à quoi d'autre que des fins d'identification devrait-on utiliser un identifiant unique? Je veux dire, la question est essentiellement: quelle est la raison pour laquelle un 4o4 est lancé dans ce cas?

— Martin Zeitler

Le 404 et le GUID ne sont pas liés, je pense. WordPress n'utilise tout simplement pas le GUID lorsqu'il recherche une publication qui correspond à une URL.

— fuxia

Pensez que vous avez raison ... post_name et GUID peuvent être exclus comme source du problème - ce qui reste sont des permaliens et des réécritures. Sans fichiers journaux Apache ou quoi que ce soit, il s'agit juste de deviner;)

— Martin Zeitler

@syslogic Je pense que la réécriture est probablement la cause et mérite une enquête plus approfondie. L'URL, y compris la partie http: //, était toujours sous 128 caractères, donc je ne pense pas que cela atteigne une limite de navigateur stricte sur la longueur de l'URL.

— Tom Auger