#8590: Cache improvements. @dcavins have checked the rest of the buddyboss PR for potential complementary improvements and found out we had previously covered these on our own.
#8693: Site Members Invitations & configs using signups only. @dcavins has fixed the issue 💪👏.
#7614: Make sure the group members count routine is more accurate. We’ve talked about the edge case when an administrator adds a not yet active user to a group. We came to the conclusion we should sync counts when not active users finally log in for the first time. @dcavins has shared an interesting patch about it on the ticket. @im4th also shared a PR exploring a different strategy: taking in account not yet active users when the current user is the administrator. Please share your opinion about what you think is best on the ticket 🙏.
#8746: companion stylesheet for Twenty Twenty-Three. @im4th & @dcavins shared between themselves the work to achieve. During the week-end @im4th updated the PR and committed it to SVN trunk so that this can be done easily. He figured out most of issues were related to CSS color variables that were not used in TT3 compared to TT2. Doing a replacement of these seems to address most issues. Another look to it would be greatly appreciated 😍.
@espellcaste should commit the two tickets about the xProfile loop & the Messages BP REST API endpoint soon.
@im4th thinks the ticket about stopping using `$this` into `@param` docblocks can wait after the 11.0.0-beta1 version is released.
11.0.0 schedule reminder
First beta: November 8, 2022.
RC: December 1st, 2022.
Release: December 14, 2022.
10.5.0 & 10.6.0 Maintenance releases
Both versions have been released before WordPress 6.1. @im4th explained why he urgently took the decision to package 10.6.0 shortly after 10.5.0: replies into our support forums showed we needed to improve how we deal with Block only based Themes as the strategy used in 10.5.0 introduced a regression with Themes using block templates, although they are regular themes.
BP Attachments 1.0.0?
There’s still some work to achieve to be ready to package a very first version of this new BuddyPress Add-on:
Public Media directory,
Attaching media to Activity (when not using the BP Activity Block editor, as this part is already handled thanks to BP Attachments blocks).
Attaching media to Private Messages.
Including first private sharing options (with friends or group members).
@im4th hopes he’ll be able to publish a first version to the WP.org repository in early December so that it happens slightly before the 11.0.0 BuddyPress release.
Next Dev-Chat
It will happen this week on November 9 at 19:30 UTC in #BuddyPress. If you have specific points or ideas you want to discuss about, don’t hesitate to share them in comments.
We’ve updated the 11.0.0 release schedule, delaying first beta to November 8. But we still plan to package the final release on December 14. This means, we’ll have less time to test and package new betas. RC is slated to December 1st.
11.0.0 last tickets to fix
#8590: Cache improvements. @dcavins will work on including the improvements that are common with the buddyboss-platform.
#8693: Site Members Invitations & configs using signups only. @dcavins has a patch almost ready and he should be able to attach it to the ticket very soon.
#7614: Make sure the group members count routine is more accurate.
#8052 Should we stop using an activity meta to retrieve the new_blog_post activity action? @im4th will take the risk to decide 🤫
@im4th asked @espellcaste (once again 👮♂️) to try to make the list of the tickets he owns for 11.0.0 less bigger (selecting the tickets we absolutely need to include in 11.0.0 and punting others to a next release). Later after the chat, he said he will look into it during the coming week-end 👀
NB: although it would have been nice to include the global community visibility switch feature, we still need to discuss about the how: @im4th‘s personal opinion is “the later we make things invisible to not logged in users, the more issues we’ll be facing” which contrast with the idea of doing it just before rendering the BuddyPress content…
11.0.0 schedule reminder
First beta: October 19November 8, 2022.
RC: December 1st, 2022.
Release: December 14, 2022.
10.5.0 Maintenance release
The Twenty Twenty-Three companion stylesheet probably won’t be included into this maintenance release but should be included into the 11.0.0 one. @im4th confirmed he will package this maintenance release at the end of October and before WordPress 6.1 final release.
Next Dev-Chat
It will happen November 2 at 19:30 UTC in #BuddyPress. If you have specific points or ideas you want to discuss about, don’t hesitate to share them in comments.
We’ve started the meeting talking about the 17 replies our call for feedbacks got at the time of the meeting. There are great remarks, ideas and suggestions. Many thanks to the contributors who shared their very inspiring thoughts. We value them a lot 😍.
11.0.0 updates
#8590: Cache improvements. The initial PR made by @nickchomey has been committed. We had a discussion about whether to include the other improvements that were added by a buddyboss-platform team member (This ticket was firslty added as a PR to the buddyboss-platform GitHub repository). The majority of the team thinks as code is open source & GPL compatible, there’s no reason not to enjoy these improvements as long as we properly credit its author and the buddyboss-platform project.
#8734: we’ve discussed about @dcavins first patch about how to implement a basic “private community” feature. Although the patch is already doing a great job and is a very interesting first approach, @im4th agrees with @johnjamesjacoby : a better one would be to think of it as a community visibility “level”. As announced during the chat, @im4th had a closer look to the patch and started an alternative PR to suggest the introduction of a bp_read cap which led to interesting new feedbacks on the ticket. Don’t hesitate to test it, and contribute to the ticket’s discussion.
#4184: being able to exclude a list of users from the activity stream is now possible in Core. This commit closed the ticket.
@im4th reminded the team we had 2 weeks left before the date we initially scheduled 11.0.0 first beta and asked @espellcaste to try to make the list of the tickets he owns for 11.0.0 less bigger (selecting the tickets we absolutely need to include in 11.0.0 and punting others to a next release).
11.0.0 schedule reminder
First beta: October 19, 2022 🚨 that’s tomorrow!
Release: December 14, 2022.
10.5.0 Maintenance release
@im4th announced he will package this maintenance release shortly before WordPress 6.1 is released so that BuddyPress behaves the best way into the next WP Default theme (Twenty Twenty-Three). If he finds the time, he’d like to finish optimizing some CSS rules about it. Don’t hesitate to give him a hand contributing to this ticket.
Open floor
About the BuddyPress.org website @johnjamesjacoby really wants us to feel more comfortable iteratively improving it, and asked the team to think about how we want to contribute to it. @im4th volunteered to give John’s a hand and maybe try to work on the list of submitted tickets about the website. As @dcavins noted, some of their authors are first time contributors and it would be great to include their suggestions. @espellcaste wants to spend more time on developer.buddypress.org along with PHPDoc improvements.
The new & gorgeous BuddyPress theme has a name and a GitHub repository, don’t hesitate to contribute to it.
Next Dev-Chat
It will happen tomorrow on October 19 at 19:30 UTC in #BuddyPress. If you have specific points or ideas you want to discuss about, don’t hesitate to share them in comments, the agenda will be published shortly.
“Release Candidate” means that we believe this first version is ready for release! The next step if everything goes well after a last round of testing is to publish the plugin on the WordPress.org Plugins Directory.
Many thanks to the ones of you who contributed to testing 1.0.0-beta2 🥰. Please help us make sure we’re ready to make this important step: Test this release candidate.
If you haven’t tested 1.0.0-beta1 or 1.0.0-beta2, please have a look at this announcement post about it.
What’s new fixed in the first Release Candidate of BP Rewrites 1.0.0?
fixed
Make sure BP Rewrites loads when BuddyPress is network activated. See #32.
fixed
Avoid a fatal error when trying to access to a BP Core Nav too early. See #33.
Please note BP Rewrites requires BuddyPress 10.0.0. Make sure to download the bp-rewrites.zip file from the Plugin’s GitHub repository release page. Use the “Add new” WordPress Administration Plugin screen to upload the zip file. Finally check BuddyPress is activated before activating BP Rewrites.
Apart from a mysterious bug about the avatar crop step (we were not able to reproduce it so far), and a question about how to bring back legacy widgets, @vapvarun confirmed there was no alerts posted in our support forum.
@dcavins is using the 10.0.0 new features on several new sites and so far he hasn’t found any other issues.
10.2.0 Schedule
Unfortunately the notifications user cache issue was partly fixed in this release, see #8642. @im4th is in favor of packaging a new maintenance release soon to include the fix committed lately as well as other 10.0.0 regression issues that could have been fixed in the meantime. @vapvarun & @dcavins agreed about this plan 👉 expect 10.2.0 to be released asap!
Open floor
@im4th has been tested BuddyPress using PHP 8.1. He has found a lot of notices and improving our support to this PHP version will need some heavy changes about our PHPUnit testcases, see #8649.
Many thanks to the ones of you who contributed to testing 1.0.0-beta1 🥰, I can’t stress enough how this is really important for the BuddyPress project in order to migrate to the WordPress Rewrite API and let administrators have a full control over any BuddyPress URLs. If you haven’t tested 1.0.0-beta1, please have a look at this announcement post about it.
Please note BP Rewrites requires BuddyPress 10.0.0. Make sure to download the bp-rewrites.zip file from the Plugin’s GitHub repository release page. Use the “Add new” WordPress Administration Plugin screen to upload the zip file. Finally check BuddyPress is activated before activating BP Rewrites.
@im4th started the meeting asking if the team has seen something specific relative to the 10.0.0 upgrade. An issue about avatar upload was found there. So far none of us were able to reproduce the issue. @im4th wondered if it could be some users disabling the Backbone base UI in favor of the legacy one. He has tested since this situation and there is a bug preventing the avatar to be successfully uploaded in 10.0.0. It has been fixed by @oztaser into trunk and the 10.0 branch, see #8619.
@vapvarun shared about the issue rtMedia had with the Groups component, it has been fixed by the plugin authors since in plugin version 4.6.10. He also shared an issue about the Privacy page not being included into the registration form when it should. This issue is still under investigation.
Team agreed we need to package a maintenance release. We were planning to do it at the end of last week, but some other issues were reported on Trac so we prefered to delay a bit to include fix for these new issues. As soon as the last one will be fixed (See #8637), we’ll package 10.1.0 (probably later today or tomorrow).
BP Rewrites’ first beta
@im4th published an announcement post on this blog a few days ago. It’s important to prepare the plugin to be hosted on WordPress.org so that testing is made more widely. @oztaser already started to test the plugin and found some issues, fixed most of them. The one issue that is not fixed yet is the one that happens when you activate BP Rewrites before BuddyPress.
@dcavins shared his doubt about his plugins: “My doubt there is I know I’ve written plugins that run on bp_init . It will be interesting to see if they all blow up.”
That’s precisely the goal of the Backcompat mechanism the plugin is including which needs the most testing. @im4th said “The goal is to try to have a first version with the less bugs as possible to publish it on WordPress.org plugin directory and see how it goes when used more widely. Then wait a few BuddyPress releases like 2 or 3 to be sure it’s ok to merge it into Core”.
4 to 6 months to improve the BuddyPress’ documentation site
No major releases, all energy on docs!
@im4th
We’re all in favor of spending the energy we put in building a major release into improving the documentation site. And we’ll try to do it by organizing each other wednesdays (when we usually meet to talk about BuddyPress development) a “contributing to docs hour”. From 19:30 UTC to 20:00 UTC, we’ll discussed about potential maintenance releases and from 20:00 UTC to 21:00 UTC everyone is welcome to contribute to BuddyPress documentation.
@vapvarun said we need a direct link fromt this site to the official BuddyPress site, it has been added into the “Official site resources” sidebar widget ✅. He can also contribute with walkthrough videos.
We’re all very eager to start this new type of meetings and we really hope you’ll be a lot to join us.
If you haven’t read BP Rewrites’ Alpha announcement post, here’s the short version: using the WordPress Rewrite API means setting BuddyPress globals later than it happens today. It requires us to make sure BuddyPress plugins/themes using these globals too early can still get their values putting in place a backward compatibility mechanism. BP Rewrites 1.0.0-beta1 includes such a mechanism and informs the user about the too early call when the WP_DEBUG constant is set to true.
For instance, the following code:
function test_bp_current_component() {
printf( '<p>The current component is: <strong>%s</strong></p>', bp_current_component() );
}
add_action( 'bp_init', 'test_bp_current_component' );
Would generate the following notice before returning the BP global’s value:
There’s no secret: the only way to have enough confidence into this backward compatibility mechanism to start thinking of merging BP Rewrites into BuddyPress Core is to test, test and test again. The more we are to test, the more specific WP/BP configurations we test and the best we update/improve the backward compatibility mechanism so that end users won’t suffer from the Legacy URL Parser to WP Rewrite URL parser switch: anticipating is less painful than healing!
Is testing the BP Rewrites feature as a plugin safe for users?
I think so 😅. Let’s explain what happens when you activate and deactivate the BP Rewrites plugin.
Once activated, The plugin is editing the post type of the existing BuddyPress pages in favor of the buddypress post type. That’s why you don’t see the BuddyPress pages anymore (as long as the BP Rewrites plugin is active) into the corresponding WordPress Administation edit screen. The BuddyPress Pages settings screen is replaced by a BuddyPress URLs settings screen. This last screen is where you define custom slugs which will be saved as a post meta of the corresponding BuddyPress post type/page item. Then the BP Rewrites plugin is taking benefit from BuddyPress hooks/APIs to change BP Core’s behavior.
When you deactivate the plugin, buddypress post type’s items are switched back to regular pages and you get them back into the corresponding WordPress Administation edit screen. Post metas are still there in case you want to activate BP Rewrites back (this can happen when you’re testing another BuddyPress plugin). If you absolutely want to get rid of these post metas, you can delete the BuddyPress pages, create new ones and redo the page mapping from the BuddyPress Pages settings screen.
What are the benefits of using the WP Rewrite API to parse BuddyPress URLs?
BP’s custom URI parser (living mostly in bp_core_set_uri_globals()) is slow, error-prone, non-extensible, non-testable, and out of step with WP best practices.
Boone B. Gorges, 9 years ago 😱
As a result, using the WP Rewrite API should be faster, more reliable, extensible, testable and fully compliant with WP best practices 😉.
From a end user’s point of view
This would bring plain URLs compatibility. If you want to use BuddyPress today: using pretty permalinks is required. With BP Rewrites, this is no more the case, you can use BuddyPress with any type of permalinks.
Plain URL permalinks can be used when BP Rewrites is active!
For end users using pretty permalinks, they have full control of any BuddyPress URLs! Today regular users can only change the directory permalinks from the WordPress page editor and advanced users can use some specific constants to customize some other URLs. With BP Rewrites, you can customize ALL BuddyPress URLs including the Group creation steps. They can do it so that it’s more meaningful for their local members and I’ve heard doing so was best for SEO 😁. For instance a french user like me understands better this BP Rewrites generated URL:
site.url/membres/imath/profil/modifier-avatar/
than the current BuddyPress one:
site.url/members/imath/profile/change-avatar/
The BuddyPress URLs settings screen
This the place where you control all BuddyPress URLs. All can be a lot! In the above screenshot we only have the Activity and Members component active. Since BP Rewrites’ alpha version we’ve improved this screen to use the “site-health” screen accordion UI.
The “Directory” panels are a bit specific compared to others. In this panels you can also customize the directory titles. This was needed because we are not using the WordPress Page Editor when BP Rewrites is active to edit directory permalink or title.
Let’s say I want the URL to reach the User’s Profile Image change screen to be site.url/membres/username/profil/modifier-avatar/ instead of site.url/members/imath/profile/change-avatar/. I first need to make sure the Members Directory slug is set to membres.
Components like Members or Groups can have “single item” screens or member and group screens. For the Members component, you’ll first be able to customize the main (or primary) screens using the “Single Member primary views slugs” panel.
To carry on the example we started about customizing the User’s Profile Image change screen URL: in this panel, I’ll be able to change the profile part for profil.
For each subnav (or secondary) items components add to their main (or primary), you’ll be able to customize their slugs using the corresponding “Single Member component_name secondary views slugs” panel.
To finish my example about customizing the User’s Profile Image change screen URL: in the “Single Member Profile secondary views slugs” panel, I can edit change-avatar in favor of modifier-avatar and click on the “Save Settings” blue button to validate these changes. And here’s what happens when I reach site.url/membres/username/profil/modifier-avatar/:
It succesfully loads the Change Avatar screen 😅.
If you activated Groups, you can customize the Creation step views, the views every Member of a group can reach and the Group Admins specific views from the corresponding panels of the User Groups accordion section.
Let’s contribute to BuddyPress’ next way of parsing URLs: test BP Rewrites 1.0.0-beta1
Please note BP Rewrites requires BuddyPress 10.0.0. Make sure to download the bp-rewrites.zip file from the Plugin’s GitHub repository release page. Use the “Add new” WordPress Administration Plugin screen to upload the zip file. Finally check BuddyPress is activated before activating BP Rewrites.