• See previously BP Dev Chat summary April 17 (2024)
• In attendance: @dcavins @im4th @emaralive @espellcaste @vapvarun
• Slack archive

👷‍♂️ 12.4.1 Retrospective

We started the meeting discussing about Security Releases process. This process is happening very privately and we are making sure to be as quiet as possible about the security fix(es) we include into the code. BuddyPress Committers received a security alert from the WordPress Plugin Team on April 20. It was involving our dynamic Block Widgets (read 12.4.1 changelog for more information about it). Once we fixed it, as requested by the WordPress Plugin Team, we performed a complete Security Check about BuddyPress code using the Plugin Check plugin. This check revealed many escaping improvements were needed. As security is our first priority, we decided to also include all needed escaping improvements into the 12.4.1 security release, even if we knew we were taking the risk of being too conservative about some of these (Security Releases can’t be beta tested). Once the security release was published, some escapes were actually problematic and generated 5 regressions.

During the chat, we took the decisions:

• to take more time to test 12.4.1 to eventually find other regressions postponing our next meetings by a week ;
• to quickly package a maintenance release to get rid of these regressions (12.5.0 has been released on May 14, 2024) ;
• to improve our GitHub action checking WordPress Coding standards so that it now includes Escaping rules (@espellcaste committed the improvements on May 4, 2024).

NB: #9080 (Deployment Process review) would be a really great improvement: building the Security Releases was a pretty long task as we backported the fix to the 11.0, 10.0 & 9.0 branches and the 11.4.1, 10.6.3 & 9.2.3 tags were made available on the Plugin Directory.

🧰 BuddyPress 14.0.0

We then talked about ticket #8728 (allowing group mods/admins to delete corresponding group activities): @im4th has grouped unit tests and patch into this GitHub PR which is also taking in account @needle feedback. We decided to take more time to test the PR before committing it to SVN trunk.

@espellcaste asked the team whether we should also sort values for xProfile options (see #8728): we agreed field option values should respect the sort options for multiselect/checkbox fields.

@espellcaste requested team’s opinion about the fact it’s currently possible to request many activation emails “resend” (see #9137): we agreed we should add some sort of feedback to the user after locking them for a period of time (maybe an hour, will be configurable), a bit like WordPress does it for comments.

Finally we talked about a possible breaking change about including all additional signup fields into the BP REST API corresponding endpoint (see this PR). As it was a bit late and we needed more time to figure it out @im4th made his suggestions a bit later. @espellcaste has since merged the PR and wrote a great developer note about it.

14.0.0 schedule reminder

• June 3: 14.0.0-beta1.
• July 8: 14.0.0.

Next Dev-Chat

It will happen on Wednesday May 22, 2024 at 19:00 UTC in #BuddyPress.

#12-0-0, #14-0-0, #dev-chat, #summary

• See previously BP Dev Chat summary March 20 (2024)
• In attendance: @dcavins @im4th @emaralive @espellcaste @vapvarun
• Slack archive

🧰 BuddyPress 14.0.0

Although we planned to share the progress we achieved about 14.0.0 tickets, just after @vapvarun informed he will work on #9097 (Member type assignment), we focused our attention on Group roles (#8728: making sure the group’s moderator role can better assist the group’s administrators).

Let’s clarify what can do each advanced role of a Group

If #8728 is about letting group moderators delete group activities, we extended the discussion to group admins and a particular group admin : the group creator.

• The bug: it looks like this filter callback is not doing the job it should. Group moderators according to this code should be able to delete group activities.
• @im4th’s concern: deleting someone else content is a serious move. He personally thinks instead of deleting the activity, all group roles should only be able to remove the activity from the group or spam it. He also hardly understands why an activity could be deleted as it’s possible to spam & kick a group member. He asked to check what happens to activities a group member shared within the group once they are marked as spammer or kicked out of the group.
• BP Team’s majority is thinking group moderators and admins should be able to delete group activities and understands why sometime we might need to delete one off topic activity instead of spamming the group member.
• @emaralive suggested to leave site admins then group admins choose about whether group activities can be moderated:
  • Site owner determines whether group activities can be moderated.
  • Group creator/admins determine whether group mods can moderate group activities.
• When Akismet is active, activities can be marked as spams. @vapvarun suggested to use the activity spam flag to allow moderation within a group. He then quicky checked if group admins or moderators can use this feature: it turned out only Site Admins can use it!
• Finally, @im4th suggested the following steps to clarify the situation:
  • Test widely what a mod can do in a group (eg: can he ban/kick/spam a user, delete an activity etc..)
  • Test widely what a group admin can do
  • Test widely what a group creator can do
  • Understand why the `bp_groups_filter_activity_user_can_delete` filter is not doing what it should.
• @emaralive who is assigned on the ticket agreed & will investigate 🕵️‍♂️.

14.0.0 schedule reminder

• June 3: 14.0.0-beta1.
• July 8: 14.0.0.

Next Dev-Chat

It will happen on Wednesday April 17, 2024 at 19:00 UTC in #BuddyPress.

#14-0-0, #dev-chat, #summary

• See previously BP Dev Chat summary March 4 (2024)
• In attendance: @dcavins @im4th @emaralive @espellcaste @vapvarun
• Slack archive

📦 12.4.0 minor release

During the chat we discussed about the opportunity to build this maintenance release a bit before WordPress 6.5. @emaralive volunteered to test the last unfixed ticket of the milestone (See #9086). At the end of our chat @vapvarun brought #9096 to the discussion. The Last activity repair tool has become obsolete and we forgot to remove it from the available BP tools. Site Admins who used it so far experienced a very annoying effect: after the last activity item are removed they are not generated back. Result is the Members directory can have no active users displayed. We’ve explained why this tool was added in BuddyPress 2.0 and came to the conclusion it should now be removed to prevent the issue about « vanishing » Active Members. We evaluated we couldn’t wait for a major release like we’re used to do for such a change and decided to fix it into this maintenance release. 12.4.0 was released on March 25.

🧰 BuddyPress 14.0.0

Thanks to #9086 patch, @dcavins transitioned to a ticket slated to the 14.0.0 milestone: #9063. The goal of this ticket is to be able to have BP directory pages as children of another one. Instead of doing this @im4th’s plan is to only use the WP rewrite rules improving the BP Rewrites API to make support custom root prefix (eg: replace / by /community/ for instance.

The Site Wide Notices debate

In short, @im4th opened this ticket #9098 to explain why he thinks this feature should become a Core feature instead of being dependent of the BP Messages component.

• At the beginning of the debate, moving it to the BP Notifications component (probably to improve consistency) seemed a better option.
• @im4th’s concern was not satisfied with this scenario as it’s still an optional component: using Site Wide Notices to replace the Admin Notifications workaround we introduced in version 11.4.0 couldn’t be achieved as this component might be not active on some setups. He’d rather wait for the WP Notifications feature as a plugin in this case.
• @espellcaste then suggested to build a new BP Add-on for this Notice feature. In this case we’d still need to use the Admin Notifications workaround to inform Admin Users about the big changes we plan to achieve in BuddyPress future. As @dcavins noted « Yes, the 11.4 workaround was pretty workaroundy. » 😅
• @espellcaste last suggestion reached a consensus: build Site Wide Notices as a Core feature but make sure it integrates well with the Notifications component when active.
• @im4th shared the main goals of this Core change:
  • improve the Site Wide Notices feature right away so that Admin Users can read our important messages but not into the WordPress Admin Notices traffic jam.
  • & let Admin Users still using it to inform all community members at once on the front-end (the current feature).

14.0.0 top features

1. @emaralive suggested #8319: using the Block Editor to write BP Activities. The potential for such an editor for the Activity component is very interesting: for instance BP Attachments is already using « Activity blocks » to post media from the Activity Block Editor (feature as a plugin). We could add Polls, Links etc…
2. @dcavins suggested #1058: being able to export / import BP Data is something we’ve been thinking about for a while and it would be nice to engage into the Data Liberation WordPress project.
3. @emaralive also suggested #9057: being able to deactivate the BP registration workflows. Building it as an optional component is not the road @im4th thinks we should take. Instead it should be a « deactivable » Members feature. @dcavins will look at it starting slowly by only using the WP signups table and stop creating users on regular WordPress sites.
4. @dcavins also suggested #8728: making sure the group’s moderator role can better assist the group’s administrators. @emaralive is working on it and thinks he will fix the ticket during the 14.0.0 development cycle.

Finally we quicky talked about BuddyPress permissions management and realized there’s a lot of possible improvements to bring to this part of the software.

14.0.0 schedule reminder

• June 3: 14.0.0-beta1.
• July 8: 14.0.0.

Next Dev-Chat

It will happen on Wednesday April 3, 2024 at 19:00 UTC in #BuddyPress.

#12-0-0, #14-0-0, #dev-chat, #summary