CUNY Academic Commons

I agree with your blue-number addition comment, Boone.
For consistency, I suggest that numbers in blue circles always indicate new-things, like they do for messages, and therefore would be changed for friends and groups in both the dropdown and nav to indicate number of friend requests and group invitations. This would mean that Sites would have no number next to it at all in either location.

Yes I'll work on this right now - we want to make the dropdown copy the profile page, right, not the other way around?

And I like the changes you're proposing, Sam, on the numbers. Boone does that sound good to you?

Checking on this some more, it looks like the items in that admin bar nav are added dynamically from each of the BP components individually as they get set up. I don't think they'll be an easy way to re-order them, unless we just want to use some Javascript to do it after everything's been loaded, but I think that could get messy.

The other option would be to just modify the Commons Profile page to match the setup in the admin bar nav.

Let me know what you think we should do, Boone, and also if you want me to go ahead and modify the way the numbers work on the profile page.

Dan, thanks for the initial research.

Regarding blue numbers: Let's start by mirroring, in the dropdown, only those numbers that reflect 'new' counts. We'll also want to remove the non-"new" counts from the user nav, but that should perhaps get its own ticket, because it'll be a different kind of task.

Regarding menu item order. It's very annoying that the order of dropdown items is different from the order of nav items. IMO, this is a BP problem, bordering on a bug. I vaguely remember the discussion, around the time that the WP toolbar was introduced (WP 3.6?), where we decided that building the toolbar dropdown should be an entirely separate process from building user nav. In retrospect, I think that was a mistake. Ray (whom I've copied here), given the backward compatibility issues that will be involved, do you think it's possible/wise to work on a patch for BuddyPress that will change the way this works? What if the 'BP_Component::adminbar_myaccount_order' property could somehow be inherited from the 'position' of the corresponding nav item?

In the short term, on the Commons, I think we should give priority to the user nav, as it exists under Commons Profile. I'd prefer not to solve this with JavaScript if possible. Dan, looking at the way that BP_Component::setup_actions() uses adminbar_myaccount_order as the priority when hooking to 'bp_setup_admin_bar', I'm sure there's a way to hook into the component bootstrap process to change this value, though given when the actions fire, it'll probably involve unhooking (remove_action()) the default hooks and rehooking at our new priorities. Ray, this is question number 2 for you: do you think it makes sense to add another filter/action in BP_Component that would make this process less painful? :)

If it turns out to be truly awful to do this, I guess reordering using JavaScript would be fine.

I spent some more time with this today and didn't have any luck. I did manage to re-order the menu items in $bp->bp_nav, but for some reason that re-ordering doesn't get reflected in the admin bar that actually shows up. Maybe I was just barking up the wrong tree on that one altogether.

Looking at it again though, it looks like it's almost in the same order as the Commons Profile navigation. The only exceptions are (1) - "My Notifications", which doesn't actually have a counterpart the Commons Profile, and "Send Invites", which in Commons Profile is right beneath "Groups", but in the Commons admin bar is actually in it's own group of items with "Log Out" at the bottom of the menu.

Which were the blue numbers that didn't mirror "new" counts that show up in the admin bar? I'm not sure if there are any - I'm only getting a circle for "Notifications", and not for Sites or Friends, at least in the admin bar.

Thanks for looking into this further, Dan.

I spent some more time with this today and didn't have any luck. I did manage to re-order the menu items in $bp->bp_nav, but for some reason that re-ordering doesn't get reflected in the admin bar that actually shows up. Maybe I was just barking up the wrong tree on that one altogether.

$bp->bp_nav may be the wrong place to look. Try $bp->bp_options_nav. (Don't ask.)

Looking at it again though, it looks like it's almost in the same order as the Commons Profile navigation. The only exceptions are (1) - "My Notifications", which doesn't actually have a counterpart the Commons Profile, and "Send Invites", which in Commons Profile is right beneath "Groups", but in the Commons admin bar is actually in it's own group of items with "Log Out" at the bottom of the menu.

I vaguely remember disabling the Notifications nav item shortly after it was shipped in BuddyPress (1.9, I think), because bp-default didn't support the Notifications component, and I didn't feel like adding support. Relevant changesets appear to be 54e2b12390ba42d5634b8c72a178e2731127faaa and 479eda3028f0445eba7d7965a2bdeefea9c9a362. Now that Notifications is working, how about if we go ahead and add it in as a Commons Profile nav item? That'll fix that part of the problem. As for Send Invites, I think we should ignore the discrepancy - retooling the Commons Profile nav into multiple sections is not viable at the moment.

Which were the blue numbers that didn't mirror "new" counts that show up in the admin bar? I'm not sure if there are any - I'm only getting a circle for "Notifications", and not for Sites or Friends, at least in the admin bar.

This is in reference to the nav items on the Commons Profile nav. Sites has a blue rectangle next to it with your site count, etc. Those that reflect "new" content (like unread messages) should be kept, and the others scrapped. And then these counts should be mirrored in the toolbar dropdown. But if this seems like it's going to be a difficult task for 1.9, we can open a separate ticket against a future milestone.

Thanks for the help here! Here's a commit that I think gets at most of this ticket: https://github.com/cuny-academic-commons/cac/commit/adce320b13ce8687cf4f78e3826fa52c84772b2f

So I un-hid the notifications tab on the nav, and added some to the theme's functions.php to change how counts are displayed in the nav. I made it so that if there are new group invites or friend requests, those are displayed as counts, but if there isn't anything new to display (including with "Sites"), the count is hidden altogether. The way I ended up doing it is a little hacky, but it works and I'm not sure if there's a better way to do it because of how the counts are coded into the "name" attribute of the nav item by Buddypress when the nav item is set up, and the only action hooks are at the end.

I haven't had a chance to mirror those counts to the admin bar yet though, so maybe we can add that as a separate ticket.

Changes look good to me - thanks, Dan. You're correct that this is kinda the only way to do it, given the way that BP sets up navigation.

Can I ask you to prefix the function names with `cac_`, please? I don't want to get unexpected fatal errors if we happen to install a plugin using the function names.

Please do create another ticket for the admin bar stuff - it's late to make these changes for 1.9.

Thanks, Dan! Looks like this fixes most of the issues.

One last point - Can we set markup=false when appending the duplicate message in emails? (bpmfp_duplicate_post_message_notification()) I don't know how well email clients will deal with the div.

Fixed comment #10 here: https://github.com/cuny-academic-commons/cac/commit/4492ce84e56e574486d65ad393d77d219c77637f

#11 is on another ticket, which I'll respond to there. Thanks again Boone!