Adding menu items to the admin bar
@r-a-y thanks Ray thought there was something other than I had. edit// Running this function in bp-custom.php or functions.php and I can’t get anything out of $current_blog and scoped just about everything I can think of.
@pcwriter what portion of the function are you wrapping, I was simply thinking that the ul containing the community links was wrapped and removed if not primary blog, but I think I’m probably missing what you are attempting to achieve. Try dropping back to the $blog_id until Ray has a moment to clarify.
You need to call the global before you can use it.
The blog id is $current_blog->blog_id
$current_blog is a multi-site only variable though. I haven’t read the whole thread so I’m not sure what you guys are trying to do
Yeah I did scope the variable, didn’t check what was available i.e dump it should have guessed at blog_id though, but I’m trying not to work at the moment
Hi guys… nap’s over.
Thanks for continuing on this fun little ploblom!
@hnla I’m trying to wrap the entire ul containing both the “Community” dropdown AND the WP pages dropdowns so that they ONLY appear on the main blog (yes, it’s multisite on WPMU2.9.2 and I just upgraded to BP126.96.36.199).
@r-a-y Should the global be called before function pages() is started, or within it?
You have to add the global to the function scope. functions create a new scope and you need to bring the variable into that scope so it’s available to the function.
Just tried adding the global and the conditional as I think has been suggested ( ).
It’s here: http://pastebin.com/PAyLNmES
on lines 2, 7 & 65.
Is this correct? With this code running, no dropdowns show anywhere. They should show, but only on the main site.
Global should be called inside the function you’re creating.
I’ve fixed up the code:
Ray your pate bin example is what I had, have to admit though it doesn’t work for me run from bp-custom or functions my original using $blog_id does though, anyhow this is pcwriters script so I’ll back off for the minute.
I haven’t checked the rest of pcwriter’s code, I only checked the $current_blog variable.
Bingo! I guess my brain was still foggy after my nap.
@hnla said add the global to the function scope… I had added it before the function (doh!)
@r-a-y I forgot to add the ->blog_id bit
With the help of both of you, it works perfectly now! BP Community and WP page dropdowns now DO NOT appear on sub-blogs. (Those few WP pages that mysteriously appear in the adminbar in the backend can be excluded simply by adding their page IDs in the code.)
Thanks a bunch guys!
I just packaged the code as a simple plugin and tested it on my install. It works perfectly.
One question you may help me with though: as this code calls BP pages, is it necessary to check whether BP is active?
As far as I can tell, if BP isn’t active, it’ll simply create dropdowns of WP pages. But I’ve been wrong before
I would say yes, but let Ray confirm that, I realise that my issue was probably running this in bp-custom before BP had intialised? as I was throwing errors on function calls so would think you should check if BP is active but Ray will know how best to proceed.
Did you not include the menu region code I showed in that earlier thread as that adds to the usefulness of the plugin, if no menus are added to the menu region then nothing will run, just adds a extra ability to add custom links through the WP interface.
Yes, I added the first bit ( ‘register_nav_menus’ ) before the pages function in my plugin file, but the second part ( ‘if(has_nav_menu’ ) throws up errors. So I’ll include that part of the code in the readme with instructions on where to paste it if running WP3.0.
@r-a-y Your infinite wisdom will again come in handy: should the plugin check whether BP is active and, if so, what would you say is the best way to proceed?
If I understood the instructions correctly here: http://codex.buddypress.org/how-to-guides/checking-buddypress-is-active/
This, in loader.php, should check if BP is active: http://pastebin.com/dFt1h3pf
EDIT: I’ve added the loader.php file to the plugin and, eureka!, it still works.
And we’re off to a running start…
I just submitted the plugin to the WP repository. Now we’ll have to wait……………
But if anyone wants to give it a whirl in the meantime, you can grab it from my site here:
Updated version now available… yippee! Continue reading this thread to learn about the changes
Be sure to read the readme!
The error with the function has_nav_menus() can be easily rectified with a check for 3.0 I’ll look at your code and make some adjustments later.
You possibly ought to have delayed submitting the plugin to the repository until a few checks had been run on the plugin, looking closer at the function I think some adjustments need to be made to the markup as it’s looking like malformed nested elements are rendering.
I’ll try and add corrections later and return to you.
Thanks. I sometimes do tend to shoot first and ask questions later
I’ve had to do a fairly extensive rewrite on the function for a number of reasons:
1/ There was a significant degree of malfomed ul child nesting which prevents drop down aspects working correctly primarily I’ve removed the opening and closing UL elements as they are not required and cause issues.
2/ Not sure how the wp_list_pages was intended to work but with the parameter ‘title_li’ declared as empty you correctly remove the wrapping elements but would need to add UL elements manually wrapping the function call for the dropdown to function correctly.
3/ Added back in the wp_nav_menu function calls but wrapped them in a check to see if WP 3.0 is running i.e are the new menu available if not hide altogether.
Also added a reverse check to remove the wp_list_pages function if using the new menus as there is little point in both and the new menu system serves better.
4/ Changed region and menu top link names to ‘pages’ but this area is a fundamental issue as it cant be known what the user sets as menu names, ideally one shouldn’t hard code values but retrieve them from the admin menu area, but this proves far too hard to work out (asked a question on WP support but haven’t had a reply and I don’t expect one – sadly there is little codex documentation of any depth on the new menus.)
This issue applies to the wp_list_pages as well as you can’t really pass any values for ‘include’ and ‘exclude’ as these values can’t be known so you ought to remove those values you have hardcoded (I have left them in).
If I can get some guidance on how to fetch values from the menu backend view such as menu names then it will be possible to make the menus far more effective but have spent quite a while trawling through the core WP files for nav-menu and it’s not obvious and too time consuming.
I have copied the revised code to this pastebin page, give it a check over, but don’t assume I have things all correct, run it as plugin copy 2
Wow, you really took this little project to heart, didn’t you? Thanks for investing so much time on it!
1. Didn’t realize the ul elements could cause problems but it works just fine without them (tested successfully on bp-default and child theme).
2. By wrapping wp_list_pages in ul elements, all pages aggregate under a top-level “Pages” nav item, with actual WP pages as subnav items and child pages as sub-subnavs as example below:
- Page 1 – - Page 1 child 1 – - Page 1 grandchild 1
- – - – - – - – - – - – - – - – - – - – - Page 1 grandchild 2
- – - – - – - – Page 1 child 2
- Page 2
By removing the “Pages” li element and wrapping the call to wp_list_pages in li elements, WP pages appear as top level, with child pages as subnavs. Creating a new page adds it to the nav as a top-level item, unless excluded (either entering the page ID manually in the code, or with “Exclude Pages” plugin). I prefer it this way, but the modified code could be included as an option in the plugin for those who prefer having all pages listed under a common heading, with instructions on where to change the heading label.
3. I get no errors with the new WP3.0 checks in place. I couldn’t figure out how to do that, but I see it was a rather simple if !function_exists call. Huh…
4. I left the top link name “Pages” in the wp_nav_menu calls for now. I have not tested this code on WP3.0 so don’t know if the menus will behave as in 2.9.2
I ran the code with modifications, both yours and mine, and it works brilliantly. Collaboration is a wonderful thing
Here’s my revision: http://pastebin.com/4U85PWrt
No word yet from WP about my plugin submission… still waiting. Got to get to work now, thanks again!
Ok get what you wanted for the wp_list-pages running horizontally, trouble with that is with a fixed width layout one might run out of space, testing on my fluid layout and the adminbar looked far too crowded.
It would be possible to offer some form of configuration file that would would allow for certain defaults to be set by the user to flip flop between dropdown and horizontal. be nice to be able to kep that seperatly from the plugin so it didn’t get overwritten with upgrades though.
I have checked in WP 3.0 and loose checks on 2.9.2 but those conditionals should hold good.
I would take my suggestion and remove those exclude parameters as they may cause issues if someone had page ids that matched (unlikely)
Problem in doing this as a plugin is that you have to allow the user to be in control of values and parameters and is what causes the issue with top level links for the wp_nav_menus. When I ran up my function for adding various links to adminbar it was and is run from bp-custom and under my control so I could add/change these values at will as required.
quick adjustment to give choice on wp_list_pages, but this ought to be carried through to the wp_nav_menus which I’ll leave as an exercise for the class
Oops, I had removed the page IDs from the plugin file, but the file I uploaded to pastebin was the one that has my page ID exclusions.
Nice touch with the pageLinkDropdown idea! I take your hint and I’ll see if, following your example, I can figure out how to add that option to wp_nav_menus.
I fully agree that the user should be able to control values and parameters. Next challenge then is to learn how to create (and code) an admin area to give users that control. Here’s the start of my study program: http://codex.wordpress.org/Creating_Options_Pages and http://codex.wordpress.org/Adding_Administration_Menus
Oh goody… more fun!
For those who want to play with the plugin – including its far out new features! (and a freesh new readme) – you can download from here:
EDIT: Ooh… just uploaded to subversion… should appear soon in the repo… fingers crossed…
What starts out as appearing to be a simple requirement, nearly always evolves to something else admin area would be next step, however in some senses it’s starting to over complicate things.
An alternative is to create a conf file with a series of options similar to the one written to flip flop the pages from hori to vert and include that file into the main one, so that user settings in that aren’t lost give instruction to user to move that one file up a level into the plugin directory root, then do a check on both original path to file or the path if moved up a level.
Edit// oops there’s a typo on second $pageLinkDropdown ($lpageLinkDropdown) – my bad,.
Config section created at top of file – labels all set from that point by user
Hide main nav links function created to add embedded styles via add_action dependent on user setting $hideMainNav = true
Hiding the main nave through CSS isn’t really the best option as it leaves the markup there, it would be better to remove altogether you may want to change default to true(hide)
This is somewhat of a stopgap solution to user parameters.
As always check over thoroughly for any other typos I may have missed
You must be logged in to reply to this topic.