Skip to:
Content
Pages
Categories
Search
Top
Bottom

Forum Replies Created

Viewing 25 replies - 1 through 25 (of 1,738 total)

  • JJJ
    Keymaster

    @johnjamesjacoby

    Hey Kristjan,

    Congrats on the success of your community!

    BuddyPress is designed and architected to scale quite elegantly, so long as the underlying hardware can also support it. It’s a bit of a non-answer, but is ultimately what it boils down to.

    (For example, WordPress.org has about 13 million registered user accounts, and on any given day they are active across the various connected properties, but there are a few dozen web servers handling the constant database reads & writes, API calls for software updates, caching various parts, etc…)

    Group creation (and subsequent user memberships) all eventually just bubble down to a singular and easy to use function call, so depending on your parameters, and with a small custom plugin, could be automated pretty easily. Nothing exists in BuddyPress itself to facilitate the automation part, but there’s nothing preventing it either.

    Perhaps to more directly answer your question, there is no technical limitation to the number of users or groups or group members your community could have, beyond the limitations of MySQL, PHP, and modern computing itself (maximum 32 bit integer value, etc…)


    JJJ
    Keymaster

    @johnjamesjacoby

    Hey @steverusso66! I noticed you hit an error when you posted your reply; sorry about that.

    Everything should be all fixed up now.


    JJJ
    Keymaster

    @johnjamesjacoby

    BuddyPress 2.8.x works OK with WordPress 4.8.

    BuddyPress 2.9 is due out in the next few weeks.


    JJJ
    Keymaster

    @johnjamesjacoby


    JJJ
    Keymaster

    @johnjamesjacoby


    JJJ
    Keymaster

    @johnjamesjacoby

    Great job everyone!


    JJJ
    Keymaster

    @johnjamesjacoby

    This is an interesting problem, if I understand it correctly.

    Your debug backtrace makes it look like the $wp_admin_nav array is somehow getting overloaded by the $wp_admin_bar global.

    And it also looks like the bp_setup_admin_bar action is returning a string, instead of the array() that it’s hardcoded to pass in by default. It seems odd that PHP 7.1 would effect this, unless there’s something going on inside of WP_Hook, or we’ve goofed somewhere that isn’t obvious.


    JJJ
    Keymaster

    @johnjamesjacoby

    Just added a link in the header across buddypress.org.

    Excited to see how this turns out!


    JJJ
    Keymaster

    @johnjamesjacoby

    Thanks for the post, and thank you everyone that chimed in to alert the OP about the protocol for security concerns. Understanding it’s possible there’s a communication gap here, this topic does also read (to my eyes) as condescending & inflammatory, which is honestly not going to yield a very positive conversation. I think y’all did a great job staying positive, and I for one greatly appreciate that.

    To be clear to anyone else that runs into this topic, what the OP sees is not a BuddyPress or bbPress bug; this is WordPress doing it’s best to show published content from public post types.

    About BuddyPress:
    * Neither BuddyPress nor bbPress modify this core behavior
    * BuddyPress does not use this interface; bbPress does
    * The .org sites have not disabled this, they just do not have any unusual content to leak

    The gist:
    * If plugins allow for private content, it’s up to those plugins to protect it
    * If you create roles with content limitations, it’s up to you to confirm they’re working

    For anyone looking to modify or restrict content that appears in this list, use the wp_link_query_args and wp_link_query filters to do so.

    Here is how WordPress calculates the results in this list. Note that it only uses published posts from public post-types:

    $pts = get_post_types( array( 'public' => true ), 'objects' );
    $pt_names = array_keys( $pts );
    
    $query = array(
    	'post_type' => $pt_names,
    	'suppress_filters' => true,
    	'update_post_term_cache' => false,
    	'update_post_meta_cache' => false,
    	'post_status' => 'publish',
    	'posts_per_page' => 20,
    );
    

    WordPress has a built-in way to calculate privacy scope using 'perm' => 'readable' and even that is not used here (though bbPress does use this in its own loops.) WordPress instead takes a strict position of published public content by default.

    If anything unexpected is appearing here, it is not because of BuddyPress or bbPress, and we are still happy to help anyone discover the source of this in a new & more friendly topic.


    JJJ
    Keymaster

    @johnjamesjacoby

    Hi there! Where did you get the codex.fr.buddypress.org URL from? I have a hunch the reason you’re seeing this is because subdomains more than 1 level deep aren’t covered by our certificate, but I also don’t think we use those anywhere. If we do, we should correct those URLs to be more friendly.

    That said, I suspect keeping codex content synchronized across multiple languages will be a pain. Maybe it’s easier (though obviously not very welcoming or inviting) to machine translate from English?


    JJJ
    Keymaster

    @johnjamesjacoby

    Thank you to everyone that helped make BuddyPress 2.3.0 happen! <3


    JJJ
    Keymaster

    @johnjamesjacoby

    We’ve released 2.2.3.1 to address this.

    It should appear in your dashboard shortly.

    If the error is preventing you from accessing the dashboard, delete wp-content/plugins/buddypress completely, and try again.


    JJJ
    Keymaster

    @johnjamesjacoby

    Hi Anja,

    You can reinstall 2.2.3, and this error will go away.

    Sorry for the embarrassing inconvenience.


    JJJ
    Keymaster

    @johnjamesjacoby

    Sorry about that confusion. It may have been a reply that ended up in moderation for a bit. We’re working on improving that in bbPress for 2.6, which is the prerelease version we’re running here.


    JJJ
    Keymaster

    @johnjamesjacoby

    Note that there is a Trac ticket for this also, should it turn out to be some kind of BuddyPress bug: https://buddypress.trac.wordpress.org/ticket/6194


    JJJ
    Keymaster

    @johnjamesjacoby

    I gave the Role bp_moderate but that did not solve the issue. There must be some other check that needs to be passed for these menu items to show up.

    You may want to put a late filter on map_meta_cap to ensure it’s truly getting added, and not getting stomped or mapped back to manage_options.

    Maybe a compromise could be found and some new functionality for the front end could be introduced that allows you to assign someone as Group Admin. I think i am not the only one that sees value in that Role especially in a big community where you have the need to moderate but do not want to give people access to the backend or higher Administrative privileges.

    You’re on the right track. Each component could (and maybe should) come with its own hierarchy of roles. Just because someone can manage users doesn’t mean they can manage groups, if that makes sense?

    I also don’t quite understand why a Group admin could not be derived from one of the Forum Roles. A forum Moderator or Keymaster should be able to moderate all Forums incl. the private group ones and could subsequently also be allowed to manage all groups.

    Anything is possible, but I’m not sure this approach is a safe assumption for all installations. At least not in its current iteration.

    All good ideas. Thanks @ubernaut for the bump.


    JJJ
    Keymaster

    @johnjamesjacoby

    That’s no good. Thanks for the report. We’ll do some testing and report back with the results.


    JJJ
    Keymaster

    @johnjamesjacoby

    @agentswall Are you saying that the link to create groups is missing? Are you able to go to groups/create manually and see the form?


    JJJ
    Keymaster

    @johnjamesjacoby

    2.2 is out!


    JJJ
    Keymaster

    @johnjamesjacoby

    @modemlooper That’s not a bad idea. I’ll work towards that approach after 2.2 goes out today.


    JJJ
    Keymaster

    @johnjamesjacoby

    The goal was to draw attention to the fact that individual forum categories even exist, as a fair amount of topics in our forums end up in the wrong place.

    Any suggestions how to emphasize individual forums without that emphasis being distracting to you?


    JJJ
    Keymaster

    @johnjamesjacoby

    Also @skyrant, it’s possible this is just a bug in our implementation, and using WordPress’s add_menu_page() function, which requires a capability be passed into it that is consequently checked on the current site being accessed, and not the root site where the bp_moderate capability is likely to be assigned.

    I’ve opened a ticket in our bug tracker to bring a bit more attention to this as a bigger issue, so if you end up creating any patches, go ahead and drop them there:

    https://buddypress.trac.wordpress.org/ticket/6175


    JJJ
    Keymaster

    @johnjamesjacoby

    Hey @ubernaut. All thoughtful consideration is appreciated and encouraged, but your “doesn’t currently exist in buddypress” response was neither, considering @skyrant appeared to already frustrated by BuddyPress not performing to his expectations.

    It was also inaccurate, as functions like bp_current_user_can() exist explicitly to enable developers to extend this functionality. If skyrant is unable to make it work, more open-ended questions about the approach will help us figure out what’s not working correctly, be it on his/her end or ours.

    And this…

    please let me know if you feel like my participation is no longer desired around here

    This isn’t the case, and if it ever was to be, never let that stop you anyways. We are all trying to build cool things and improve the world through better open-source community software. It’s inclusive at it’s core. Only twice in eight years have we excluded anyone because of clearly malicious abuse of other members, and it still bothers me to have needed to do so.

    <3


    JJJ
    Keymaster

    @johnjamesjacoby

    You can also look at our _bp_enforce_bp_moderate_cap_for_admins() function for a clue as to what might be preventing your bp_moderate role and capability checks from needing the additional manage_options capability.


    JJJ
    Keymaster

    @johnjamesjacoby

    Hey @skyrant, project lead chiming in here. Apologies for @ubernaut’s response; it doesn’t come across as very helpful or inviting, nor does it point you in any directions as to where to start building this type of functionality, which is the type of helpful reply I would expect from our forums normally.

    You’ll want to look into WordPress’s map_meta_cap filter, and more specifically, our bp_moderate capability checks.

    In the old days, we used a bunch of is_super_admin() checks to only allow the type of access you desire to network administrators. This proved to be too powerful an assumption once BuddyPress started working on Single-Site installations, and so we ported (almost) everything to checking for bp_moderate instead.

    You could create a new role and grant it the bp_moderate capability. In doing so, any user with that role will have the ability to moderate the entire BuddyPress community.

    This also is a bit more powerful than we would like it to be, and in the future we hope to introduce dedicated roles and capabilities all through-out BuddyPress very similarly to the way we did with bbPress. It’s not in the immediate roadmap however, so if this is an area you’re interested in, and want to help us improve it, let’s keep a dialogue going here and see if anyone else chimes in.

Viewing 25 replies - 1 through 25 (of 1,738 total)
Skip to toolbar