A client just created a post with a really long slug (90 characters), no special characters (other than hyphens) etc.

Whenever the link to that post was clicked, including the "Preview" or "View this Post" links from the Admin back end, a 404 was generated.

Once we manually trimmed the slug, everything worked as expected. Is this a "feature" or a "bug"?

EDIT: a Note for all those talking about DB limits.

If I were hitting the DB field limit, then the slug itself would be
truncated. Think about it for a second. In the case of most WP
installations, wp_posts.post_name is VARCHAR(200). So, let's say that
someone types in a title with > 200 chars. What happens? The slug gets
truncated to 200 chars and stored in wp_posts.post_name. It's not like
someone is going in and typing the full title of the post in the
browser address bar, substituting the spaces with dashes right? The
URL is being generated by WordPress, and it's getting the URL from the
wp_posts.post_name table and just putting that in the href attribute
of the anchor tag. So there's not going to be a disparity there. The
whole DB thing is a red herring.

In any case, the slug in question is only 90 chars, so it has nothing to do with DB limits.

You can use a free tool like MySQL workbench to check the datatype (and maximum length if any) of any wordpress field as defined in the corresponding wordpress table/column
–
Jordi CabotMay 23 '12 at 16:13

Probably the problem wasn't even directly WordPress/database related at all ...

But the length of the URL exceeded 255 characters (and not all web-browser do like that).

What happened here might have been an URL longer than 255 chars, which got truncated by the browser's address-bar when opening it ... causing the retrieval of a bad permalink ... which resulted in a 4o4.

So assumable the maximum slug-length might be:

255 - the length of (Protocol + FQDN + permalink structure) ...

based on a browser's hard limit.

But it cannot be longer than 200 chars ...

based on the post_name's field size.

Even if somethings else might have caused the 4o4 in this particular case.

It could have been a character which wasn't properly url_encoded as well,
reasons for 4o4's are quite endless ... ever considered a bad cluster on HDD or a faulty RAM module? :)

Erm, for what else than identification purposes should a unique ID be used then? I mean, the question basically is: What's the reason a 4o4 is thrown in this case?
–
syslogicMay 30 '12 at 5:32

The 404 and the GUID are not related, I think. WordPress just doesn't use the GUID when it searches for a post that matches an URL.
–
toscho♦May 30 '12 at 5:46

Think you're right on that... post_name and GUID can be excluded as source of the problem - what's left are permalinks and re-writes. Without Apache logfiles or anything this is just guessing around ;)
–
syslogicMay 30 '12 at 5:58

@syslogic I think rewrites is probably the cause and bears further investigation. The URL, including the http:// part was still under 128 chars, so I don't think it's hitting a hard browser limit on URL length.
–
Tom AugerMay 31 '12 at 13:59