Found during the 1.3.0 review, while fixing the equivalent bug for admin menus (MenuGrouperTrait::group_menus()).
What happens
includes/Admin/Settings/TabAdminBar.php → group_nodes() emits a child node only while iterating its parent's entry in $parents, and a node only counts as a parent when its own parent field is empty or unknown. A grandchild is therefore never visited, so it never gets a checkbox on the Admin Bar tab.
Against the real WordPress hierarchy (my-account → user-actions → user-info / edit-profile / logout, see wp-includes/admin-bar.php):
rendered: my-account, user-actions, search
dropped : user-info, edit-profile, logout
All three dropped nodes are in CoreAdminBarItems::CORE_IDS, so they are discovered — they simply have no UI.
Why it matters
logout is protected, so it survives at runtime. user-info and edit-profile are not protected. Because they never render a checkbox, they are absent from $_POST the first time a user saves the Admin Bar tab, drop out of the saved visible list, and remove_node() deletes them from the Howdy menu — with no way to restore them from the settings screen.
Scope
Pre-existing since 1.2.0; not a regression introduced by 1.3.0, which is why it was not a release blocker.
Suggested fix
Mirror what MenuGrouperTrait::group_menus() now does for orphaned submenus: resolve the hierarchy to arbitrary depth, or fall back to listing any node whose parent was not emitted, so nothing is silently unmanageable. The tests/Unit/Admin/Settings/MenuGrouperTraitTest.php cases are a good template — the equivalent test coverage for group_nodes() is missing today.
Found during the 1.3.0 review, while fixing the equivalent bug for admin menus (
MenuGrouperTrait::group_menus()).What happens
includes/Admin/Settings/TabAdminBar.php→group_nodes()emits a child node only while iterating its parent's entry in$parents, and a node only counts as a parent when its ownparentfield is empty or unknown. A grandchild is therefore never visited, so it never gets a checkbox on the Admin Bar tab.Against the real WordPress hierarchy (
my-account→user-actions→user-info/edit-profile/logout, seewp-includes/admin-bar.php):All three dropped nodes are in
CoreAdminBarItems::CORE_IDS, so they are discovered — they simply have no UI.Why it matters
logoutis protected, so it survives at runtime.user-infoandedit-profileare not protected. Because they never render a checkbox, they are absent from$_POSTthe first time a user saves the Admin Bar tab, drop out of the saved visible list, andremove_node()deletes them from the Howdy menu — with no way to restore them from the settings screen.Scope
Pre-existing since 1.2.0; not a regression introduced by 1.3.0, which is why it was not a release blocker.
Suggested fix
Mirror what
MenuGrouperTrait::group_menus()now does for orphaned submenus: resolve the hierarchy to arbitrary depth, or fall back to listing any node whose parent was not emitted, so nothing is silently unmanageable. Thetests/Unit/Admin/Settings/MenuGrouperTraitTest.phpcases are a good template — the equivalent test coverage forgroup_nodes()is missing today.