Post types with names over 14 characters, taxonomy names over 26 characters

[simonwheatley]

When registering a translated (shadow) post type in Babble_Post_Public::registered_post_type, if a post_type string is longer than 14 characters, and the language is two two letter codes, then WordPress register_post_type will return a WP_Error and trigger a _doing_it_wrong_call, e.g. post type 012345678912345 would become a translated post type 012345678912345_xx_xx (21 characters long) which would cause the issue described.

We should:

1. Change where we are currently calling trigger_error (or throw new exception) to instead call _doing_it_wrong
2. wp_die if WP_DEBUG is defined and true, or throw an admin notice if not
3. Stretch goal: Do not allow any translation of a post type if one of the translation post types for it will go over 20 characters

There is a similar problem with taxonomy names, except the limit is 26 characters (32 characters minus the six characters we need for the lang code suffix), which we should address in a similar way.

[joehoyle]

Why not have the shadow post type name always be under 16 chars, by using some abstraction function to hash the post type name in the case of it being longer than the max chars?

It seems even with this ticket, Babble still wouldn't support post type names at 16 chars.

[simonwheatley]

I've been resisting that as an idea, because I like the principle that the shadow post type names in the database for each post type remain human readable, as (in most cases) was the original default language post type name. I'd prefer to encourage developers to name their CPTs accordingly, but I guess they're not always going to have control if the CPT is added by a third party plugin, etc.

[joehoyle]

@simonwheatley worth mentioning - we'd only need to hash names that were longer than 14 chars (or whatever) so you'd only get an ugly name for the edge cases.

[simonwheatley]

See Core Trac #28303

[simonwheatley]

To add more context to the above core trac link :smile: the locale variants, e.g. Portuguese formal, adds a _formal suffix, more than doubling the length of the locale name. This clearly compounds our problem here :disappointed:

[johnbillion]

This is a pretty crappy situation. Like Simon, I'd love to retain the readability of post type names, but with a _de_DE_formal suffix, it only leaves seven characters for the actual post name.

Three options:

• Change nothing in Babble, push for core to increase the length of the post_type field.
• Add length warnings to Babble if it detects a post type / language code combo which exceeds 20 chars.
• Hash the post type / language code in the shadow post type name. Need to consider backwards compatibility here.

[simonwheatley]

@joehoyle @johnbillion My preference is:

• Add length warnings (_doing_it_wrong) to Babble if it detects a post type / language code combo which exceeds 20 chars IF WP_DEBUG is true
• Hash the post type / language code in the shadow post type name IF the length will go over the length of the post_type field; I think this won't have backwards compatibility issues, as sites hitting this are already borked :worried:

[simonwheatley]

Note Dominik's reply in core trac:

There are official sub tags which are even longer than seven chars, for example 1694acad in fr-FR-1694acad. BCP47 includes a section about Length Considerations which says, that there is no upper limit for language tags but "buffer sizes for language tags MUST allow for language tags of at least 35 characters." So this sounds more like an implementation issues which needs to be fixed in the plugin, not something we have to consider if we want to support (official) variants of a languages.

[simonwheatley]

(doh, didn't mean to close… stupid buttons)

[johnbillion]

Purely so I can say "told-you-so" at some point in the future, a prediction: hashing shadow post type names will come back and bite us in the ass.

[simonwheatley]

Low blow, @johnbillion, low blow. Nobody disagrees, but what can we do? :worried:

[markoheijnen]

No special way at Automattic to get something fixed in WordPress 4.4 😉 Just kidding but we should have a list on what we need to be fixed in WordPress and this would be really high on that list. Unsure if there is an ticket for this but I believe they finally want to tackle option_name length.

[simonwheatley]

@markoheijnen @johnbillion @joehoyle Is there a consensus that we should only implement _doing_it_wrong at this point, and open a ticket to increase the length of the post_type field? 20 does seem short, at least in this context, but how long should it be? Bear in mind the length considerations Dominik pointed out, i.e. "buffer sizes for language tags MUST allow for language tags of at least 35 characters". 64 characters? 128?

[markoheijnen]

I guess 64 would be enough.

[simonwheatley]

Having considered this some more, I believe:

• Currently it's possible for the post_type name to break if it becomes too long
• A site developer might not always be in control of the post_type name to change it to a shorter one
• We can always run a migration to reverse some or all hashed post_type names if the field length is increased
• It's a horrid situation, and I'd much rather we had readable post_type names at all times… but I think we have no choice

So…

[simonwheatley]

Closed in #301