Search Results for 'buddyboss'
-
Search Results
-
BuddyPress’s activity component has excellent query-level extensibility:
From BP_Activity_Activity::get() — lines 666, 682
$where_conditions = apply_filters( 'bp_activity_get_where_conditions', $where_conditions, $r, $select_sql, $from_sql, $join_sql ); $join_sql = apply_filters( 'bp_activity_get_join_sql', $join_sql, $r, $select_sql, $from_sql, $where_sql );These filters allow any addon to inject WHERE clauses and JOINs into the main activity query without modifying core. BuddyBoss’s moderation system, for example, hooks into
bp_activity_get_where_conditionsto hide suspended content — all from addon-level code.The messages component has **no equivalent**.
BP_Messages_Thread::get_current_threads_for_user()builds its SQL in a$sqlarray (lines 790–794) and executes it directly:$sql['select'] = 'SELECT m.thread_id, MAX(m.date_sent) AS date_sent'; $sql['from'] = "FROM {$bp->messages->table_name_recipients} r INNER JOIN {$bp->messages->table_name_messages} m ON m.thread_id = r.thread_id {$meta_query_sql['join']}"; $sql['where'] = "WHERE {$deleted_sql} {$user_id_sql} {$sender_sql} {$type_sql} {$search_sql} {$meta_query_sql['where']}"; $sql['misc'] = "GROUP BY m.thread_id ORDER BY date_sent DESC {$pag_sql}"; $thread_ids = $wpdb->get_results( implode( ' ', $sql ) );The only filter (
bp_messages_thread_current_threads) fires AFTER the query on the fully-constructed result set (line 841) — meaning addons must filter in PHP, not SQL. This is:- **A performance problem** — filtering in PHP means fetching rows from the database that will be discarded, and constructing full
BP_Messages_Threadobjects for threads that are then thrown away. This gets worse as thread count grows. - **An extensibility gap** — addons that need custom thread filtering (archiving, priority inbox, moderation, read/unread management) have no clean way to modify the query
- **Inconsistent with the activity API** — activity has comprehensive pre-query filters; messages doesn’t
#### Proposed Change
Add filter hooks to
get_current_threads_for_user()before query execution, following the pattern established byBP_Activity_Activity::get():After building $sql array (around line 794):
/** * Filters the WHERE SQL for the current threads query. * * @since {next_version} * * @param string $where_sql Current WHERE clause. * @param array $r Parsed query arguments. * @param string $select_sql Current SELECT clause. * @param string $from_sql Current FROM clause (includes JOINs). */ $sql['where'] = apply_filters( 'bp_messages_thread_get_where_conditions', $sql['where'], $r, $sql['select'], $sql['from'] ); /** * Filters the FROM/JOIN SQL for the current threads query. * * @since {next_version} * * @param string $from_sql Current FROM clause (includes JOINs). * @param array $r Parsed query arguments. * @param string $select_sql Current SELECT clause. * @param string $where_sql Current WHERE clause. */ $sql['from'] = apply_filters( 'bp_messages_thread_get_join_sql', $sql['from'], $r, $sql['select'], $sql['where'] );**Note on parameter style:** In
BP_Activity_Activity::get(), the WHERE conditions are passed as an array (joined to a string after the filter), whereas in the messages method they are already a string. This proposal preserves the existing messages code structure and filters the string directly, which is the minimal-change approach. If BP maintainers prefer, the messages SQL could also be refactored to use an array of conditions for parity with activity — but filtering the string is sufficient for all the use cases described below.#### Scope
- ~12 lines added to one file (
class-bp-messages-thread.php) - Zero behavioral change — the filters pass through existing values by default
- Follows the pattern established by the activity component’s existing filters
- The existing
bp_messages_thread_current_threadspost-query filter continues to work as-is
#### What This Enables for Addons
With these hooks, addon plugins can implement:
- **Message archiving** — Add
is_hiddencolumn tobp_messages_recipients, filterWHEREto excluder.is_hidden = 1 - **Message soft-delete** — Add
is_deletedcolumn tobp_messages_messages, filterFROM/JOINto exclude deleted messages from thread listing - **Content moderation** — Inject suspend/block conditions into thread queries
- **Priority inbox** — Filter by custom meta or thread properties
- **Group messaging** — Filter threads by group membership context
None of these features require core changes — they just need the ability to modify the query, which activity already provides but messages doesn’t.
#### Prior Art
BuddyBoss Platform needed exactly these extension points. Because the hooks don’t exist in BuddyPress core, BuddyBoss had to:
- **Restructure
get_current_threads_for_user()** entirely — they replaced it with a delegating call to a newget_threads_for_user()method containing ~400 lines of rewritten SQL logic - **Add
is_hiddenandis_deletedcolumns** directly into the restructured query conditions - **Add their own filter hooks** —
bp_messages_recipient_get_where_conditionsandbp_messages_recipient_get_join_sql— with signatures functionally identical to what this proposal suggests
The fact that BuddyBoss independently arrived at the same solution (pre-query filter hooks on the messages SQL) validates the need. If these hooks had existed in BuddyPress core, BuddyBoss could have achieved the same result from addon-level code without forking the class.
I’m happy to submit a PR for this change.
BuddyPress activities have a single visibility control:
hide_sitewide(0 or 1). This provides binary visibility — shown everywhere, or hidden from sitewide feeds. There’s no way to express:– **”Only me”** — private activity visible only to the author
– **”Friends only”** — visible only to the author’s friends
– **”Logged-in users”** — hidden from anonymous visitors
– **”Group members only”** — visible only within the group context where it was postedPer-item privacy is a foundational social platform feature. Facebook has had it since 2009. LinkedIn, Twitter/X (with protected tweets), Instagram, and every major social network support some form of per-post audience control. It’s as fundamental to a social platform as
hide_sitewideis — just multi-valued instead of binary.This is not a request for any specific addon’s needs. It’s a request for the same kind of infrastructure that
hide_sitewideprovides — a first-class column that any addon can use to implement privacy-aware features.#### Current State
BuddyPress 14.4.0’s activity query system is well-designed for extensibility:
–
bp_activity_get_where_conditionslets addons inject WHERE clauses
–bp_activity_get_join_sqllets addons add JOINs
– Data hydration usesSELECT *(inpopulate()and the cache-miss path ofget()), so any column added to the table is automatically returned to calling code
–bp_activity_before_save/bp_activity_after_saveprovide save-time hooksAn addon **can** add a
privacycolumn viadbDeltaand filter queries viabp_activity_get_where_conditions. However, thesave()method has a hardcoded column list in its INSERT/UPDATE SQL (inBP_Activity_Activity::save()), meaning an addon must do a separate$wpdb->update()after every save — a double-write on every activity creation. This works but is suboptimal, and the column’s general-purpose nature (used by media addons, document addons, moderation addons, group addons — not just one feature) argues for core inclusion.#### Proposed Change
**Schema:** Add one column + index to
bp_activityinbp_core_install_activity_streams()(inbp-core-admin-schema.php).dbDelta()handles adding the column on upgrade automatically:sql
-- Added after the existing <code>is_spam</code> column in the CREATE TABLE definition: privacy varchar(75) NOT NULL DEFAULT 'public', -- Added to the KEY list: KEY privacy (privacy)**Model class (
BP_Activity_Activity):**1. Add
public $privacy = 'public';property
2. Insave()— addprivacyto the INSERT/UPDATE column list alongside the existing columns (user_id, component, type, action, content, etc.)
3. Inget()— add'privacy'to the$rdefaults (defaultfalse, meaning no filtering). When set, addAND a.privacy IN (...)to the WHERE conditions.**REST API (
BP_REST_Activity_Endpoint):**4. In
prepare_item_for_response()— exposeprivacyin the response object (paralleling howhide_sitewideis currently exposed ashidden)
5. Inprepare_item_for_database()— acceptprivacyas a writable field on create/update**Migration:**
dbDelta()runs on every upgrade viabp_core_install(), so modifying the CREATE TABLE definition is sufficient for the schema change. A DB version bump inbp-core-update.phptracks the upgrade.#### Scope
– ~40 lines of changes across 4 files (
bp-core-admin-schema.php,class-bp-activity-activity.php,class-bp-rest-activity-endpoint.php,bp-core-update.php)
– Default value'public'— 100% backward compatible
– Existing queries that don’t passprivacyreturn all activities as before
–hide_sitewidecontinues to work as-is (orthogonal —hide_sitewidecontrols directory listing,privacycontrols per-item access)#### What Core Provides vs. What Addons Handle
To be explicit about scope: this proposal adds **storage and query filtering only**. Core would:
– Store the
privacyvalue on each activity row
– Allowget()callers to filter by privacy value(s)
– Expose/accept the field through the REST APICore would **not** need to:
– Define a fixed set of allowed values (addons register the values they need — e.g.,
'onlyme','friends','loggedin')
– Enforce access control based on privacy values (addons hook intobp_activity_get_where_conditionsto inject viewer-aware WHERE clauses, exactly as they would today for any custom filtering)
– Provide UI for selecting privacy (addon/theme territory)This mirrors how
hide_sitewideworks today — core stores the flag and filters on it; the decision of *when* to set it is made by callers (groups component, plugins, etc.).#### Prior Art
BuddyBoss Platform (a BuddyPress-derived platform) implemented this exact column. Their
bp_activityschema includesprivacy varchar(75) NOT NULL DEFAULT 'public', and their media, document, video, and moderation subsystems all depend on it for privacy filtering. The column is referenced in their activity save/query paths, REST API, and template layer — making it one of the most cross-cutting additions they made to the activity table. The fact that an independent platform needed this to build standard social features demonstrates both the demand and the general-purpose nature of the column.I’m happy to submit a PR for this change.
Hi BuddyBoss community,
I’m having trouble activating BuddyBoss components programmatically. I’ve tried several approaches, but the components aren’t being enabled. Here’s what I’ve attempted:
Using bp_update_option()
Direct database updates
Different hooks (init, after_setup_theme)
Current Behavior:No components activate
No error messages in logs
Tried both single site and multisite
What I Need:A reliable way to activate components (Groups, Activity, Messages, etc.)
Best practices for programmatic component management
Any known issues with automatic component activation
<?php
/**
* BuddyBoss Components Activator
* Add this to your theme’s functions.php or as a must-use plugin
*/// Make sure we don’t expose any info if called directly
if (!defined(‘ABSPATH’)) {
exit;
}// Hook into after_setup_theme to ensure BuddyBoss is loaded
add_action(‘after_setup_theme’, ‘activate_buddyboss_components_on_init’, 9999);function activate_buddyboss_components_on_init() {
// Check if BuddyBoss is active
if (!function_exists(‘buddypress’)) {
return;
}// Get current active components
$active_components = get_option(‘bp-active-components’, array());// Components we want to activate
$components = array(
‘groups’ => 1,
‘activity’ => 1,
‘messages’ => 1,
‘notifications’ => 1,
‘friends’ => 1,
‘settings’ => 1,
‘xprofile’ => 1,
‘members’ => 1
);// Merge with existing components
$new_components = array_merge($active_components, $components);// Only update if there are changes
if ($active_components != $new_components) {
update_option(‘bp-active-components’, $new_components);// Clear BuddyBoss component cache
if (function_exists(‘bp_core_reset_incrementor’)) {
bp_core_reset_incrementor(‘bp_active_components’);
}// Flush rewrite rules on next load
set_transient(‘bb_flush_rewrite_rules’, ‘1’, 60);
}
}// Handle rewrite rules flush
add_action(‘init’, ‘bb_maybe_flush_rewrite_rules’, 9999);
function bb_maybe_flush_rewrite_rules() {
if (get_transient(‘bb_flush_rewrite_rules’)) {
delete_transient(‘bb_flush_rewrite_rules’);
flush_rewrite_rules(false);
}
}I was on buddyboss for a couple of years on a fairly popular site. I had issues several times and decided I wanted to move back to buddypress. We lost a lot of things. Photos mostly but also the activity feed is not what it was. Nothing shows when it loads in default setting of “everything” I can selected new members and that shows a member registered a year and a half ago and yet we have had new members everyday. Anyone have any thoughts on this? Your help is greatly appreciated.
Thanks for the screenshots, they do help. The page shown (General Settings) looks very similar to a page that is provided by the BuddyPress Groups Extras (BPGE) plugin, see the following screenshot:
As indicated in the screenshot, the Home or, in your case, the
Activities tab is fixed in place by the code:if ( $nav['slug'] === 'home' ) { $disabled = 'ui-state-disabled'; }The above snippet can be found here and just indicates that the Home tab is disabled from being sortable. The following is what the element (li) has as classname (
default ui-state-disabled) for a non sortable tab of which the only one is the Home tab.<li id="position_686f6d65" class="default ui-state-disabled"> <strong>Home</strong> </li>While a sortable tab has
default ui-sortable-handleas a classname.<li id="position_6d656d62657273" class="default ui-sortable-handle" style=""> <strong>Members <span>1</span></strong> </li>The BPGE plugin author claims this change was due to:
Group's "Activity"/"Home" navigation link is hard coded in BuddyPress to always be the first one, so disable its reordering.However, when I rollback from v3.7.0 to v3.6.10, the Home tab is now sortable and can be moved. So the reason for the change is not entirely true.
Moving along, since the General Settings page from the BPGE plugin is similar to the page from your screenshots, we may be able to infer that there was a fork of some the code (the pages portion) from the BPGE plugin and was included in the BuddyBoss theme which AFAIK is a commercial (paid) theme, meaning I can’t verify the code within this theme due the status of free vs paid. If this is the case, then your resolve will have to come from the BuddyBoss developers. However, if the code that supports manage Page general setting resides elsewhere, e.g., custom code or 3rd party plugin, then the resolve is the responsibility of those who authored the code.
As an aside, as it relates to the BPGE plugin, there is an appearance of wonkiness with the reordering of group tabs which appears to be a factor that caused the change to make the Home tab not sortable, however, I’m not sure if BuddyPress is causing the wonkiness,
Having stated all of the above, it seems to me, the reason that you want the Pages tab to be the first tab is because you want that to be the landing page. Would this be a correct assumption? If so, there may be the possibility of changing the landing page to Pages, regardless of the tab order, which will depend on similar the code is similar enough to the BPGE plugin.
Hi,
I am using the “BuddyPress Messaging Control” plugin (available here) and ran into some bugs with it. The creator has not responded so I thought I should ask here.Issue 1:
This plugin is used to restrict who (based on user roles) can send how many messages to whom and within what time period, eg free user roles can send 10 messages a week or only reply to messages sent to them, but paid users can send unlimited messages to anyone).When I tested this plugin with the latest Buddypress and WordPress version and BuddyX theme, when you go to send a message, and your account is restricted, there is a message that says “Your messaging is capped, you can send a further”. and “Your messaging is set to Reply Only, you can only message users who have previously sent you a message, in addition you are only able to send another”. It doesn’t show the quota, and I would like for it to show it, because this just looks silly.
Issue 2 and 3:
In the Buddyboss platform (Buddyboss says anything made for Buddypress is compatible with Buddyboss, but it doesn’t actually seem so) the messages can be sent by simply pressing enter, there is even a message that says “Enter to Send Shift+Enter to add a new line”. But, pressing the “enter” key doesn’t visibly do anything, ie the message that you typed still stays in the text box, it doesn’t move to the sent messages box, so it is not obvious that a message was sent. Then the user will repeatedly press “enter” until they run out of their alloted messages. Then a message appears that says “There was a problem sending your message.”The first of this issue is obviously the message not “sending” upon pressing “enter”.
The second of this issue is that the message itself is vague and not specific: It should say “You have used up your message quota for this period.”I am wondering if anyone can help with fixing these things.
Thank you in advance.Topic: Hyerarchical groups for BP
https://github.com/dcavins/hierarchical-groups-for-bp
Unfortunately, this very important plugin is no longer updated with the latest version of BP and crashes the system. It would be helpful if it was updated and if possible integrated directly into the BP core, as Buddyboss has already done.
- **A performance problem** — filtering in PHP means fetching rows from the database that will be discarded, and constructing full
