string(77) "edit-tags.php?taxonomy=acs-field-group-category&post_type=acs-field-group" string(73) "edit-tags.php?taxonomy=acs-field-group-category&post_type=acs-field-group"
Same string, different length!
No, they’re not the same string — if you had viewed the raw/server-generated HTML source, or used this instead of the var_dump($submenu_file);
:
echo '<pre>'; var_dump($submenu_file, $sub_item[2]); echo '</pre>';
Then you would have seen the correct string which uses &
instead of just &
:
string(77) "edit-tags.php?taxonomy=acs-field-group-category&post_type=acs-field-group"
So that means, your (sub-)menu slug (the 5th parameter for add_submenu_page()
) needs to use the ampersand’s HTML entity, i.e. &
, like so:
add_submenu_page( $slug, __('Categories','acs'), __('Categories','acs'), $cap, // wrapped for brevity
'edit-tags.php?taxonomy=acs-field-group-category&post_type=acs-field-group' ); // ← use &
That way, the submenu would be active when the submenu page is loaded.
And actually, you can see a core example here in wp-admin/edit-tags.php
(WordPress v6.0.1), which implies that $submenu_file
(the submenu slug) expects &
to be used.
PS: Remember to restore the original wp-admin/menu-header.php file
— remove your “hack”/modifications.