Change to add_new label displays wrong label for old post types

[smerriman]

In #47125, the label for adding a new item in the menu changed its default value from Add New to Add New Post, with developers advised to change their code to match when creating custom content types.

To me this was a mistake; an appropriate label already existed with that wording: the add_new_item label.

If it was desired to change what displayed in the menu, the right fixing was to use display add_new_item, rather than changing the entire meaning of add_new.

I have always registered custom post types by setting add_new_item to 'Add New MyPostType', and leaving add_new out of the array entirely, since there was never a need to override the wording of 'Add New'.

Now, all of my post types for all clients over many years are displaying 'Add New Post'.

Can this change please be reverted, and replaced by displaying add_new_item when you wanted to display the item name, as it was always intended to be used?

[afercia]

@smerriman thanks for your report.

I have always registered custom post types by setting add_new_item to 'Add New MyPostType', and leaving add_new out of the array entirely

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'd think the fundamental issue here is that entirely omitting the add_new label makes WordPress use the default:

'add_new'                  => array( __( 'Add New Post' ), __( 'Add New Page' ) ),

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

I do realize that, apparently, the omission of the add_new label is a case that hasn't been taken into account in #47125. However, I'd recommend to just add the add_new label to all your custom post types and specify the post type name in the strings, as that's the best practice WordPress now recommends.

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

[smerriman]

Replying to 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 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.

[joedolson]

It doesn't seem like a lot of trouble to add a fallback mechanism, and there is an argument in favor of changing the default back to what it was - with the idea that the default represents an "unknown" post type.

That said, it doesn't appear that this has caused many people problems, so it doesn't seem high priority.

Taking ownership to explore further.

[joedolson]

Assigning to @rcreators to follow up.

[rcreators]

@joedolson As I understand the issue, for the custom post type, the default label add_new value changed from Add New to Add New Post / Add New Page for Voice Over and Accessibility.

I suggest reverting to the link's old "Add New" value for the Default Label and Use area-lable=add_new_item for the links in the menu.

That will solve accessibility issues and old custom post-type registration issues with labels.

Let me know if that sounds good, will add a patch for the same.

[joedolson]

It's a sound argument that having two keys 'add_new' and 'add_new_item' implies that the two should be used differently; they look like they should be 'Add New' and 'Add new {item}', which makes sense to me.

In which case, yes, we should change core to useadd_new_item and should change the fallback for add_new to be just 'Add New'.

We should also add documentation to indicate that use of the 'add_new' key is discouraged, but retained for backwards compatibility.

[chaion07]

Thanks @smerriman for reporting this. We reviewed this ticket during a recent core triage session. We feel the need for a new patch for this.

Props to @cbravobernal for the suggestion

Cheers!

[chaion07]

Adding the good-first-bug keyword since @joedolson has gived some instructions and as @cbravobernal suggested. Thank you both.

[eclev91]

@chaion07 To @rcreators's point, an aria-label could add context in these menu items, but for the sake of this ticket, should that be considered a separate enhancement?

…ing " Post" to the "add_new" default.

Trac ticket: https://core.trac.wordpress.org/ticket/60045

[johnbillion]

Let's address the aria-label issue in a separate ticket please

Can you also update the function documentation for [https://github.com/WordPress/wordpress-develop/blob/6.6.2/src/wp-includes/post.php#L2093-L2133 get_post_type_labels()] to change the default value shown for add_new and note that add_new_item is preferred?

Patch on 60045 with current trunk.

Trac ticket: ​https://core.trac.wordress.org/ticket/60045

[joedolson]

Updated PR to also apply to the two other uses of the add_new label, and updated function documentation.

I don't see much of a use for aria-label here; with this change, there is no usage of add_new in core, so essentially this exists only for back compatibility, and we don't have any way of knowing where that parameter might be used in custom code.

Marking for commit. This is effectively the same as it was before, except that core now references the add_new_item parameter instead of the add_new parameter. This seems more appropriate to me, since the phrase used is of the format "Add New {item}", not "Add New".

Marking for commit.

[joedolson]

In 59161:

Administration: Switch core post type labels to add_new_item.

In [56515], the default value of Add New was changed to "Add New Post / Add New Page". This caused problems with post types where add_new was not declared.

Change core usage to reference the add_new_item value and revert the default value of add_new back to "Add New / Add New". This retains the accessibility advantages without creating counter intuitive usage of the add_new key.

With this change, post types registered with no add_new key will be unimpacted in core, and post types registered with no add_new_item key will use the default "Add New Post", which is not a change from the current state.

Props smerriman, afercia, rcreators, joedolson, eclev91, johnbillion.
Fixes #60045.

In r59161

In r59161

[room34]

The [documentation](​https://developer.wordpress.org/reference/functions/get_post_type_labels/) for add_new vs. add_new_item is unclear. How exactly does "Label for adding a new item" (the description of add_new) differ from "Label for adding a new singular item" (the description of add_new_item)?

In practice, add_new is the text that populates the admin menu, and add_new_item is the text that becomes the page title when you click through to that page.

I have leveraged this difference in my plugins, using add_new as a brief label for the admin menu link, and add_new_item as the full text intended to appear as the page title (in the <h1> tag).

With this change, it's now impossible to have different text in the menu than in the page title.