Increase CPT "machine name" limit from its current maximum of 20 characters.

[taupecat]

In order to accommodate proper namespacing for Custom Post Types (as well as, potentially, transliteration from non-Latin alphabets), 20 characters is often not enough.

Custom Taxonomies currently have a machine name limit of 32 characters. It would be nice to see CPTs have at least that many, although 64 characters would be even better.

[zodiac1978]

I've used Git blame to look for the tickets which introduced those limits in the schema.php

I’ve searched for the reason to limit the post type to 20 chars and found this comment:
https://core.trac.wordpress.org/ticket/2604#comment:5

It was varchar(100) before. See:
https://core.trac.wordpress.org/ticket/1710

Looks like the taxonomy part was handled here:
https://core.trac.wordpress.org/ticket/4189

It was first varchar(55) and changed in a different patch on the same ticket to varchar(32).

[taupecat]

And in that comment, he states that there was no difference to performance with the field size decrease. Yet the field size was never returned to 100, despite the reduction not achieving the desired results.

And performance relative to field size is probably even less of an issue today, given increases in computer power over the last 15 years (Moore's Law, and all that).

Thanks for research on this!

Ref: https://core.trac.wordpress.org/ticket/54070

Trac ticket:

[taupecat]

The pull request failed all the PHPUnit tests _except_ for:

• 8.1 on ubuntu-latest
• 8.1 multisite on ubuntu-latest
• 5.6.20 slow tests on ubuntu-latest
• 5.6.20 multisite slow tests

Not sure why though. The changes were really quite minimal, and the versions of PHP should make zero difference.

[SergeyBiryukov]

Replying to taupecat:

The pull request failed all the PHPUnit tests

Looks like the tests need some adjustments, specifically this one:

There was 1 failure:

1) Tests_Post_Types::test_register_post_type_with_too_long_name
Failed asserting that WP_Post_Type Object (...) is an instance of class "WP_Error".

/var/www/tests/phpunit/tests/post/types.php:56

Introduced in [31450] / #31134 and renamed for clarity in [31457].

[costdev]

I was looking into this but you got there before me @SergeyBiryukov!

The test that checks for a post type name that's too long doesn't provide a sample that is long enough for this change.

The test passes with this fix:

tests/phpunit/tests/post/types.php:54

function test_register_post_type_with_too_long_name() {
        // Post type too long.
        $this->assertInstanceOf( 'WP_Error', register_post_type( 'abcdefghijklmnopqrstuvwxyz0123456789' ) );
}

becomes:

function test_register_post_type_with_too_long_name() {
        // Post type too long.
        $long_name = 'abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789';
        $this->assertInstanceOf( 'WP_Error', register_post_type( $long_name ) );
}

[taupecat]

What's the next step on this?

[costdev]

Looks like it just needs some follow up on the needs-codex keyword to adjust these pages:

1. ​register_post_type() - $post_type
2. ​Registering Custom Post Types - Naming Best Practices: Notice #1
3. ​Database Description - Column: post_type

[ocean90]

We already have a ticket for this request in #37104 which was closed as maybelater. A similar one is #39507, closed as wontfix.

Could you provide some real use cases where a longer post type name would be required?

[costdev]

It's worth noting that #37104 was set as maybelater due to a lack of input for several years rather than any problem with the feature request itself.

I agree that it would be good, both for insight and for posterity, to see an example or two relating to:

In order to accommodate proper namespacing for Custom Post Types (as well as, potentially, transliteration from non-Latin alphabets), 20 characters is often not enough

Edit: In #37104, one person mentioned that a 20 character limit created difficulty for them in adding prefixes to the post type in order to prevent clashes.

[taupecat]

Replying to ocean90:

We already have a ticket for this request in #37104 which was closed as maybelater. A similar one is #39507, closed as wontfix.

Could you provide some real use cases where a longer post type name would be required?

Wow, okay, this is out of left field.

I [posed the question on Twitter](​https://twitter.com/taupecat/status/1433424418978492423) recently as to why the 20 character limit. Both the blog post referenced by a ticket you pointed and other research done by @zodiac1978 indicated that the 20 character limit (down from 100) was an attempt to improve database performance which ended up having no appreciable effect at the time. And that was 15 years ago.

So maybe the question should be, what was the use case to bring it down from 100 to 20 in the first place, and why did that limit stay in effect when it didn't accomplish the stated goal?

Among the responses to my Twitter post were [comments from @markjaquith](​https://twitter.com/markjaquith/status/1433431774965624848) and others indicating that the limit should be raised. So I'm proposing a very simple fix to raise it.

I can't provide specific use case for increasing the limit other than 20 characters is unreasonably low when one wants to incorporate sensible namespacing in custom post type names, especially when one considers that custom taxonomy names have a 32 character limit. I've run headlong into this limit in previous projects, and have always had to make adjustments, sometimes compromising good namespacing practices. This ticket is to help developers in the future have a little breathing room so that they don't have to make similar adjustments when adding a namespace to their custom post type names.

I'm willing to do the (rather minimal) work here, and I saw the comment that the Codex will need an update patch which I will submit as soon as I can spare a few minutes to do that.

[costdev]

@taupecat I agree - it isn't clear why the reduction from 100 characters to 20 was committed when it yielded no performance benefits, and you're right, it seems this is less a case of anyone justifying a higher character limit and more about someone justifying the status quo.

[taupecat]

I've updated my pull request with the DocBlock documentation (for developer.wordpress.org) updated to reflect the increase to 64 characters.

The plugin developer guide should be updated after this change is merged into core and released.

And logging into the old Codex just appears to be broken. 😞

[taupecat]

Hi all, just checking in to see if there's been any movement on this? What do I need to do next in order to advance this?

[taupecat]

Periodic ping to see if there's anything I can do to make this change happen.