BuddyPress MCP for privacy-bounded members and group admin

Community health questions the BuddyPress MCP can answer

Community managers rarely ask for one group. They ask which groups have gone quiet, which have grown past what their moderators can handle, and how many new members arrived this month. buddypress-list-groups sorts by active, newest, alphabetical or popular and filters by status, up to a hundred groups a page, and each row carries the member count, creator, parent and last activity. buddypress-get-group adds the admin and moderator ids for one group. Between them an agent can produce a table of groups with no recent activity, groups whose only administrator has not been seen in months, and private groups with a single member.

Member questions work the same way within the privacy line. buddypress-list-members sorts by active, newest, alphabetical or popular, searches public identity and filters by member type, and every row includes the member's group ids and last activity. That is enough to count new members, find who belongs to a group, or check a member type's spread. It is not enough to segment by profile answers, contact anyone, or see what members wrote, because none of that is returned.

• Large communities need several pages; ask the agent to say how many it read rather than present a partial count as the total.
• Hidden groups appear only with show_hidden true, and only to a connection whose user can see them.
• check-setup reports whether the connected user has community administration rights, meaning manage_options or bp_moderate.

Restructuring groups: parents, slugs and privacy

buddypress-edit-group changes the name, description, slug, privacy status, parent group and forum flag, and only the fields you send. Parents give a community a hierarchy, such as regional groups under a national one; a group cannot be its own parent and a parent id that does not exist is refused before anything is saved. The forum flag records whether the group should have a forum; the forum itself comes from a separate forum plugin outside this module.

Two edits deserve more thought than the API suggests. A slug change moves the group to a new URL, and GoBuildWP's automatic redirects cover posts, not BuddyPress groups, so old links and bookmarks to the group will break unless a redirect is added by hand. A privacy change always asks for confirmation because of what it exposes. Moving a private group to public makes its past content visible to anyone, and moving a public group to hidden takes it out of the directory and search for everyone who is not already a member. Tell members before either happens.

Setting up a family of BuddyPress groups in one session

Programmes such as a regional network or a course with several cohorts need many groups at once, usually under one parent. Create the parent first with buddypress-create-group, then each child with parent_id set to it, choosing the creator for each so the right coordinator becomes its first administrator. Before every create, the agent should search the listing with show_hidden true for an existing group of the same name, since BuddyPress itself will happily hold two groups with similar names and members will join the wrong one.

Finish with buddypress-get-group on each new group to confirm status, parent and administrator, and look at the group directory as a logged-out visitor and as a member to see that private and hidden groups appear only where they should. Group creation cannot be rolled back from the change log, so a typo in a name is fixed with an edit rather than an undo.

Before a BuddyPress group is deleted

Deleting a group removes its membership records, invitations and metadata with no trash, and the change log records the delete without an undo because the data lives in BuddyPress's own tables. Accounts survive, but who belonged to the group does not. If there is any chance the group will be wanted again, take a record first: get-group for its settings and administrators, and a members listing filtered down to that group id for the roster.

Often the better move is not deleting at all. Setting an abandoned group to hidden removes it from the directory while keeping its members and history, and it can be made visible again later. That is still a confirmed privacy change, but it is one the community can recover from, which a delete is not.

Why the module stops at groups

Messages, activity posts, friendships, invitations, bans and member roles are not exposed, and that is a deliberate boundary rather than a gap waiting to be filled. Each of them either speaks for a person or changes what a person can do in the community. Moderation decisions about members stay with human moderators in BuddyPress's own screens, where they can see the context an agent would only be guessing at.