In my last post, I talked about how to add a custom meta box with a custom link to WordPress navigation menus. Several times, I mentioned how I needed to add a specific class to that link for WishList Login 2.0, so that I could find that link later and do stuff with it.
This is the part where we “do stuff” with that link. Specifically, we’re going to hook into the navigation menu before it displays, find our link and change its display based on the current user’s login status. Here’s what it looks like:
So, if they’re logged in, we’re going to change it to a logout link. If they’re not logged, then we’ll leave it alone. Here’s the code to do that:
Here’s a run-down of what’s happening:
- We’re hooking in using the wp_nav_menu_objects filter.
- If the user is logged out, we just return the link as it is since by default it’s a login link.
- If the user is logged in, we then loop through the items and search the “classes” array element for our class.
- If the class exists in an item object, then we alter the “title” and “url” of that link and we unset our target class from the object.
- Then, we simply return the new objects array.
There’s definitely some customization and abstraction you could do with this:
1. Edit only the menu for a certain theme location. You’ll notice in the hook, I have 2 arguments being sent to the callback function, but I’m only actually using the first one. That’s to show you that there are actually 2 arguments available. The second one is the $args array which will contain information about that menu… including the theme location.
You would simply run a check on that array to see if the current theme location is the one you want to edit. This is especially important if you don’t want to touch widget menus at all… since, the Custom Menu widget uses the same back-end functionality as regular menus.
In our case, we wanted to hijack every instance of a link that contained our special class… even in a widget… so, we didn’t run any such check.
2. Abstract the target class. In our function, the target class we search for is hard-coded. In this instance, it’s fine because there’s no reason to have an option to change that class. You may have a scenario where it does make sense to allow users to change that class. In this case, you’d want to abstract that out by creating an admin option. You could then use get_option() to retrieve the target class and alter your menu accordingly.
So, that’s it. It’s a pretty straight-forward way to hook in and alter navigation menus how you’d like. And, IMHO, a hell of a lot easier than dealing with wp_nav_menu_items() and futzing with parsing HTML, and so on.
