[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @jmchez

We’ll package a 12.1.0 minor release Monday which will improve the Reset Slugs tool you can find into WP Admin > Tools > BuddyPress. This should avoid some orphaned directory page that might cause the number suffix.

If you have regular pages using the same slugs than your BP Directories, I also advise you to edit their slugs to something different.

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @dreamscape2

If you recently updated BuddyPress to 12.0, as this plugin hasn’t been updated for years, I’d advise you to install and activate the BP Classic backwards compatibility Add-on we specifically built for these situations.

BP Classic

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @maciejatmyshca

There was a ticket where I did some tests, imaged were showing when not logged in for me:
https://buddypress.trac.wordpress.org/ticket/9066

if it’s lazy loading I believe it’s mainly a WordPress thing as we do it in activity and for avatars only if I remember well.

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hello @ceraus

BuddyPress is overriding WordPress registration URL by default so that it is displayed into your theme instead of the wp-login.php file. From previous support topics on the same subject I’ve read some users were deleting the registration page BuddyPress was created to force the use of the WordPress registration page. This was a workaround that is not doing the trick anymore in BuddyPress 12.0.0.

Please see: https://buddypress.org/support/topic/buddypress-12-0-0/page/8/#post-332709 for a way to disable the BP Registration flow.

[@anonymized-6594935 Inactive 2 years, 9 months ago]

For readers information: a ticket to track the above was opened here https://buddypress.trac.wordpress.org/ticket/9066

Using BuddyPress 12.0 on a regular config of WordPress is not blocking images, there’s probably a plugin/theme/custom code conflicting with BuddyPress on your specific config.

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @roberthemsing

Making the BuddyPress registration flows « deactivable » is something we’ll think of during next major version. In the meantime using this gist I was able to disable it.

[@anonymized-6594935 Inactive 2 years, 9 months ago]

@roberthemsing

Ouch, pretty annoying! Thanks for reporting it. I’ll check it asap. In the meantime, what happens if you go to Settings > BuddyPress > URLs and change the slug for the Register panel to sign-in for example?

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @beoogo

Sorry to read about your issue. If you get a blank page that’s probably due to a fatal error. Your host should give you access to the error log of your site to find the issue. My guess is one of your plugin is using a deprecated function. If you’re trying to activate version 12.0.0 of BuddyPress, you can try to first activate the BP Classic backwards compatibility add-on.
If it doesn’t solve the issue or if you’re using a previous version of BuddyPress, add this constant to your wp-config.php file:
define( 'BP_LOAD_DEPRECATED', true );

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @roberthemsing

What you describe is the typical behavior you get when you try to reach the registration page while you already logged in. Did you make sure to log out before trying to reach this page ?

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi,

Try to go to WP Admin > Permalinks and simply click on the save button to refresh your permalink settings

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @clipcash

I have no idea, I’ve just searched our entire codebase and we’re not using such an error message. That’s probably a message generated by another plugin.

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @lmstearn

To me it’s a bbPress issue. I believe there’s already one on bbPress Trac.

The workaround I posted here: https://gist.github.com/imath/24fdfa1b8625477e93c0daa0d90b2a44 is the way to go imho.

[@anonymized-6594935 Inactive 2 years, 9 months ago]

I agree BuddyX is a great looking theme, it’s available on the Theme directory and actively maintained by great developers (who are contributing back to BuddyPress). We wrote a post on it on this website. Our BP Block Theme will also be available on the Theme directory and we’ll probably look at a way to feature nice BP Themes from end-users Dashboard a bit like we’re featuring BP Add-ons from it (Plugins > Add New > BP Add-ons tab).

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @windhillruss

I’ve just tested BuddyPress v12.0.0 with or without BP Classic and I wasn’t able to reproduce your issue. To me everything works fine, if you can clone your site on a local/staging environment, I advise you to disable all plugins but BuddyPress and BP Classic and use a bundled WordPress theme to see if the issue is still there (it shouldn’t), then activate one by one your plugins to see which is not behaving the right way.

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hello, you are using a fork of BuddyPress. Our code have diverged. Please contact this fork support. We cannot reply for them.

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @windhillruss

Thanks a lot for your feedback I’ll check this asap 👌

Hi @epgb101

Thanks a lot for your feedback. I agree we need to improve the front-end design. As I’ve explained here, we are very ambitious trying to integrate with any themes. In next major version (14.0.0, because 13 is a hard number), we’ll carry on on this road but we will also try something new: build a new BP Block Only Theme where we can control every part of the design (which is far from being the case with other themes). So I am confident we’ll reduce the gap you’re talking about and I’m very positive about the fact being able to use the WP Site Editor to organize the layout will attract (back) more people to use BuddyPress.

Hi @maciejatmyshca

Really sorry to read about your issue. I have no idea about why this is happening. Someone else shared about a similar issue in a previous reply to this topic. I have tested (again) with WordPress latest version + Twenty twenty four and only BuddyPress activated and I had no issues with images or styles.

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @wojciechr

Since BuddyPress 12.0.0, we’ve delayed the moment when the displayed user is set to comply with the WP Rewrite API. You now need to wait for bp_parse_query to get it. I advise you to use a later priority than default one (eg: 20).

The other option is to download and activate the BP Classic plugin. It will bring backward compatibility with your code.

My advice is to prefer 1st option 😅

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hello @perchenet

Thanks a lot for the screenshot you shared with us. I guess you are using the Classic Widget plugin (or a filter to carry on using WP Legacy widgets UI). If you were using the Block Widgets interface that replaced it during WordPress 5.8, you’d be able to also set the title from the BP Block Widget Inspector.

I believe you have 2 choices:
– Activate BP Classic to get the BP Legacy widgets back and be able to use them with the WP Legacy Widgets UI.
– Or since the text widgets seems to render serialized blocks, you can use the Post Block Editor to visually set the Online/Active members block title, then from the « more » button of the Block tool bar, use the « Edit HTML » menu item to get the serialized block which should contain the title attribute you set. If this « Edit HTML » menu item is not available for the block (I may have disabled it), use the Block Editor command to switch to the code view. Copy the serialized block and paste it into your widget block and it should display your custom title above the avatars into the front-end part of your site.

I can’t test myself until 6/7 hours as it’s office hours for me 😅

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @perchenet

Just to be sure we are talking about the same things:
– The Active/Online members legacy widgets were removed from BuddyPress 12.0.0 and moved into the BP Classic add-on as they were deprecated since 10.0.0 (following their migration as block widgets in version 9.0.
– The Active/Online members block widgets are available in 12.0.0 and are (almost completely) translated into french. In 12.0.0 we’ve changed the way we build blocks to use the WordPress way (block.json + wordpress/scripts builder) instead of our “9.0 to 11.0” way (Parcel.js).

The below screenshot is showing the Active/Online members block widgets translated into french.

Looking at your screenshot, it looks like you are using a custom translation file and renamed these widgets to “Aupostien·ne·s récemment en service / en ligne”.

I also see that the default block widget title is not translated, I guess WordPress is not supporting translating the attributes described into the block.json file (that’s why I was writing (almost completely) a bit above). I agree that’s annoying and I’ll probably work on a way to have the default title translated. But, you can customize this title using the Block Inspector from the right sidebar once you activated its display (follow the first arrow in the below screenshot).

So to have the title into french you just need to enter your text into the “Titre” field like I did on the above screenshot. So you can use “Aupostien·ne·s récemment en service” as the block widget’s title for example.

Thanks again for your congrats 😍

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @tdakanalis

Thanks for your feedback. Short answer is: you can’t anymore. In BP 12.0.0, we’ve delayed the moment when BuddyPress objects are fully set to the time when WordPress parses a query in order to comply with the WP Rewrite API.

We’ve faced the issue you’re talking about because group extensions are loaded way too early. We haven’t changed this to avoid too much back compatibility issues and opted to build the BP Classic plugin for users that may use plugin like yours.

If you can’t get the group ID in the constructor method of your group extension, it doesn’t mean you can get it when you actually need it: that is to say when your group’s extension screen/nav is generated by BuddyPress.

Actions you need to take:
1. Make sure you are using the latest BP Group Extension API (the one we introduced in version 1.8 which returns arguments to the parent class (eg return parent::init( $args );). I advise you to read this updated documentation about it: https://github.com/imath/buddypress/tree/master/docs/developer/group-extension
2. Use the newly introduced (12.0.0) show_tab_callback, see https://github.com/imath/buddypress/tree/master/docs/developer/group-extension#show_tab_callback
3. Look at the code explaining how to use this new argument here or there
4. Update your code 🙏.

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @priyam1234

I’m not sure to understand what you’re trying to do, but if you need to force the BP Directories metabox to be shown in the Nav Menus Admin Screen, you can try that:

function priyam1234_hidden_meta_boxes( $hidden, $screen ) {
	if ( isset( $screen->id ) && 'nav-menus' === $screen->id ) {
		$hidden = array_diff( $hidden, array( 'add-post-type-buddypress' ) );
	}

	return $hidden;
}
add_filter( 'hidden_meta_boxes', 'priyam1234_hidden_meta_boxes', 10, 2 );

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hello @bermudastream

The fact this snippet is not working on your config is amazing to me, as I’ve tested it on my development env.

If you haven’t done so, could you add the code into a bp-custom.php file? See https://codex.buddypress.org/themes/bp-custom-php/ for more info about this file.

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @meghraaj,

We are using the REST API endpoint internally to manage group members and it works as expected. I’ve just tested the CREATE endpoint successfully in a similar way than the one we’re explaining here: https://developer.buddypress.org/bp-rest-api/reference/user-groups/group-membership/#add-a-specific-member-into-a-group

I wasn’t able to reproduce the issue, sorry. Have you made sure to deactivate all plugins but BuddyPress to test your code?

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @legiosmoke

I’ve just test Astra with BuddyPress 12.0, it works as expected, images are not disappearing, here’s a proof of it:

[@anonymized-6594935 Inactive 2 years, 9 months ago]

Hi @legiosmoke

Thanks for your feedback. I’ll test the Astra Theme version that is available on the Theme directory to see if all images are disappearing once BuddyPress is activated.