Search Results for 'buddypress'
-
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 everyone,
I’m running a BuddyPress-powered site and noticing the activity stream getting slow as user activity grows, even with caching enabled. It starts to feel heavy once groups, friendships, and posts increase.
How are others keeping BuddyPress fast and scalable while using the core social features?
Appreciate any insights.
Topic: Help Learning BuddyPress?
Hello,
Can I please ask what’s the best way to learn about BuddyPress.
I have looked for tutorials on Youtube but the ones I found are 7 or 8 years out of date. So difficult to get an overview.
I will install the BuddyPress plugin and try and figure things out from scratch if I have to but was just hoping for some background first.
Any suggestions greatly appreciated.
Best Regards,
Steve
P.S. Above the form that I’m using to make this request it says to include the wordpress, buddypress versions. I haven’t installed anything yet but they will be the latest as I’m starting from scratch.
HI i haev tried to add featured groups to my side bar as a widget .The groups show but the css background colour is wrong and html code is showing – the function is not working all the other buddypress featuired members etc all work fine but not groups
I have the same problem I work wordpress on a raspberry PI When I istall buddypres and try to create a group I am taking the wrong error “Not Found
The requested URL was not found on this server.Apache/2.4.65 (Debian) Server at wpress Port 80”
Thank you for your help
———————-
I wand to add that I have no such a problem under “XAMPP” at WIN 11, the above mention proble it happens also to other pages like “friends”, “members”, “Activity”, the theme I am using is the “Di Blog”
Thank you againMoved from: Reply To: The URLs to the pages are not working!
- **A performance problem** — filtering in PHP means fetching rows from the database that will be discarded, and constructing full
