custom post types: "page-attributes" should be "page-attributes"

[F J Kaiser]

The only "-" used in custom post types is in "page-attributes". Everywhere else "_" is used. Assignes as minor.

[F J Kaiser]

Sorry. Misstyped the title:

"page-attributes" should be "page_attributes".

[nacin]

What are you comparing it to?

post_type_supports arguments include: custom-fields, page-attributes, and post-thumbnails. The 'supports' arg for register_post_type is simply a wrapper for register_post_type_support, which uses these slugs.

[F J Kaiser]

Comparing to a) all "parent" definitions/keys and b) all "child" (where the value is and array) definitions in "labels" and "capabilites". It's not major, but it feels strange and is a classic when it comes to bugtracking. I think it could better be an underline instead of the dash to stay in a line with the rest of the function.

[nacin]

For theme and post type support arguments, we consistently use hyphens. post-thumbnails is where it started (which was very widely publicized to theme developers and the like), and it continued for custom-fields and page-attributes. 'supports' is just a wrapper for register_post_type_support.

I agree it has the potential to be confusing, but it is separate in that these are not array keys, they are values. Capabilities are separated with underscores so if you set fine-grained capability control then you will use underscores; while supports arguments have been using hyphens for some time and therefore they will stay.

This is trivial, and the Codex and code documents this well, so I'm suggesting wontfix.

[F J Kaiser]

I know and understand it. I would just let it open as a note for "far in the future" RCs. That's why i set it to "minor". (But you can close it if you want. It's np.)

[nacin]

Let's leave this as is. It's a valid point to make sure we're using consistent naming conventions and it's something we'll continue to consider in the future.