BuddyPress.org

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

You could always use this snippet and maybe adjust the height of the field/container if needed:
This is just an example in the BuddyX theme – can be done with other themes too.

.buddyx-mem-cover-img {
  visibility: hidden;
}

.buddyx-mem-cover-wrapper {
  height: 100px;
}

Hello again

Sorry for the late reply, I forgot to setup notifications on this post. 🙂

I now see what you’re trying to do and why you would use the Select2 options (looks cool!).

Now to my next question – what have you done to debug this? Have you tested if this is due to a compatibility issue within your current theme or with a third-party plugin maybe?

I’ve never used the Select2 myself, but I would like to test it out myself for sure. 😀

I also want to edit the registration page and customise the messages on it and the way it looks, so I tried this too. What I did was, I created a child theme in its own separate folder called buddyx-child. Since the steps say to

`Paste it into your theme folder in wp-content/themes/your-theme/buddypress/members/register.php.

I created a folder called “buddypress” in the child theme folder, then in that folder, created a folder called “members”, and copied and pasted the “register.php” file there and made my edits there. I typed some test messages using the paragraph HTML tag <p> and the message shows on the registration page, BUT the visual layout of the page changes. I don’t know why that is when it’s supposed to inherit the CSS from the parent theme. If I move the “register.php” file out of the buddypress/members/ directory and put it directly in my “your-theme” (ie my child theme) directory, then it doesn’t work at all and the child theme just inherits the original registration page.

Anyone with any ideas?

Hi,

It is difficult tell since the error message is missing backtrace info. Furthermore, I’m not getting that error with:

• WP 6.7
• BP 14.2.1
• PHP 8.3

Just for GP and long story short, I placed the function bp_get_the_profile_field_id(); in functions.php of a child theme in an attempt to replicate the error. Query Monitor revealed the error was caused by the aforementioned function, see the following screenshot:

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.

And you use the BuddyX theme with BuddyPress and not the BuddyBoss Platform right?

You can send me an email here: support@spiritualskill.com

This reply will be deleted once you reach out, in order to prevent spam mails in the future. 🙂

Hello again 🙂

This might start to make sense then!

First, when you translate something within the code itself (not using a translation plugin and po/mo file) it will for the most part be overridden whenever you update your WordPress / plugins that are translated. So, this might be why it doesn’t work now after the update.

I personally use a combination of LocoTranslate and TranslatePress. This is because BuddyPress activity is updated the way it is and for that reason LocoTranslate itself is not able to translate the dynamic content (like when activity updates – without the page doing so) – this TranslatePress supports.

So, for the BuddyPress content that can’t be translated correctly using LocoTranslate, I use the TranslatePress for those. Both plugins are free to use, and it doesn’t require you to purchase any expensive addons.

It’s important that you pick the right placement for your translation-files (custom, author, system). If they’re not in the right place the translation might not show up on the front-end. Also make sure you setup the settings within the LocoTranslate plugin not to override your translated files upon updating WordPress: Loco Translate > Settings > File system access > Modification of installed files & Editing of POT (template) files must be set to Disallow.

For the display name, this should be the default value it sorts by. Mine by default sorts by display name. When you go to Users > Profile Fields – you can edit the different settings from within there with the names and what is mandatory/not mandatory.

For the sorting part (or other features in the future) if it still causes issues, maybe a snippet code using a plugin like WPCode Lite might be a better solution rather than going into the code and edit it from there. In this way it will not get affected in most cases when you update WordPress, plugins and theme.

Maybe some of this can help you – if not – then feel free to keep me updated. 🙂

Sounds like compatibility issue within the theme then. Have you tried it with a BuddyPress supported theme?

You can add users from back-end, yes.. but the users still need to “activate” their account and login for them to show up on the front-end (in directory).

Does the member show up in the normal member directory? – and is the issue only with the “alphabetical search”? .. My alphabetical search works fine, so might be a theme compatibility issue.

Have you cleared both server and browser cache?