WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#19077 closed defect (bug) (fixed)

Custom Post Type Sub-Menu Items Broken

Reported by: Jick Owned by: nacin
Milestone: 3.3 Priority: normal
Severity: major Version: 3.3
Component: UI Keywords: has-patch
Focuses: Cc:
PR Number:

Description

If you add a sub-menu item to a custom post type the menu and page title break when attempting to view that sub-page. I mean, the menu item is not properly highlighted when you're on the sub-page and the page title is also not correct. For example, my site is called "My Test Site". This is what I see for the page title:

‹ Easy Admin Color Schemes — WordPress

In other words, there is no title for the actual page before the ‹ part.


Really, it's easier to just see it. I have attached a very simplified test case. I can see the problems with the latest trunk version of WordPress.

Attachments (3)

custom-post-type-sub-page-test.php (592 bytes) - added by Jick 8 years ago.
19077.patch (646 bytes) - added by SergeyBiryukov 8 years ago.
19077.2.patch (614 bytes) - added by SergeyBiryukov 8 years ago.

Download all attachments as: .zip

Change History (11)

#1 @nacin
8 years ago

  • Milestone changed from Awaiting Review to 3.3

#2 @Jick
8 years ago

Whoops! Just noticed the original ticket has a slight error. Not sure how to edit it. Where it has:

‹ Easy Admin Color Schemes — WordPress

It should actually be:

‹ My Test Site — WordPress

Mixed a couple things I'm working on up. :P Sorry about that...

#3 follow-up: @SergeyBiryukov
8 years ago

  • Keywords has-patch added

Since [19052], WP_Screen::set_current_screen() overwrites $typenow with $current_screen->post_type, even if it's empty. Before that, it used to be vice versa:
$current_screen->post_type was set from $typenow.

19077.patch is an attempt to restore previous behaviour.

#4 in reply to: ↑ 3 @SergeyBiryukov
8 years ago

Replying to SergeyBiryukov:

$current_screen->post_type was set from $typenow

Correction: only in some cases (e.g. 'edit' == $current_screen->id).

But still, $typenow wasn't overwritten with an empty value in other cases (e.g. 'mycustomposttype_page_customposttypesubpage' == $current_screen->id).

#5 @nacin
8 years ago

  • Owner set to nacin
  • Status changed from new to reviewing

#6 @SergeyBiryukov
8 years ago

19077.2.patch just prevents overwriting globals, leaving $current_screen->post_type as is (which is probably closer to the previous behaviour).

#7 @Jick
8 years ago

It looks like [19097] fixed these issues (for me at least). :D

#8 @SergeyBiryukov
8 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

Confirmed as fixed in [19097].

Note: See TracTickets for help on using tickets.