[wp-trac] [WordPress Trac] #60045: Change to add_new label displays wrong label for old post types

[WordPress Trac]

#60045: Change to add_new label displays wrong label for old post types
----------------------------+------------------------------
 Reporter:  smerriman       |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  6.4
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  accessibility
----------------------------+------------------------------

Comment (by smerriman):

 Replying to [comment:3 afercia]:
 > The WordPress admin menu always used the `add_new` post type label and
 I'm not sure that can be changed without introducing problems.

 I'm not sure what the problems would be. As it stands, the behavior
 currently is very confusing; the latest version of the documentation asks
 you to provide two different labels (add_new and add_new-item), without
 any sense of why they should be distinguished or where each is used.

 (As far as I can tell by hunting through the code, add_new is used in the
 menu and nowhere else in WordPress; add_new_item is used in many other
 places such as the title for the add term page, and in other metaboxes).

 The apparently intent of #47125 was that add_new should never be used
 anymore, given the inaccessibility of the text, so it makes more sense to
 match it with the more accessible label used throughout the rest of the
 site.

 > While providing ''all'' the post type labels isn't strictly required, it
 is highly recommended.

 This doesn't appear to be the case, at least not as described anywhere in
 the documentation; it makes it the default values very clear. Duplicating
 default values isn't standard practice (consider all of the default
 parameters through WordPress functions; it would be silly if these were
 provided in every function call).

 In fact, it's not even done by core; calls to `register_post_type` in core
 code only provide some of the labels, relying on the defaults for the
 rest.

 > Alternatively, core should add a new fallback mechanism to check whether
 `add_new` is omitted and provide the old defaults if that's the case. I'd
 see such additional fallback as a bit overkill though. Cc @joedolson

 There's no need for a new fallback mechanism; simply change the default
 parameter back to what it was. If you want to override the default for
 core types, then pass that value when registering the post type. Changing
 the default value for a parameter that has been around over 10 years can't
 really do anything but introduce problems.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60045#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform