• 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 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