BuddyPress.org

Hi,

The CSS file that gets loaded depends on which template pack is in use, e.g. Legacy vs Nouveau. Additionally, styles (CSS) can be customized via a Child theme and, if a Classic theme is in use, via the Appearance > Customize > Additional CSS menu path within the wp-admin area. Thus, which CSS file gets loaded is irrelevant/moot.

Specific to Avatars, How to Customize BuddyPress Avatars With CSS has some info (Note: might be a tad outdated). There are other sources on wordpress.org that contain general info regarding custom CSS, e.g. from the Advanced Administration Handbook – Custom CSS in WordPress

Hopefully, this is enough information to get you started.

Hi @glenphillips33,

Anything is possible, what’s unknown is the probability. IIRC, I had a similar experience, but it involved the wordpress.org site and drop-down menu items that affected Chromium on a AlmaLinux distro. Google Chrome worked fine as well as Firefox. On a Ubuntu and Debian distros (Linux), Chromium work just fine, as was with Windows 10. Long story shorter, eventually, the AlmaLinux distro received an update with a new Chromium build that fixed the issue with Drop-down menus.

That said, it doesn’t seem likely for a Windows platform since Google Chrome should be automatically updated and is usually ahead (stable release) of Edge, Opera and other browsers that share the Chromium engine or, maybe you are using cutting edge/beta releases/builds but, as previously mentioned, anything is possible.

If you want to supply the Web URL, I suggest you add that to your BuddyPress Profile, there is a field specific for this purpose (Web URL). That way, you can remove it later, if you don’t want the URL to remain public. I can then either confirm or deny whether I see something unusual while visiting a profile area with Google Chrome.

Next up are a couple of housekeeping items, that you require your attention, of which should not be related to the issue you reported in this thread.

(1) BuddyPress 12.4.1 is not compatible with WordPress 6.7.x. The effect is that your server error log(s) are filling up with an error notice, e.g.:

Notice: Function _load_textdomain_just_in_time was called <strong>incorrectly</strong>.
Translation loading for the <code>buddypress</code> domain was triggered too early. This is
usually an indicator for some code in the plugin or theme running too early. Translations
should be loaded at the <code>init</code> action or later. Please see <a
href="https://developer.wordpress.org/advanced-administration/debug/debug
-wordpress/">Debugging in WordPress</a> for more information. (This message was added in
version 6.7.0.) in /var/www/html/wp_test/wp-includes/functions.php on line 6114

The solution is to either to roll back WordPress to version 6.6.2 or upgrade BuddyPress to version 14.3.3.

(2) BuddyPress 12.4.1 is missing 2 security patches, if you are going to continue to use the BuddyPress 12.x branch, it is recommended that you upgrade to BuddyPress 12.5.2, see If you are using BP 12.x and can’t upgrade to 14.2.1, and apply (1), accordingly.

Hi @stephunique,

Long story short, the “screenshot” file is added to the wp cache, e.g., $this->cache_add( 'screenshot', 'screenshot.' . $ext );.

Additionally, it appears that the extensions for the “screenshot” file can be any of the following 'png', 'gif', 'jpg', 'jpeg', 'webp', 'avif'.

Last but not least, in the future, it would, most likely, be best to ask WordPress related questions in one the WordPress related forums.

Hi,

BuddyDev has a commercial plugin, BuddyPress Profile Data Moderator, that may serve your purpose. If you are looking for something free then you should search the WordPress Plugins Directory, if you’ve not done so.

Hi @glenphillips33,

My apologies for a belated response but, my default browser is Chromium (just a preference thing) on a Linux platform and all looks as expected. Although, Chromium, Google Chrome, Microsoft Edge, and others share the same basic engine, there may be differences in builds across the various OS platforms. Without knowing more information, it is difficult to assess the issue. For example, we currently don’t know, at a minimum, which may or may not prove to make a difference:

• WordPress version
• BuddyPress version
• PHP version
• BuddyPress template pack in use
• If you have tried using a WordPress default classic theme (non block theme or non FSE)

The layout appears broken, with profile sections overlapping or not displaying at all.

This is a generalization, meaning there isn’t enough specificity to truly understand the situation. Perhaps, a screenshot would suffice without having to visit your site.

Here is my setup as it relates to the following screenshot of an arbitrary Profile page with Google Chrome:

• WordPress: 6.7.1
• Active Theme: twentyeleven child theme (twentyeleven-child)
• PHP: 8.2.25
• OS: AlmaLinux 9.5 (Teal Serval)
• Browser: Google Chrome – 131.0.6778.85 (Official Build) (64-bit)
• Page caching: No
• Object caching: No
• BuddyPress: 14.3.3
• BuddyPress URL Parser: BP Rewrites API
• BuddyPress Active template pack: BP Nouveau

For me, the profile area renders as expected with Goggle Chrome based on the given setup. I also looked at the same page with Windows 10 and Google Chrome (131.0.6778.86 (Official Build) (64-bit), logged-in and logged-out and it looks the same. I don’t have a Mac, so I can’t provide a verification. Also, I’m serving up the profile page from a development site on my LAN.

Hi,

Thanks for reporting this issue, I can confirm the error messages for the BP REST API when using the BP Nouveau template pack. Unfortunately, something went wrong with the build and these errors didn’t get caught when testing the build. 14.3.1 was released to fix an issue with WordPress 6.7 (_load_textdomain_just_in_time issue) and another issue (heartbeat) with the BP Legacy template pack.

Looks like we need another build to get this fixed. At the moment, the only recourse is to roll back to 14.2.1 and continue to use WordPress 6.6.2.

My apologies for the inconvenience.

My apologies for the inconvenience, the BP Team is aware of this issue (see Trac ticket #9247) and the tentative plan is to deploy a minor release (14.3.0) for a fix. Unfortunately, at this moment, I don’t have an ETA.

Hi,

My apologies for the inconvenience, the BP Team is aware of this issue (see Trac ticket #9247) and the tentative plan is to deploy a minor release (14.3.0) for a fix. Unfortunately, at this moment, I don’t have an ETA.

Hi @miednr,

I’m not sure why you are having difficulties with a BuddyPress installation on a multisite whereby blog posts are not showing up in the Activity stream when configured to do such.

At the moment, I’m not able to duplicate your situation because blog posts are showing up in my Activity stream in a multisite installation. As can be seen in the following screenshot:

Since blog posts work for me and not for you, we need to figure out the difference(s) in our installations and what I have as the basics are (running on a LAN):

• WordPress 6.7 – multisite with subdirectories
• BuddyPress 14.2.1 – network activated on secondary site
• All BuddyPress components activated
• Default BuddyPress options plus “Post Comments” enabled
• TwentyEleven theme used on secondary site
• Pretty permalinks used on secondary site

Additionally, the installation guide I used is “Case 2” from the following document:

BuddyPress Activation Guide for WordPress Multisite

Maybe if we start on some common ground, we should eventually figure out what may be going astray with your installation, well at least that would be the theory.

Are you using LocoTranslate?

In this case this might be the issue. There was a lot of issues after the update to WordPress 6.7 regarding how the text got translated. It seems to have been fixed with their latest update though.

I just wanted to thank @dreampixel for the support they are giving here on the site. It’s very refreshing. Usually no help whatsoever is offered by any of the people behind Buddypress. None.

Hello @thinlizzie 🙂

I’m by no means an expert or anything lol, but I’ve been playing around with WordPress and numerous different large setups for the past 15+ years. I normally reply to people if I got the time or ideas on what could be done.

That is not my experience that there is no support in here. Please remember that BuddyPress is open source and the users in here (mods included) are not obligated to help/offer support all the time. Most people in here have other projects going on and/or might not be able to help. Also, a lot of the time the same issues are highlighted again and again instead of people searching the forums for answers first.

That being said, I also appreciate when people try to help me troubleshooting, since it can be quite frustrating when things doesn’t work, and you have people depending on it.