[buddypress-trac] [BuddyPress Trac] #8617: Allow disabling avatar revisions in BuddyPress

buddypress-trac noreply at wordpress.org
Mon Jan 17 22:22:30 UTC 2022


#8617: Allow disabling avatar revisions in BuddyPress
------------------------------------+---------------------
 Reporter:  sbrajesh                |       Owner:  (none)
     Type:  enhancement             |      Status:  new
 Priority:  highest                 |   Milestone:  10.0.0
Component:  Core                    |     Version:
 Severity:  blocker                 |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+---------------------

Comment (by imath):

 Hi @sbrajesh

 Rereading my previous comment, I hope you didn't take this part personally
 > So first thing is to think a bit more about it!

 It was me talking to myself 😅.

 Then, I've tried to build
 [https://buddypress.trac.wordpress.org/attachment/ticket/8617/8617.patch
 8617.patch] according to the
 [https://wordpress.slack.com/archives/C02RQBYUG/p1642372565025500
 discussion we had about it in slack] today.

 1. Disabling the avatar history can be done using:

 {{{
 add_filter( 'bp_disable_avatar_history', '__return_true' );
 }}}

 In this case, instead of saving a new revision of the avatar, it's simply
 deleted. Meaning there's only one avatar available for the user: the
 latest. `new_avatar` activity are always using the latest activities (FYI
 when avatar history is enabled, it displays the avatar that was in use
 when the activity was posted.

 2. Disabling richer logging activities can be done using:

 {{{
 add_filter( 'bp_activity_get_types_supporting_generated_content',
 '__return_empty_array' );
 }}}

 I personally think, we should also make it possible for plugins to disable
 this feature using a filter even if it's possible to do it using template
 overrides (which is easier to do when working from a theme). To disable
 one of the richer logging activity, instead of returning an empty array,
 you need to use a callback to return the list of allowed activity type
 names.

 To build this I've tried to think about how could evolve activity types
 feature (I got inspired by the `get_post_types_by_support()` function).
 Imho, the `$bp->activity->actions` global should include a feature
 property and we should make it possible to register activity types
 features a bit like WordPress does it for post types. We can probably
 achieve the WIP function `_bp_activity_get_types_by_support()` in a future
 version of BuddyPress.

 How do the team feel about this suggestion?

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/8617#comment:3>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac


More information about the buddypress-trac mailing list