Opened 4 years ago
Last modified 11 months ago
#50438 new defect (bug)
item_ labels do not work once registered in a post type
Reported by: | ninetyninew | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Posts, Post Types | Keywords: | close |
Focuses: | docs | Cc: |
Description
Labels starting with prefix item_ from here:
https://developer.wordpress.org/reference/functions/get_post_type_labels/
Are not used in the dashboard when registering them in a custom post type.
<?php $labels = array( 'name' => _x( 'Cars', 'Post Type General Name', 'abcde' ), 'singular_name' => _x( 'Car', 'Post Type Singular Name', 'abcde' ), 'menu_name' => __( 'Cars', 'abcde' ), 'name_admin_bar' => __( 'Car', 'abcde' ), 'archives' => __( 'Car Archives', 'abcde' ), 'attributes' => __( 'Car Attributes', 'abcde' ), 'parent_item_colon' => __( 'Parent Car:', 'abcde' ), 'all_items' => __( 'All Cars', 'abcde' ), 'add_new_item' => __( 'Add New Car', 'abcde' ), 'add_new' => __( 'Add New', 'abcde' ), 'new_item' => __( 'New Car', 'abcde' ), 'edit_item' => __( 'Edit Car', 'abcde' ), 'update_item' => __( 'Update Car', 'abcde' ), 'view_item' => __( 'View Car', 'abcde' ), 'view_items' => __( 'View Cars', 'abcde' ), 'search_items' => __( 'Search Car', 'abcde' ), 'not_found' => __( 'Not found', 'abcde' ), 'not_found_in_trash' => __( 'Not found in Trash', 'abcde' ), 'featured_image' => __( 'Initial Image', 'abcde' ), 'set_featured_image' => __( 'Set initial image', 'abcde' ), 'remove_featured_image' => __( 'Remove initial image', 'abcde' ), 'use_featured_image' => __( 'Use as initial image', 'abcde' ), 'insert_into_item' => __( 'Insert into Car', 'abcde' ), 'uploaded_to_this_item' => __( 'Uploaded to this Car', 'abcde' ), 'items_list' => __( 'Cars list', 'abcde' ), 'items_list_navigation' => __( 'Cars list navigation', 'abcde' ), 'filter_items_list' => __( 'Filter Cars list', 'abcde' ), 'item_published' => __( 'Car published', 'abcde' ), 'item_published_privately' => __( 'Car published privately', 'abcde' ), 'item_reverted_to_draft' => __( 'Car reverted to draft', 'abcde' ), 'item_scheduled' => __( 'Car scheduled', 'abcde' ), 'item_updated' => __( 'Car updated', 'abcde' ), ); $capabilities = array( 'edit_post' => 'update_core', 'read_post' => 'update_core', 'delete_post' => 'update_core', 'edit_posts' => 'update_core', 'edit_others_posts' => 'update_core', 'delete_posts' => 'update_core', 'publish_posts' => 'update_core', 'read_private_posts' => 'update_core' ); $args = array( 'label' => __( 'Car', 'abcde' ), 'description' => __( 'Post Type Description', 'abcde' ), 'labels' => $labels, 'supports' => array( 'title', 'thumbnail' ), 'hierarchical' => false, 'public' => false, 'show_ui' => true, 'show_in_menu' => true, 'menu_position' => 40, 'menu_icon' => 'dashicons-businessman', 'show_in_admin_bar' => true, 'show_in_nav_menus' => false, 'can_export' => true, 'has_archive' => false, 'exclude_from_search' => true, 'publicly_queryable' => false, 'rewrite' => false, 'capabilities' => $capabilities, 'show_in_rest' => false, ); register_post_type( 'abcde_car', $args );
e.g. on post update the notice is Post updated. Not Car updated.
Change History (5)
#2
@
4 years ago
I see, is there any reason why these couldn't be used in that scenario? I often see custom post types which are registered without the block editor support as they contain no content area at all - just meta boxes with fields to attach meta to the post type.
#3
@
4 years ago
- Keywords needs-patch added
Good point, let's look into using these labels regardless of the post type's editor support.
At a glance, seems like they could be used in wp-admin/edit-form-advanced.php
.
#5
@
11 months ago
- Keywords close added; needs-patch removed
I've been working on this ticket during the Yoast Contributor Day.
It looks like there is a mismatch between the labels used by the Block editor and those used by the Classic editor, making it difficult to map the former to the latter.
In detail:
- Classic editor has
Post restored to revision from %s.
which is missing in the Block editor labels - Classic editor has
Post saved.
which is missing in the Block editor labels (though I'm not sure whether it's still used) - Classic editor has
Post submitted.
, to be followed by a preview link, while Block editor usesDraft saved
(not tied to a post type) - Classic editor has
Post scheduled for: %s.
(%s is the date), while Block editor has justPost scheduled.
- Classic editor has
Post draft updated.
while Block editor uses eitherDraft saved
(not tied to a post type) when simply updating orPost reverted to draft.
when unpublishing a post - Block editor has
Post published privately.
which is missing in the Classic editor labels - Block editor has
Post trashed
which is missing in the Classic editor labels (though it looks unused at the moment)
Considering all the above, I don't think it's easy to find a solution here, unless we either add Classic editor-oriented labels to the array, or change the behavior of the Classic editor notices (losing useful info in some cases, e.g. when scheduling), or a mix of the two things.
While we can have a few improvements on the Block editor side (Post scheduled for: %s.
would be a nice addition), I don't think it's likely to refactor Classic editor to support Block editor labels.
The most immediate way to add custom messages for custom post types is still to hook into post_updated_messages
https://developer.wordpress.org/reference/hooks/post_updated_messages/ and add items there. In fact, even for block editor-based post types you'd need to hook into bulk_post_updated_messages
https://developer.wordpress.org/reference/hooks/bulk_post_updated_messages/ to customize the notices in the post list (so you have 1 car moved to the Trash
instead of 1 post moved to the Trash
).
My proposal then is to close
instead of leaving this pending while there is already a documented way to achieve the intended result.
Hi there, welcome back to WordPress Trac! Thanks for the report.
It should probably be better documented, but
item_published
and otheritem_*
labels are only used for post types that support block editor:'supports' => array( ..., 'editor' )
'show_in_rest' => true
If the post type does not support editor, or only supports classic editor, these labels are indeed not used.