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 my question is if I have access to the global $wp_admin_bar object, is there I way I can access the objects inside nodes:WP_Admin_Bar:private? And if not, is there another way to get to these objects, such as creating a new class that extends the WP_Admin_Bar class and then accessing the objects from there?
ps: I’m trying to overcome this challenge without changing the core WordPress files…
Link to the file: http://phpxref.ftwr.co.uk/wordpress/nav.html?wp-includes/class-wp-admin-bar.php.source.html
Change them to protected member variables and extend the class.
Whoever wrote the class with private members effectively made the class “final”. Which goes to show that you should always write your members as protected, unless there’s a really, REALLY good reason to do otherwise.
Hope that helps…