BuddyPress.org

You need to call the global before you can use it.

global $current_blog;

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

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 BP1.2.5.2).

@r-a-y Should the global be called before function pages() is started, or within it?

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.

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.

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 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.

If I understood the instructions correctly here: https://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.

@pcwriter
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.

@pcwriter

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

http://pastebin.com/trUDaPEP

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.

@hnla

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: https://codex.wordpress.org/Creating_Options_Pages and https://codex.wordpress.org/Adding_Administration_Menus

Oh goody… more fun!

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,.