Search Results for 'Hide Admin'
-
Search Results
-
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.
Hello guys!
I’ve seen this question in here a couple of times and maybe others would enjoy this code.
I couldn’t find a good solution in trying to “hide” the official and hidden groups, when users are creating them (it just would not allow me to hide them!).I then managed to fix a code and make it work so at least it shows an error when a user (besides admin) tries to create a group that is NOT private. In this way when a user tries to create a public/hidden group it will not allow the user to “proceed” with the next step unless private group is chosen.
Feel free to update the CSS to your liking!
Hope it helps, enjoy! 🙂
function restrict_group_type_selection() { // Ensure this script only runs during the group settings creation step if (bp_is_group_creation_step('group-settings')) { // Check if the user is not an admin (wrap the condition outside the script for cleaner HTML output) if (!current_user_can('manage_options')) { ?> <style type="text/css"> .group-type-error-message { color: #ffffff; background-color: #f95959; position: relative; margin-top: 20px !important; border: 0 !important; font-weight: 600; } } </style> <script type="text/javascript"> document.addEventListener('DOMContentLoaded', function () { const nextButton = document.getElementById('group-creation-next'); // Target the "Next step" button if (nextButton) { nextButton.addEventListener('click', function (event) { const selectedGroupType = document.querySelector('input[name="group-status"]:checked'); let errorContainer = document.getElementById('group-type-error-message'); // Remove any existing error message if (errorContainer) { errorContainer.remove(); } if (!selectedGroupType || selectedGroupType.value !== 'private') { // Prevent moving to the next step if the group type is not 'private' event.preventDefault(); // Create and display a styled error message errorContainer = document.createElement('div'); errorContainer.id = 'group-type-error-message'; errorContainer.className = 'group-type-error-message'; errorContainer.innerText = 'You are only allowed to create private groups.'; // Insert the error message after the "Next" button nextButton.parentNode.appendChild(errorContainer); } }); } }); </script> <?php } } } add_action('bp_after_group_settings_creation_step', 'restrict_group_type_selection');Hello all,
I have hidden myself as an admin, on my test site running buddypress, for obvious reasons. However, I discovered that when composing a message using Buddypress messages, when the user types in a partial name of the recipient, even a single letter, everyone that matches that name will show up, even if they are hidden from the directory. For example, typing “@a” will show “@admin” (me) as well as “@adam” or “@amanda” and this is no good.
Is there a way to remove certain users (ideally by user roles) from showing up in the “to” field?
I have WordPress 6.6.1 and Buddypress 14.0.0.
Thank you
hello,
im a none developer and would like to ask if there is a code that you could provide for me to put it into the plugin code snippet (php code) which would hide the activity form (on all sites) from user but stay visible for admins only.
thanks a lot
Hi there
I have a wordpress v6.3.2 with
> BuddyPress v11.3.2
> ProfileBuilder v3.10.1 (in order to have custom fields during registration)
> Elementor ProI have 2 weird behaviour.
1- Non admin users, can see the admin bar with… MY account when they logged in.
Fortunately, they cannot go in my account.
To avoid that, for the moment i installed a plugin : Hide Admin Bar Based on User Roles2- The non admin accounts go directly in the backoffice when they log in (with the connexion button widget of elementor)
Could you please help me?
Best regards
Hi
I would like to hide the two columns in the members directory: role and activity as this is not interesting on our intranet.
Here’s the link to a screenshot: https://tinyurl.com/22pahgnt so the column ‘Rol’ (=role)(Beheerder = Administrator) and ‘Activiteit’ (=Activity) should be hidden.
How can I hide this? Can’t find it in the theme options of Woffice.
Thank you!
Hi!
How can I hide the BuddyPress “Profile Fields” menu entry (in the WP backend) for non-admin users?
https://pasteboard.co/osvfH8ty1JYk.jpg
They should not be able to make changes there.
Thx in advance and best regards
Markus
