Wrong attribution of current_page_parent for menus when on single/archive CPT

[tabrisrp]

• When on a single CPT page, the menu item receiving the class current_page_parent is the blog archive page, and not the archive CPT page.

• When on an archive CPT page that is in a submenu, the menu item receiving the class current_page_parent is the blog archive page, and not the parent menu item. Also, the parent menu item doesn't have the current-menu-parent and current-menu-ancestor classes.

This plugin has some functions that deal with this issue, but it's probably something that should be fixed in core now since archive CPT page are available by default. ​https://wordpress.org/plugins/sf-archiver/

[helen]

Hi @tabrisrp - welcome to Trac. Is this new to trunk (4.4 development) or does it exist earlier?

[tabrisrp]

Replying to helen:

Hi @tabrisrp - welcome to Trac. Is this new to trunk (4.4 development) or does it exist earlier?

Hi @helen,

Happy to join and help improving WP :)

It exists since before the 4.4, as the plugin I linked already did changes on the menu item classes and is working with 4.3 and earlier. It's probably there from the start of the new menu system.

It only came to my attention now thanks to a currently in development website.

[helen]

Thanks - needed to check if this was something we needed to fix before releasing 4.4. Upon further inspection, I feel fairly certain this is a duplicate of something but cannot locate it at the moment.

[tabrisrp]

It most probably has been reported before, but I was not able to find a corresponding ticket.

It's mostly a design issue for themes, because if you're styling those classes has a position indicator on the website, it will be wrong on some pages.

I think it could get a small priority bump now that the archives CPT pages are available in the menu editor.

It's also an issue in a specific case I encountered, where I filter a menu to extract its sub-menus based on the menu parent classes. For the archives CPT page and single CPT page, the wrong sub-menu is extracted because of this bug.

[mdgl]

With regard to the first issue, see #16382 which is marked "wontfix" as it seems current_page_parent is added as a backwards-compatibility measure. New themes/plugins should best rely only on the newer classes (with hyphens).

For the other problems, code to properly set the menu item parent/ancestor classes was missing for custom post type archives. In fact, this code shouldn't be dependent on object type, so in the forthcoming patch I have factored this out into a common block. This also makes function _wp_menu_item_classes_by_context() slightly easier to read and understand (but still pretty opaque!).

I took the opportunity of incorporating the fix for #32918 at the same time (easier now the code is in just one place).

It's likely a number of other bugs are lurking in this area of code. We could really do with some unit tests: see #32367.

This is only a refresh of 34839.diff

Disclaimer: I have not reviewed this code. This refresh is just for testing purposes.

More code assessment is required to see if it's adequately covering the problem stated in the ticket

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

[SirLouen]

Test Report

Description

✅ This report validates whether the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/9039.diff

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 137.0.0.0
• OS: Windows 10/11
• Theme: Twenty Sixteen 3.5
• MU Plugins: None activated
• Plugins:
  • Category Posts in Custom Menu - Free 3.0 3.0.3
  • Test Reports 1.2.0

Testing Instructions

1. I'm using Category Posts in Custom Menu plugin to showcase the problem easily
2. Add some pages. For this test, I've added 4 pages
3. Add a post category
4. Add 2 posts to this newly created category
5. I'm using 2016 theme to configure menus more clearly
6. Go to menus and add the following

• First page as parent, second page as child of first
• Third page as parent, fourth page as child of third
• Add the category as child of Third.
• Enable the feature of the plugin previously installed in the category: Replace by posts in this category

7. Go to the front end
8. Click on the second page
9. You will see that current_page_ancestor is present (check Supp artifacts)
10. Click on any of the two posts that popped under the Third page submenu
11. 🐞 Page ancestor is not present (check Supp artifacts)

Expected Results

• Ancestors are respected in all scenarios

Actual Results

1. ✅ Issue resolved with patch (check Supp Artifacts)

Additional Notes

• Now I'm noticing that #32918 is essentially the same. That ticket was before this, but given that almost a decade has passed since inception of both ticket, and this has a better patch, I'm going to close the other one in favour of this.

needs-code-review

• I have not reviewed the code, only tested the behaviour. As I commented before, further assessment is required to evaluate if this patch should move forward.

• As @mdgl commented maybe some Unit tests could be added in the same place as the ones provided in #32367 (needs-unit-tests)

Supplemental Artifacts

Regular Nav Menu with Parent-Child Ancestors Class

Nav menu with Parent-Child within the logic of the plugin (no ancestor)

Nav menu with Parent-Child with Patch (has ancestor)

[SirLouen]

#32918 was marked as a duplicate.