Make WordPress Core

Opened 4 months ago

Last modified 6 weeks ago

#60045 accepted defect (bug)

Change to add_new label displays wrong label for old post types

Reported by: smerriman's profile smerriman Owned by: joedolson's profile joedolson
Milestone: Future Release Priority: normal
Severity: normal Version: 6.4
Component: Administration Keywords:
Focuses: accessibility Cc:

Description (last modified by SergeyBiryukov)

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?

Change History (8)

#1 @SergeyBiryukov
4 months ago

  • Description modified (diff)

#2 @SergeyBiryukov
4 months ago

  • Focuses accessibility added

#3 follow-up: @afercia
4 months ago

@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

#4 in reply to: ↑ 3 @smerriman
4 months ago

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.

Last edited 4 months ago by smerriman (previous) (diff)

This ticket was mentioned in Slack in #core-test by ankit-k-gupta. View the logs.


4 months ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


6 weeks ago

#7 @joedolson
6 weeks ago

  • Milestone changed from Awaiting Review to Future Release
  • Owner set to joedolson
  • Status changed from new to accepted

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.

#8 @joedolson
6 weeks ago

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.

Note: See TracTickets for help on using tickets.