BP Docs-Chat Summary April 24, 2024

BP Documentation tracker status.

Between April 10 & April 24, we haven’t progressed much about documentation. We were very busy working on the 12.4.1 security release and on the 14.0.0 tickets.

  • PR created : 0
  • PR reviewed : 0
  • PR converted : 0

The need to prioritize Documentation tasks

Following up our previous discussions about our various Multisite configs…

@vapvarun shared with us the great work he’s been doing into this area to prepare a documentation resource about it. He made 4 videos to explain the 4 possible BP Multisite configs:

BP Activated at the Network level, community area on main site of the network
BP only activated on one of the site of the network.
BP Activated at the Network level, community area on a secondary site of the Network
BP Multiblog config 🧗‍♂️

@im4th shared his feelings about all these set-ups : as we’re a short contributor team, we need to prioritize what we document according to the “popularity” of the set-up (in terms of number of people using it). Let’s pick the 2 or 3 most used configs and concentrate on their documentations.

@vapvarun picked the 3 first configs to work on a PR he has since submitted 💪 . He also plans to work on pushing PRs about these 2 other migrate tasks:

Documentation pages to use in BP Admin Screen help tabs

@emaralive has been referencing all BP Admin Screens needing a documentation link into this GH discussion. We decided to share migrate tasks about these documentation pages this way:

Open Floor

@emaralive made a very interesting “map” of all Admin places where BuddyPress is adding pages.

@vapvarun introduced Pooja Sahgal to the team, she will regularly contribute to BP Forums, welcome on board 😍.

Next Docs-Chat

It will happen on May 15, 2024 at 19:00 UTC in #BuddyPress. (We decided to postpone meetings by a week to fully test BuddyPress 12.4.1 & prepare a 12.5 minor release).

#docs-chat, #documentation, #summary

BP Dev-Chat Summary April 17, 2024

🧰 BuddyPress 14.0.0

We first talked about ticket #8728 (allowing group mods/admins to delete corresponding group activities):

  • @emaralive did a great job reviewing existing group roles capabilities. We now have a clear understanding of these.
  • He also worked on fixing the filter callback so that it actually do what it was built for: allowing group mods/admins to delete corresponding activities.
  • @espellcaste has prepared unit tests about it.
  • The last point we needed to take a decision about was to introduce a global community setting to let the site’s Administrator to allow/disallow group mods/admins to delete activity as well as a « per group » basis setting to let the group creator to allow/disallow this delegation for their group. We all agreed it will be a nice addition. So next steps about this ticket is to build the corresponding UIs (BP Settings Admin screen + Group’s create/manage/admin screens).
  • As this summary is being written very late, @emaralive has updated the patch on the ticket 4 days ago and suggests we don’t need a group setting: promoting members to mods or admins seems sufficient.

We then talked about the Activity Block Editor (see ticket #8319):

« Videmo » of the BP Activity Block Editor Add-on
  • It’s still a work in progress that needs improvements such as being able to use this editor to comment an activity (@emaralive noted it), making sure using the paragraph block’s alignment button actually aligns the posted activity.
  • It replaces the current Activity WP Admin screen with a specific Activity stream using this editor to post, edit & comment existing activities.
  • Goal is to first publish it as « feature as a plugin » on WordPress Plugin directory, see how people welcome/use it before eventually merging it into the BP Activity component.

We finally talked about other tickets progress:

  • #8976 Adding custom xProfile fields to registration REST API endpoint: @espellcaste has made great progress about it and should have it fixed soon.
  • #9129 Automated tests with cache services: @espellcaste informed us we’d need a specific GitHub Action to reach this goal as it doesn’t seem possible to use the WordPress env package.
  • #6123 has been fixed, 14.0.0 won’t create users during a regular WP user registration, see this developer note for additional information.

    14.0.0 schedule reminder

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

    Next Dev-Chat

    It will happen today Thursday May 2, 2024 at 19:00 UTC (exceptionaly as yesterday was a day off) in #BuddyPress.

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

    BP Docs-Chat Summary April 10, 2024

    BP Documentation tracker status.

    Phase 1 (a.k.a., BP Codex migration meta task ) was completed which resulted in a total quantity of  271 BP Codex pages reviewed,  which netted 208 pages to be ignored and 63 pages to be migrated.

    The actual count of issues created were:

    • 209 ignore – the extra issue was a duplicate – 209 -1 = 208
    • 58 migrate – there were 5 pages that were included within a single issue – 58 + 5 = 63

    For Phase 2 (a.k.a., BP Documentation meta task) the main emphasis is document creation and, if necessary, the updating of documents previously created during Phase 1, as well as Phase 2.

    A question was posed (by @emaralive) as to the presentation of statistics for Phase 2; IOW, what should be included? @im4th suggested:

    • PR created
    • PR reviewed
    • PR converted

    In an effort to help facilitate the tracking and gathering of metrics for the statistics @emaralive suggested and completed action to archive the 208 ignore issues. This left a total of 71 issues of which 24 issues were completed , by @im4th and @vapvarun, (status of Done) during Phase 1, which left 47 open issues (status of Todo and In Progress) and the % of complete (as of April 10, 2024) to be 34%.

    Futhermore, @emaralive created additional views within the project for documentation (although, this appeared to have gone unnoticed):

    Although, not explicitly stated, the additional project views could help with the gathering of data in support of the statistics, for example:

    OpenClosed% Complete
    Migrate391933%
    Add6440%
    Update2133%
    Total472434%

    Or:

    TodoIn ProgressDone% Complete
    Migrate3901933%
    Add60440%
    Update20133%
    Total4702434%

    However, presentation of documentation statistics is still open to discussion, since this topic has not been settled.

    Follow-up on BuddyPress Multiblog & BuddyPress Multi Network

    A comment was posted regarding BP Docs-Chat Summary March 28, 2024 and the poster’s concern for the deprecation of the BP_ENABLE_MULTIBLOG constant and whether this would affect a plugin the poster was using.. @im4th volunteered to make a reply to the comment and completed the action.

    @vapvarun reported his efforts in support of documentation for this area of interest (Multiblog/Multi Network/Multisite):

    • The availability of screenshots
    • The availability of 3 dedicated videos

    Additionally, @im4th & @vapvarun conversed a bit about the logistics of embedding/including videos within GH (GitHub) documents.

    Open Floor

    @im4th revealed the completion of a:

    “generic” area for resources common to all Handbooks

    Whereby documents such as the following can reside:

    @emaralive suggested and volunteered to update the main README.md for the bp-documentation repo, since Phase 1 has been completed, which makes the content outdated, along with the removal of 2 issue templates (ignore & migrate) that are no longer relevant. This task has yet to be started and @im4th volunteered to review the changes, once a PR has be generated.

    Next Docs-Chat

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

    #docs-chat, #documentation, #summary

    BP Dev-Chat Summary April 3, 2024

    🧰 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

    BP Dev-Chat Summary March 20, 2024

    📦 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

    BP Dev-Chat Summary March 4, 2024

    ⏰ New development meeting day/time

    @im4th suggested to change the day and time we meet to discuss about BuddyPress development so that it’s more suitable for contributors located in Asian time zones. Let’s come back to our “legacy” day/time: every other Wednesdays at 19:00 UTC!

    @emaralive @espellcaste & @dcavins agreed (even during DST, 19:00 UTC can be problematic for David’s presence during 1st meeting half).

    As Documentations chats are also happening at this day/time, we’re always meeting on Wednesdays at 19:00 UTC and depending on the current week number, we’ll be talking about development (even weeks) or documentations (odd weeks).

      🧰 BuddyPress 14.0.0

      Release lead: imath

      @im4th asked if one of us was wishing to lead this release: @dcavins won’t be able to find the time to, @espellcaste volunteered to lead next major release. To let the time to @emaralive to experience a full release development cycle, @im4th volunteered & is the 14.0.0 release lead.

      Ticket updates

      To view the full tickets list slated for this milestone, go there!

      • @emaralive hasn’t progressed yet about #8728 (Allow group moderators to moderate group activities).
      • @espellcaste has put together a local site about BP CLI commands reference (See #9113).
      • @dcavins has not progressed about #8794. It’s a pretty sensitive subject as it deals with capabilities in WP Admin. Best approach seems to be to build a specific & new Admin screen to let users having the bp_moderate cap to manage site membership requests.
      • @im4th reopened #9101 as he was worried about the fact we’re adding 2 accordion sections to the site-health debug screen. It’s closed again as using a single section is not separating nicely settings from constants when using the copy feature.
      • @im4th moved the ticket about improving Activity Favorites management out of the 14.0.0 milestone (See #5644). He was the only one of the team in favor of introducing Likes as Activity children and highlight this as one of the top features for 14.0.0. Users will need to wait for a future BP Relationships API.
      • Without any news from @rayisme, he also moved the Followers feature (See #7133) out of the 14.0.0 milestone. Moreover the plugin’s scope is larger than following members (using it, you can follow activity or blogs for instance).
      • @emaralive wanted to talk about #9098 as re-thinking the Site Wide notices feature can have implications about BuddyPress documentations. But we agreed to talk about it during our next development meeting as it was getting late.

      Finally @im4th asked the team to use the 2 coming weeks to think about the 14.0.0 top features as @dcavins said “it’s nice to have a focus, so that the release accomplishes something that seems cohesive”. So far many of the enhancements slated for next release are to make administering a BP site easier.

      14.0.0 schedule reminder

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

      Next Dev-Chat

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

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

      BP Docs-Chat Summary February 28, 2024

      BP Documentation tracker stats

      • BP Codex contains 271 pages.
      • 202 total tasks were created (migrate + ignore + add + update).
      • 194 tasks related to pages reviewed were created (migrate + ignore).
      • 42  « migrate » tasks were created.
      • 152 « ignore  » tasks were created.
      • 5   « add     » tasks were created.
      • 3   « update  » tasks were created.
      • Approximately, 72% of a total of 271 pages have been reviewed (194 / 271)

      There were various comments by @dcavins & @im4th in regard to the stats:

      • @dcavins made note of the number of ignore tasks that were created and asked whether this was a indication of out of date documents.
      • @im4th made note of the progress made and responded to @dcavins regarding out of date documents, e.g,, pre 1.7 information, Theme changelog, snippets of code, etc.
      • @vapvarun & @dcavins conversed a little bit about the efficacy of code snippets.

      Review of how WP Docs teams handle discrepancies with published documentation (2 examples)

      Example 1 (one) was a DevHub (Advanced Adminstration Handbook) document and example 2 (two) was a HelpHub (End User – Support Guides ) document, of which the purpose was to plant the seed as to how the BP Team would/should handle user feedback:

      • DevHub provided a link to GitHub Advanced Admintration repository.
      • HelpHub provided a comment box, in which to provide user feedback.

      @im4th made note of some confusion regarding the use of discrepancies (the meaning thereof), of which @emaralive provided a general meaning and @dcavins expanded the meaning to include suggestions for improvement. @im4th was initially of the thought to use a method similar to how DevHub handled the situation and wanted a concrete example. @emaralive mentioned that example 2 was an actual issue (the text and screenshots are out of date, from WP v4.9.6, approx.). To move things along and not to belabor the point of this exercise, @emaralive mentioned the opening of a Discussion topic within the document tracking respository whereby further dialogue could be advanced, n,b,, @emaralive still needs to open the topic.

      Open Floor

      Earlier @vapvarun mentioned he had some documentation related Pull Requests ready to go. During Open Floor @vapvarun indicated the following would be next up for him:

      • Configure BuddyPress for Multisite ( possible cases )
      • Installation in WordPress Multisite
      • Languages and Translations

      @im4th indicated the he would review the Pull Requests that @vapvarun had ready to go. During this Open Floor time, @espellcaste indicated that he had documentation (.md files) related to BP CLI that could be placed within the BP docs folder, however, @im4th had some reservations as to where the BP CLI documents should reside. Additiionally, @espellcaste indicated that he had plans to outline the workflow related to BP CLI documents and since we were short on time, I indicated that I would open a Discussion topic in the BP document tracking repository, of which, that discussion can be found here.

      Next Docs-Chat

      It will happen on March 13, 2024 at 19:00 UTC in #BuddyPress.

      #docs-chat, #documentation, #summary

      BP Dev-Chat Summary February 19, 2024

      What do we want to keep in the 14.0.0 milestone?

      • @espellcaste reminded us why he asked about making this specific point: to have a better visibility of what’s actually planned on the milestone. He added that if there was a ticket we don’t know if we would have the time to work on, it’d be great to put in the next milestone.
      • @espellcaste then asked Team members to assign themselves on the tickets they wish to work on during the 14.0.0 development cycle. Once done, his idea was to discuss together about the remaining tickets. He actually took the lead of the meeting to run this tickets review.

      Below is the remaining tickets list:

      • About #7133 (BuddyPress followers plugin to join the BP Add-ons collection) @im4th contacted @rayisme by e-mail but got no reply from him so far. @im4th already has commit access on the plugin’s WP.org repository but he thinks it’s better r-a-y’s GitHub repository is transfered on the BuddyPress organization account before we can all eventually contribute to it.
      • About #9065 it’s an issue Dion Hulse (from the WP Core/Meta team) started contributed to due to potential fatal errors with malformed Request inputs. @im4th thinks it’s important as Dion explained to fix it in BuddyPress waiting for it to be possibly fixed by WordPress, so he assigned himself on the ticket.
      • The chat thread was going pretty quick so @emaralive informed it was difficult to follow especially when you try to read a very old ticket like #5644 (Activity Favorites management). This was actually our second point on our meeting’s agenda! @im4th wanted to take the time to explain why he thinks we really should use Activity children like comments to transform Activity Favorites as Activity Likes. @espellcaste, who was probably very focused on reviewing the remaining unassigned tickets, didn’t pay attention to this discussion and carried on his review. (1).
      • @espellcaste thought @im4th was the best contributor to work on #9063 so @im4th assigned himself on it and will try to make it possible to add a way to use a slug prefix for BP Directories rewrite rules.
      • @emaralive volunteered to work on the Group Moderator cap issue #8728.
      • @espellcaste volunteered to work on integrating Group/Member types into the BP REST API and assigned the requested member types improvement tickets to himself (See #8618 & #9092).
      • @espellcaste then decided to punt unassigned tickets to next release cycle.

      14.0.0 schedule reminder

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

      BP Cli documentation

      Then @espellcaste decided to talk about this subject instead of the 2 remaining points we added to our agenda. His goal is to build a BP Cli command reference like the one WP Cli has elaborated. @im4th suggested « if we can do it for BP Cli, then we can also build a code reference for BuddyPress ». @espellcaste informed he would first look into a code reference for BP Cli as a test ground to see what issues we’ll face before eventually working on a BuddyPress code reference.

      (1) imath’s Apologies to @emaralive & @dcavins

      As I’m @im4th 🤗, the one writing this summary, I’d like to say:

      Even if this tickets Review was an interesting experience and even if @espellcaste was really good at running it, I realize I should have stopped him to take the time to make sure @emaralive could catch up when he expressed his difficulties, make sure @dcavins had a chance to express his wishes during the tickets review, and make sure to respect the meeting agenda. I apologize – a hard day at work was probably the reason why I made these mistakes.

      Next Dev-Chat

      It will happen on March 4, 2024 at 21:00 UTC in #BuddyPress.

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

      BP Docs-Chat Summary February 14, 2024

      On behalf of @vapvarun, @emaralive is posting this summary

      BP Documentation tracker stats

      @im4th reported the following stats:

      • BP Codex contains 271 pages.
      • 158 tasks were created.
      • 38 « migrate » tasks were created.
      • 120 « ignore » tasks were created.
      • Approximately, 60% of a total of 271 pages have been reviewed.

      Contributing to docs is improving code!

      @vapvarun indicated that he has the following documents in WIP:

      • Member Types
      • Site Notices
      • Activate BuddyPress
      • PHP Version Support
      • Version Numbering

      @vapvarun also indicated the possibility of prioritizing the following documents as next up:

      • Getting Started >> Configure BuddyPress for Multisite
      • BuddyPress Administration >> Activity
      • BuddyPress Administration >> Groups
      • BuddyPress Administration >> Forums

      Additionally, during support forum tasks, @vapvarun opened Trac ticket 9096 (Data Loss Issue: Last Activity Deletion impact Member Directory and Friend List due to Repair member “last activity” data.)

      @im4th indicated that @vapvarun was on the correct path for documentation creation.

      @emaralive asked a question about Member Type assignment (who should be able to assign) that lead to the discovery of a bug. Subsequently, @im4th opened Trac ticket 9097 (Member types should be only “assignable” by community admins).

      Next Docs-Chat

      It will happen on February 28, 2024 at 19:00 UTC in #BuddyPress.

      #docs-chat, #documentation, #summary

      BP Dev-Chat Summary February 5, 2024

      What do we expect from 14.0.0?

      • We started with a very interesting thread about transforming the Private Messages component as a Slack-like chat system where BP Groups could be used as channels to discuss with corresponding group members. The wp-sync package could help us to reach this goal.
      • As it’s a pretty huge change, improving the Private Messages component using pagination could be a first step on our road. The potential backwards compatibility obstacle with Standalone BuddyPress themes could be avoided improving the way we currently use the WP Theme support feature adding a list of buddypress features. Eg: add_theme_support( 'buddypress', [ 'messages_pagination', 'etc..' ] ).
      • @emaralive suggested to have a look at the Better Messages plugin.
      • We talked about #7133: Having @rayisme‘s BP Followers into our Add-ons galaxy would be a great addition. As @im4th already got in touch with @rayisme about this subject he will contact him again to ask him if he’s fine with transferring the GitHub repo into the BuddyPress org so it’s easier for the team to contribute to it.
      • @espellcaste see potential Cron related issues about #7953 (Activity Scheduling).
      • @im4th thinks we should consider improve Activity favorites to act like bookmarks or likes, see #5644.
      • About BuddyVibes @im4th is currently working on making it a WP Block only Theme first. He thinks if we’re waiting for a design contribution it will never happen, reason why he chose to work on a very basic structure.

      14.0.0 first schedule!

      14.0.0 will be a shorter development cycle than 12.0.0 (which took us almost a year). A 4/5 months development cycle was decided: 14.0.0-beta1 in 4 months, final release in 5 months.

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

      @dcavins suggested to start discussing on the tickets we should keep into the 14.0.0 milestone during our next meeting. @espellcaste suggested to start looking into it a bit before the meeting to only leave the tickets we should discuss about.

      Next Dev-Chat

      It will happen on February 19, 2024 at 21:00 UTC in #BuddyPress.

      ⏰ 🔩

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