Tell me more ×
WordPress Answers is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.
up vote 5 down vote favorite

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.

Are there any known limitations around rewrite?

share|improve this question
1  
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 Cabot May 23 '12 at 16:13

3 Answers

up vote 7 down vote

Due to wp_posts table structure the length of post_name column (the column for slugs) is equal to 200 characters.

share|improve this answer
1  
@TomAuger & Eugene - can you confirm the issue, because Tom says the slug had 90 chars. I'm aware that the limit is 200, but this doesn't counts the home URL, does it? – brasofilo May 23 '12 at 16:39
@Eugene, exactly. 200 characters. My slug was exactly 90 chars, so we're not hitting the DB limit. – Tom Auger May 23 '12 at 20:13
up vote 2 down vote

I guess it doesnt have a limit by it self but the property of the field in the database for slugs might be set to a max length.

So check the Database!

share|improve this answer
@The one who downvoted: The answer is correct. Therefore I reupvoted. – kaiser May 23 '12 at 19:32
up vote 0 down vote

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

share|improve this answer
The GUID is not the URL. It just happens to look like one, but is not used to read a request. If you move WordPress from one domain to another the GUID will not be changed. See core.trac.wordpress.org/ticket/6492 and core.trac.wordpress.org/ticket/10857. – toscho♦ May 30 '12 at 4:41
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? – syslogic May 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 ;) – syslogic May 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 Auger May 31 '12 at 13:59
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.