[wp-trac] [WordPress Trac] #58062: Positioning of custom post type submenu
WordPress Trac
noreply at wordpress.org
Tue Apr 11 13:35:01 UTC 2023
#58062: Positioning of custom post type submenu
-------------------------------+---------------------------------
Reporter: mort1305 | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Posts, Post Types | Version: 6.2
Severity: normal | Resolution:
Keywords: | Focuses: ui, administration
-------------------------------+---------------------------------
Changes (by sabernhardt):
* component: Menus => Posts, Post Types
Old description:
> '''Current Functionality (since 3.1.0):''' One can add a CPT as a
> submenu of another CPT by setting the ''show_in_menu'' argument of the
> ''register_post_type()'' function as
> ''edit.php?post_type=CUSTOM_CPT_SLUG''. The submenu is then added into
> the administration menu by way of the ''_add_post_type_submenus()''
> function. When this occurs, the submenu CPT's are displayed in the order
> the CPTs were registered.
>
> '''Problem:''' The current coding prohibits the ordering of CPT submenu
> items per the programmer's desires in the event CPT registration is
> unable to be controlled or in the event other submenu pages are added via
> the ''add_submenu_page()'' method. This occurs because the call to
> [https://developer.wordpress.org/reference/functions/add_submenu_page/#source
> add_submenu_page()] by
> [https://developer.wordpress.org/reference/functions/_add_post_type_submenus/#source
> _add_post_type_submenus()] only passes 5 arguments. (The sixth omitted
> argument is what handles menu positioning.)
>
> '''Solution:''' The ''menu_position'' argument passed to the
> ''register_post_type()'' function already exists, and defines a CPT's
> positioning within a menu. The solution is to incorporate this argument
> into the core by modifying line 2079 of
> [https://core.trac.wordpress.org/browser/tags/6.2/src/wp-
> includes/post.php#L2079 wp-includes/post.php] as follows:
> {{{
> add_submenu_page(
> $ptype_obj->show_in_menu,
> $ptype_obj->labels->name,
> $ptype_obj->labels->all_items,
> $ptype_obj->cap->edit_posts,
> "edit.php?post_type=$ptype",
> is_set($ptype_obj->menu_position) ? $ptype_obj->menu_position : NULL
> );
> }}}
New description:
''Current Functionality (since 3.1.0):'' One can add a CPT as a submenu
of another CPT by setting the `show_in_menu` argument of the
`register_post_type()` function as `edit.php?post_type=CUSTOM_CPT_SLUG`.
The submenu is then added into the administration menu by way of the
`_add_post_type_submenus()` function. When this occurs, the submenu CPT's
are displayed in the order the CPTs were registered.
''Problem:'' The current coding prohibits the ordering of CPT submenu
items per the programmer's desires in the event CPT registration is unable
to be controlled or in the event other submenu pages are added via the
`add_submenu_page()` method. This occurs because the call to
[https://developer.wordpress.org/reference/functions/add_submenu_page/#source
add_submenu_page()] by
[https://developer.wordpress.org/reference/functions/_add_post_type_submenus/#source
_add_post_type_submenus()] only passes 5 arguments. (The sixth omitted
argument is what handles menu positioning.)
''Solution:'' The `menu_position` argument passed to the
`register_post_type()` function already exists, and defines a CPT's
positioning within a menu. The solution is to incorporate this argument
into the core by modifying line 2079 of
[https://core.trac.wordpress.org/browser/tags/6.2/src/wp-
includes/post.php#L2079 wp-includes/post.php] as follows:
{{{
add_submenu_page(
$ptype_obj->show_in_menu,
$ptype_obj->labels->name,
$ptype_obj->labels->all_items,
$ptype_obj->cap->edit_posts,
"edit.php?post_type=$ptype",
isset($ptype_obj->menu_position) ? $ptype_obj->menu_position : NULL
);
}}}
--
--
Ticket URL: <https://core.trac.wordpress.org/ticket/58062#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list