AdminMenu rendering code chokes on uppercase

[jltallon]

When registering custom taxonomies for a custom post type, if the post type name contains uppercase letters, the menu items for the custom taxonomies are not shown.

It looks like the post type name is lowercased in some parts of the core code (but no all) and so string comparisons fail.
Just isolated this behaviour, so I'm still not sure how much of the core this affects.

Moreover, when I saved posts with the intended mixed-case name, they have been saved to the DB with lowercased post_type

It it is indeed the intended behaviour, a note should be added to the Codex:

"Custom Post Type names must be lowercase"

The attached sample (real) code reproduces the problem by setting "post_type_tag" to "DomainName" instead of "domain_name". Numbers work properly, however.

Tested with latest SVN (RC4 + r17467)

[jltallon]

Test case for "C-P-T case sensitivity" - 'DomainName' vs 'domainname'

[greuben]

You need to register the taxonomies before the custom post type and also you must use 'taxonomies' in register_post_type arguments.

see the attached file.

[jltallon]

Thanks.

The Codex does not clearly specify that it has to be done in this order, so this would be a documentation bug.
Moreover, the fact that doing it in the order I was doing it works, but only with all-lowercase names is at the very least surprising. WP should be case-preserving and case-respecting or be documented as "case
folding". The problem being with varying behaviour and/or lack of documentation, not with the internals as such.

[greuben]

Okay my bad...the order doesn't matter. The taxonomies arg have done the trick.

This is a valid bug. In register_post_type the $post_type is sanitized but in register_taxonomy we are not sanitizing the $object_type array

[jltallon]

wp-includes/post.php, line 822:

$post_type = sanitize_user($post_type, true);

( whereas taxonomy.php, line 313 reads "$args [ ' object_type ' ] = (array) $object_type;" )

The problem being that sanitize_user, in strict mode, changes the intended "custom post type name".
Moreover, it looks like a C-P-T (or taxonomy, for that matter) name shouldn't contain the 'at' sign, right?

Hence, I propose to introduce a new sanitize_object_name function (not filter) for this matter.

(patch follows)

[jltallon]

Alternative b) just use "sanitize key" for register_taxonomy (just like it is done in post.php, line 916)

Unless there is a compelling reason to do so, I think WP should be case-preserving and case-sensitive for user-defined Post-Types and Taxonomies.

[jltallon]

Implement 'sanitize_objectname' and use it for register_post_type and register_taxonomy

[greuben]

Instead of creating a new function we can just array_map to sanitize_key.

[duck_]

See #14910 and #15982 as to why we cannot just replace with sanitize_key.

[nacin]

Let's start with a note added to the Codex page.

[jltallon]

Yes, the documentation piece is needed anyway.

Noted that sanitize_key is a bit too expensive. My "sanitize_objectname" could be made simpler.
Moreover, I did not use sanitize_key (in fact, I replaced its usage for register_object_type) since it wraps names to lowercase, and I wanted it to be case-preserving.

Call the function whatever you like, but (IMHO) we should allow [A-Za-z0-9_] (i.e. "identifier" as in most programming languages) for custom post types and custom taxonomies.

[ocean90]

Duplicate: #16649

[mikeschinkel]

I'd love to see lowercase as a requirement for taxonomy and post type names. They are, after all, internal names and not named for display to the user. having them be lowercase means it's easier to ensure our code can sanitize them. FWIW.

[scribu]

+1 on case folding, for both post types and taxonomies.

[c3mdigital]

Fixed in #16649

[helen]

Replying to c3mdigital:

Fixed in #16649

#16649 was closed as a dupe of this one...