#14698 closed enhancement (wontfix)
Adding custom menu items in a WP managed menu
Reported by: | Owned by: | ||
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | minor | Version: | 3.0.1 |
Component: | Menus | Keywords: | |
Focuses: | Cc: |
Description
In Walker:walk() line 932 of classes.php (WP version 3.0.1), the comparison of the parent ID to 0 is done so using ==. This is an issue if you're trying to manually insert a menu item for a term within a menu consisting of posts. I would like to be able to set the parent_id to something like 'term:4' (with 4 being the ID of the term). But because it is a string and comparing a string to zero with == will always equate to false.
I suggest that line 932 is changed from:
if ( 0 == $e->$parent_field )
to:
if ( empty( $e->$parent_field ) )
The end result I'm looking for is a way to take an existing menu and add in sub-items for a particular item that contains all the terms from a given taxonomy. Then for each of the term items, add child items for all of the custom posts associated to the term. For the time being, I'm using a negative db_id to bypass the comparison issue.
Here's a sample of my code:
function my_get_nav_menu_items($items, $menu, $args) { if ($menu->slug != 'primary') { return $items; } $findAProgram = null; foreach ($items as $item) { if ($item->post_name = 'find-a-program') { $findAProgram = $item; break; } } if ($findAProgram) { $order = count($items); foreach (get_terms('program-focus') as $term) { $posts = get_posts("taxonomy=program-focus&term={$term->term_slug}&post_type=programs"); if (!empty($posts)) { $term = wp_setup_nav_menu_item($term); $term->menu_item_parent = $findAProgram->db_id; // set db_id to negitive value to avoid collisions with posts with the same ID // This is needed due to the non-strict equality check in classes.php // line 932 in Walker::walk(). I would love to use a string for the // term ID's (something like 'term:4'), but "any string" == 0 will // always return false. $term->db_id = -1*$term->ID; $term->menu_order = $order++; $items[] = $term; foreach ($posts as $post) { $post = wp_setup_nav_menu_item($post); $post->menu_item_parent = $term->db_id; $post->menu_order = $order++; $items[] = $post; } } } } return $items; } add_filter('wp_get_nav_menu_items', 'my_get_nav_menu_items', 10, 3);
Change History (8)
#1
@
14 years ago
- Summary changed from Added custom menu items to Adding custom menu items in a WP managed menu
#2
@
14 years ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
#3
@
14 years ago
- Resolution invalid deleted
- Status changed from closed to reopened
I agree that the following lines of code is a pretty nasty hack
// set db_id to negitive value to avoid collisions with posts with the same ID // This is needed due to the non-strict equality check in classes.php // line 932 in Walker::walk(). I would love to use a string for the // term ID's (something like 'term:4'), but "any string" == 0 will // always return false. $term->db_id = -1*$term->ID;
That doesn't change the fact that it's not possible to inject a mixture of posts and categorizes into a menu without the risk of a collision in db_id's. It doesn't really matter to me how this is fixed. In fact the requirements on my project changed and we ended up using a custom post type instead of a category. In my opinion, wp_setup_nav_menu_item() should be able to prepare pages, posts, categories, menu_items, etc. to be added to a menu. The way that it is now, if a page and a taxonomy term have the same db_id, the one will override the other. If you really feel strongly that this doesn't warrant a fix, please re-close it and I'll leave it alone. Just trying to help.
#5
@
14 years ago
set db_id to negitive value to avoid collisions with posts with the same ID
This is needed due to the non-strict equality check in classes.php
line 932 in Walker::walk(). I would love to use a string for the
term ID's (something like 'term:4'), but "any string" == 0 will
always return false.
$term->db_id = -1*$term->ID;
This looks like a dirty, dirty hack, and a change to empty() should not be done to support it.