That being said, in this article I will show you how to manage the WordPress toolbar, removing it for specific roles, adding links and menus, and customizing its appearance.<\/p>\n Occasionally, you might want to remove the toolbar from the front-end of your site. You can hide it to all users or for specific roles. The following line \u2013 when added to your functions.php<\/em> file (don’t forget to use a child theme<\/a>!) \u2013 will remove the toolbar for all site users:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n The\u00a0WordPressCodex<\/a> states that the More probably, you may want to show\/hide the toolbar depending on a\u00a0user’s capabilities or role name<\/a>. The following code will hide the admin bar to all users but administrators and editors:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n I said before that the Fatal error: Call to undefined function wp_get_current_user() …<\/strong><\/p><\/blockquote>\n That’s because the In this second example, we’re removing the toolBar for all users except administrators and editors:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n If you want your code to be reusable, it would be preferable to hook the function to the Since version 3.1, WordPress has provided the Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n That’s the same as the following lines:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n And we can show\/hide the toolbar depending on a\u00a0user’s capabilities, as well:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n In this example, the toolbar will be shown only to administrators and editors (they can That’s all that we have to know when we decide to remove the toolbar. But what if we wanted to use the Toolbar to give new powers to our WordPress install?<\/p>\n The In our examples we’re going to use just the following three methods:<\/p>\n Default menus are defined in \/wp-includes\/admin-bar.php<\/a>. Some of them are available for all logged-in users, like the WordPress Logo<\/em> menu (which shows some institutional links), the\u00a0My Account<\/em> menu (which shows some links related to the current user), and Site Name<\/em> menu (which provides quick links to the admin panel).<\/p>\n But WordPress gives us the ability to add custom menus and links, textual information and form fields. I won’t explain here how to add items to the toolbar, as we’ve already covered this topic in How to Add Items to the WordPress Toolbar<\/a>. Rather, I will show you two practical examples of customization, starting with an easy upgrade of the built-in My Account<\/em> menu.<\/p>\n When our goal is adding nodes to the toolbar depending on the user’s role, we have to define a callback function keeping as argument an instance of the Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n I mentioned earlier in this article that we can build new menus as well as adding links to existing menus. In this example, we’re going to provide the current user with a quick link to his\/her personal website, adding a new node to the\u00a0My Account<\/em> built-in menu.<\/p>\n When the admin-bar.php<\/em> loads, a new group of nodes named Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n First, we get the The code above will generate the following mark-up:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n The resulting menu is shown in the image below.<\/p>\n Some Toolbar menus are available only in specific pages. For instance, the Edit post<\/em> menu, which provides a quick link to the editing page of the current post or taxonomy term, appears exclusively in single post pages and taxonomy archives.<\/p>\n This may suggest to us the idea of showing up menus under specific conditions. In the following example, the condition will be provided by the user role.<\/p>\n So, we may like to show to the site editors a role-specific menu holding a group of links pointing to the admin screens of pending posts (one link for each post type). This sort of menu would be extremely useful for multi-author websites when many users write posts (and custom post types) expecting to be reviewed for publication.<\/p>\n Now, let’s get back to our callback function and add the following code:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n In the code above, first, we check whether the current user is an editor. If he\/she is, we add the Now comes the funny part. The Finally, for each post type, we add a node to the And, if you’d like to customize the menu presentation with a gorgeous icon from Dashicon<\/a> set, just append the following code to your plugin or functions.php<\/em> file:<\/p>\n Please update your cookie preferences<\/a> to enable preference cookies to view this gist.<\/p><\/div><\/div>\n The function we’ve hooked to the ![\"default](\"https:\/\/wpmudev.com\/blog\/wp-content\/uploads\/2016\/02\/default_toolbar_full.png\")
Removing the Admin Toolbar<\/h2>\n
show_admin_bar<\/code> function should be called immediately upon plugin load and does not need to be called from a function hooked to the init<\/code> action.<\/p>\nshow_admin_bar<\/code> function does not need to be called from a callback function. So, you may ask why we’re hooking it to the after_setup_theme<\/code> action? In this case, if we didn’t, WordPress would return the following error message:<\/p>\ncurrent_user_can()<\/code> function<\/a> uses wp_get_current_user()<\/code> to retrieve the current user object. This latter function is not available when the plugin loads, so we have to be sure to call current_user_can<\/code> not before the plugins_loaded<\/code> action (check the Codex for a list of typical actions<\/a> in chronological order). If you’re calling current_user_can()<\/code> from within a theme’s (or child theme’s) function file, you’ll need to hook the callback function to the after_setup_theme<\/code> action, instead.<\/p>\nafter_setup_theme<\/code> action in any case.<\/p>\nshow_admin_bar<\/code> filter<\/a>, so we have another way to accomplish the same task. For example, we can hide the toolbar to all users with a single statement:<\/p>\npublish_posts<\/code>).<\/p>\nCustomizing the Admin Toolbar<\/h2>\n
WP_Admin_Bar<\/code> Class<\/a>\u00a0controls the toolbar. Thanks to the class methods we can add and remove menu elements (nodes) and groups of elements.<\/p>\n\n
![\"Site](\"https:\/\/wpmudev.com\/blog\/wp-content\/uploads\/2016\/02\/site_name_menu.png\")
How to add new items to an existing menu<\/h2>\n
WP_Admin_Bar<\/code> object. The function should be hooked to the admin_bar_menu<\/code> action as shown in the following code:<\/p>\nuser-actions<\/code> is added to the\u00a0my-account<\/code> menu. This group of nodes will be considered a parent for any new custom link we adding to the menu. The following code will add the link to the group:<\/p>\n$current_user<\/code> object and check if it is a valid instance of WP_User<\/code>. Then we get the my-account<\/code> node object, which corresponds to the My Account<\/em> menu placed on the right side of the Toolbar. Finally, if the user_url<\/code> meta field and the node object exist, then we add the user-url<\/code> node to the menu.<\/p>\n![\"The](\"https:\/\/wpmudev.com\/blog\/wp-content\/uploads\/2016\/02\/my_account.png\")
An Advanced Example: Conditional Menus, Custom Post Types and More<\/h2>\n
editor-menu<\/code> top-level node (no parent for this node). Later, we add the editor-actions<\/code> group, setting the editor-menu<\/code> item as its parent node.<\/p>\nget_post_types<\/code> function retrieves from the database an array of custom post type objects (more in the Codex<\/a>). For each post type, we check if the logged-in user has the role of editor (she can publish_posts<\/code>). Then we get an array<\/a> of all pending posts in the current post type and count them.<\/p>\neditor-actions<\/code> group. Each link will point to the pending post type screen.<\/p>\n![\"The](\"https:\/\/wpmudev.com\/blog\/wp-content\/uploads\/2016\/02\/editor_menu.png\")
wp_head<\/code> action<\/a> just prints a style element within the head<\/code> of the document. Sure, this is not a best practice when you enqueue a style in a document, but here I assume that we just need one style declaration. Loading a whole CSS file would not be an efficient option.<\/p>\n