BuddyPress.org

Ya, I found that’s true, as well. But nothing in the registration process gives indication of that. Validation shouldn’t allow it. Maybe this is an issue upstream / with WP? Chrome’s built-in email field validation even let’s the .. slip by. This might be a futile endeavor…

So, instead of modifying the bp_has_broups query in the template, I figured I needed to do an if / else to check if the user has not set the sort option yet. To do that, in bp-custom.php I hooked in to the bp_ajax_querystring filter:

add_filter( 'bp_ajax_querystring', 'mediclique_bp_ajax_querystring', 32, 2 );
function…[Read more]

FYI – this approach still shows the ‘Home’ nav item to logged out users, but it can effectively be hidden via CSS.

Solution:

There is an action to hook to inside bp_core_activate_signup() that fires right after activating the account ( user clicked the link in the email ), so when the user hits /activate this will fire and reset the user_status to 3 ( 1 is spammer I guess ). Now to figure out the rest…

Here is the code ( the second function disallows the…[Read more]

Scratch that.
I need the forum id based on group id.

Aaaaand the solution: bbp_get_group_forum_ids()

Found the solution!
So, in /buddypress/bp-groups/bp-groups-loader.php if found that it’s checking for a “front” template along with Activity Streams being disabled.
So, I just created an empty front.php file in my overloads /buddypress/groups/single/ folder and, boom!

Couple things to consider / need direction on:
– the URL is still /home. Looking to have /members
– the “Manage” section for admins—what is the proper way to handle visibility in the nav?

To be clear, and provide further details to demonstrate that this hasn’t been answered previously, I’m looking to have 2 nav items in every group: Forum, Members.
In that order, with the default page being Forum.
I have achieved the default page being Forum with this:

add_filter( 'bp_groups_default_extension', 'custom_bp_groups_default_extension'…[Read more]

Ok, the one i found that has the ajax check does work.
I have narrowed all issues down to a redirect loop on ajax actions inside a custom loop on a page template.
Starting a new topic… thanks all.

Thought I had found the silver bullet here:

https://buddypress.org/support/topic/need-to-disable-the-user-access-to-wordpress-admin-panel/#post-183537

which includes a check for ! ( defined( 'DOING_AJAX' ) && DOING_AJAX )…still has a redirect loop when performing the ajax actions.

The search continues…

Sorry, correction:
This doesn’t cause a redirect loop…but it doesn’t prevent access of non-admins to admin section.
And it DOES now cause a redirect loop on the actions that were, before, loading the whole home page into the middle of the template.

Switching the action to wp causes a redirect loop.
But we’re thinking it’s just a matter of finding the right action to hook into?