CUNY Academic Commons

Here you go! https://www.figma.com/design/ePPpJucc02oge8kFA9duFc/CUNY-Navigation?node-id=14251-656&t=3wbeWptHMLQQWRvP-1 I've also added boone and Ray's email to the file

Hi Sara,

Do you have an updated Figma link? Or if you do not have access to Figma, can you post screenshots of the "My Groups" and "My Sites" dropdown menus when expanded and other assets that haven't already been attached to this ticket such as the Help icon SVG?

Here it is https://www.figma.com/design/E4oYOOSpqn6aX6Qa9O8AO2/CUNY-Design---Fall-2025?node-id=14442-786

Hi Sara, when I attempt to open the link, I get a message saying that there is an issue with the file sharing options:

Unable to open file

It looks like there’s an issue with this Design file’s sharing settings. We’ve emailed the owner to let them know.

Can you check the Figma permissions?

can you check this link? https://www.figma.com/design/E4oYOOSpqn6aX6Qa9O8AO2/CUNY-Design---Fall-2025?node-id=14442-786&t=BH7V97p96pEtp6u6-1

Thanks Sara! The new Figma link works.

I've committed a first pass of the new admin bar refresh design in https://github.com/cuny-academic-commons/cac/commit/0a46a9b216. This is available for testing on cdev. You might need to refresh your browser cache to see the new design.

There's still some work to do for the mobile view, specifically the More overflow menu and the various menu icons that get displayed when the screen width is < 400px, but I'll get to that in later revisions. In the meantime, let me know if you encounter any visual bugs.

Hi Sara,

This is where I grabbed the smaller CAC logo: https://gcdi.commons.gc.cuny.edu/cac-logo/. The letters look a little jagged due to some compression though.

One other testing note - what do we think about keeping Create a Site and Create a Group at the top of the My Sites / My Groups drop-downs like we have it now?

~/wp-cli-scripts/blog_public-sync.php

Thanks so much, Ray!

Hi Ray - I've been doing some unrelated work on the 2.7.x branch and have experienced slow load times due to the changes here. Specifically, I'm testing with a user that has perhaps 100 sites and 100 groups, and every page load is taking 60+ seconds. The slowness appears to stem from the avatar calls. I think it's because bp_core_fetch_avatar() does a file_exists() check for a "local" avatar, but in our case, this requires a round trip to S3. In a way, this is a shortcoming in BP itself - it should do a better job caching whether a user has a local avatar, one that doesn't involve filesystem scans. But I think we need to do something to address it.

One effective but broad method might be a high-level cache for menu content. Build all of the 'My Sites' menu markup one time, and then throw it into a transient, or into the object cache with some appropriate cache busting. Initial load would still be slow, but most pageloads would hit the cache. Another strategy might be to build an avatar cache. At first, it could be just for this purpose - so instead of calling bp_get_blog_avatar() when building the menu, call cac_get_avatar( 'blog', $blog_id ), which would check some persistent cache before calling bp_get_blog_avatar(). Over time we could roll this out more broadly, or try to integrate more directly into bp_core_fetch_avatar(). What do you think?

I am good with a static arrow.

FYI In testing on cdev, the link is blue when I went to a site and the mobile view is a bit wonky (see screenshots)

I've removed the hover arrow and the link for the "A CUNY Academic Commons Site" link should now be white. This is available for testing on cdev.

Scott is also seeing some weird link color behavior when clicking on a My Sites dropdown item and looking at the toolbar in the WP dashboard of that site.

I could not replicate this when visiting the abigclone site in Firefox's Private Window mode. It could be a caching issue. I've bumped the CAC version number on cdev, so that should hopefully bust the cache. Can you ask Scott to try again?

In a way, this is a shortcoming in BP itself - it should do a better job caching whether a user has a local avatar, one that doesn't involve filesystem scans. But I think we need to do something to address it.

I'll look into this. Automattic has some code that caches avatar URLs to user and group meta: https://github.com/Automattic/BuddyPress-VIP-Go/. We'd need to tweak this code to work with our S3 set up, but it looks promising.

Is there a user on cdev that is an admin of a ton of sites and groups? If not, I might have to bulk-generate some so I can do some testing there.

Hi Ray, when you are able to get back to this, just let me know when mobile is ready to test. I still have to see if Scott is still seeing the behavior he had flagged before and will let you know if so.

I also wanted to resurface my suggestion to keep Create a Site and Create a Group at the top of the My Sites / My Groups drop-downs like we have it now. I think it's worth keeping creation a prominent item. I don't think these are elsewhere on the admin bar in one click now.

Ray, is there a site already on CDev that has a bunch of plugins installed where I can see the overflow menu?

Another strategy might be to build an avatar cache. At first, it could be just for this purpose - so instead of calling bp_get_blog_avatar() when building the menu, call cac_get_avatar( 'blog', $blog_id ), which would check some persistent cache before calling bp_get_blog_avatar(). Over time we could roll this out more broadly, or try to integrate more directly into bp_core_fetch_avatar(). What do you think?

Boone, I've added a first pass at avatar caching in https://github.com/cuny-academic-commons/cac/commit/773c3acf1f8f0b75a9fff51969dbbe8b4e0c3ed4.

I've opted to build caching directly into bp_core_fetch_avatar() by caching the full avatar URL into either user or group meta. Site icons do not need to be cached since this is already quite optimized in BP blog meta: https://github.com/buddypress/buddypress/blob/89348dfe6062c246206082bb40c82bbbd36762eb/src/bp-blogs/bp-blogs-template.php#L416.

In order to disable filesystem lookups, the 'bp_core_avatar_folder_dir' filter must return an empty string so the file_exists() call will fail at the following juncture: https://github.com/buddypress/buddypress/blob/89348dfe6062c246206082bb40c82bbbd36762eb/src/bp-core/bp-core-avatars.php#L526. Then we can load up our cached avatar URLs further down the bp_core_fetch_avatar() function with the available filters. There is one caveat here and that is the way I'm using the check_cache() function to wipe out the avatar folder directory might cause conflicts with other code utilizing the avatar folder directory. For instance, when an avatar is deleted, the avatar directory is needed to find the correct directory. I had to ensure that our filter is removed so the previous avatars can be removed correctly (see https://github.com/cuny-academic-commons/cac/blob/773c3acf1f8f0b75a9fff51969dbbe8b4e0c3ed4/wp-content/plugins/cac-bp-custom-includes/bp-avatar-cache.php#L19-L32). I'm hoping this is the only instance of this likely to occur, but I thought I'd mention this here.

Another thing is I had to re-implement Gravatar lookups due to the way I am bypassing Gravatar checks to load our cached avatar URLs (see https://github.com/cuny-academic-commons/cac/blob/773c3acf1f8f0b75a9fff51969dbbe8b4e0c3ed4/wp-content/plugins/cac-bp-custom-includes/bp-avatar-cache.php#L10-L11). Gravatars are only loaded for users if the user does not have an existing uploaded avatar and if we're loading this on production or cdev (see https://github.com/cuny-academic-commons/cac/blob/773c3acf1f8f0b75a9fff51969dbbe8b4e0c3ed4/wp-content/plugins/cac-bp-custom-includes/bp-avatar-cache.php#L108-L128). The rationale here is local development doesn't need to ping Gravatar, but let me know if we want to change this.

Lastly, I am also disabling BuddyPress's avatar history feature. This feature was introduced in BuddyPress 10, but I do not think we need this functionality on the Commons. Avatar history means that older avatars will stay on S3 without being deleted, unless the user decides to delete their profile photo. Also the avatar history feature does a fair bit of filesystem lookups when adding a new avatar or when the related 'new_avatar' activity entry is rendered.

For the actual benchmarks, I haven't done too much in-depth testing here, but on cdev with a regular user account that has 50 groups, I've found that page load times go down on average from 4.5 seconds to 2.5 seconds. I used the Query Monitor plugin to get a sense of the page load times, but Boone, let me know if the avatar cache implementation helps with load times with your test account with 100 groups and 100 sites.

Ray, thanks so much for having a look at the avatar caching.

I've done some initial testing. Using the same URL and the same user data, pageload times look like this:
2.6.x: 4.09s
2.7.x before your caching: 67.99s
2.7.x after your caching: 22.79s

So it's obviously much better, but still extremely slow. I did some xdebug profiling and determined that calls to bp_get_blog_avatar() are the culprit. You mentioned that you didn't cache this because the internals are already efficient. But on my environment, bp_core_fetch_avatar() is still running and, critically, is still running file_exists( $avatar_folder_dir ) and/or opendir( $avatar_folder_dir ) in the case of blog avatars. This requires an AWS ping, which is very slow. When I comment out blog avatars altogether, the page loads blazingly fast - just around 1s - so I'm pretty confident that your caching approach is solid, and something like it should be extended to blogs (or, at the very least, the avatar_folder_dir should be nulled out to avoid the check, like you do with the other avatar types in check_cache()).

Thanks for testing, Boone. Your analysis about bp_get_blog_avatar() is correct. bp_get_blog_avatar() is efficient only when site icons are used, but if a site does not have a site icon, it will default back to bp_core_fetch_avatar(), which would use the filesystem lookups for blog avatars. I've added some code to bypass the filesystem for blog avatars in https://github.com/cuny-academic-commons/cac/commit/3e94f04323e4fec1bd868a6f8753d18dcd4851bc.

I've done some brief testing with a user with 50 groups and 50 sites on cdev and the page load times goes down from around 6 seconds to 2 seconds with avatar caching in place. Let me know if you see similar results, Boone.

Excellent! Very snappy for me now. Thank you!

I've removed the "A CUNY Academic Commons Site" line from the main site.

About:

On an actual site, it should appear both when logged in and logged out, so that you have the branding as well as the quick link back to the main site. Right now it only appears when logged out.

I've made the change so the "A CUNY Academic Commons Site" line appears when logged-in, but I feel that the logged-in view now looks a little congested and a little awkward with the line there. We do have the "Commons Home" link under the main avatar menu as well, but that is a little hidden away. Is there anything else we can do here?

If you go to Users > Profile on a site and set the "Administration Color Scheme" to "Light" you get admin bar appearance like in the attached video, with the highlights/hovers not working well.

Good catch! Should be fixed now. All changes should be available for testing on cdev. Sub-site logged-out views will require a server cache purge, so if you are testing a specific site and you are not seeing the change, let me know and I will clear the cache for the specific site.

Hi Ray, thanks for these changes. I see what you mean about the "A CUNY Academic Commons Site" line with clutter when logged in. Is there a direct way to exclude this line only for sites you're a member (or higher) of? Because if you don't belong to the site, that admin bar is still blank and the tag might as well be there, right? I can flag this for Sara too.