id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
19371	As of 3.3beta2 WP_Admin_Bar no longer provides a way to access attributes of existing menu items	willshouse	koopersmith	"Up until around 3.3beta1 items in the `WP_Admin_Bar Object` could be accessed using this type of syntax, for example to change the CSS class of one of the existing menu items:

{{{
$wp_admin_bar->menu->{'wp-logo'}['meta']['class'] = 'new-class';
}}}

When running `print_r($wp_admin_bar)` the output looked something like this:

{{{
WP_Admin_Bar Object
(
	[menu] => stdClass Object
		(
			[my-account] => Array
				(
}}}

However, around version `3.3beta2` the above syntax for changing a menu item's CSS class no longer works, and the output from `print_r($wp_admin_bar)` reveals a different structure for that object:

{{{
WP_Admin_Bar Object
(
	[nodes:WP_Admin_Bar:private] => Array
		(
			[my-account] => stdClass Object
				(
					[id] => my-account

				)
}}}					

I realize that Wordpress may not want me fiddling with the menus this way, and if there was a more standardized way to do this I would love to use it, but as far as I know there are only two functions that are available to modify the admin bar, `add_menu_item` and `remove_menu_item`, and these do not give the flexibility to do things like changing the attributes of existing menu items.

To confirm, I looked at `wp-includes/class-wp-admin-bar.php` it is clear that Wordpress has changed the way they define the variables.


Old Class

{{{
class WP_Admin_Bar {
	var $menu;
	var $proto = 'http://';
	var $user;
}}}

New Class

{{{
class WP_Admin_Bar {
	private $nodes = array();
	private $root = array();

	public $proto = 'http://';
	public $user;
}}}

So basically the problem is that there is no longer any way to access attributes for existing menu items in the WP admin bar unless I make changes to the WP core files myself.

BTW I submitted this to Stack Exchange for suggestions ( http://stackoverflow.com/questions/8286798/ ) and the response was that the `private` variables should be `protected` variables. At least that would give me something to work with."	defect (bug)	closed	high	3.3	Toolbar	3.3	minor	fixed	has-patch commit