BP Rewrites 1.0.0 Release Candidate

Hi BuddyPress contributors!

“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.

Props 💚

@adiloztaser@eha1, @imath.

Let’s contribute to BuddyPress’ next way of parsing URLs: test the first release candidate of BP Rewrites 1.0.0.

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.

Happy testing 🙏 😍 🤝

#10-0-0, #feature-as-a-plugin, #rewrites

BP Rewrites 1.0.0-beta2

Hi BuddyPress contributors!

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.

Thanks a lot to Sarah Gooding who wrote this great post about BP Rewrites’ first beta on WP Tavern. We’re very thankful you spread the news to the WordPress world.

What’s new fixed in 1.0.0-beta2

fixed
Anticipate WordPress 6.0 changes about the WP Request to make sure BP Ajax requests are using the Rewrite API. See #31.
fixed
Make sure BuddyPress is active before trying to change anything into the site’s set up. See #29.
fixed
Remove the BP Pages settings tab to prevent any rewrite rule errors. See #27.
fixed
Fix bpRewritesUI() function call when readyState is not fired. See #26.
fixed
Remove superfluous parameters on remove_filter() calls. See #25.

Props 💚

@adiloztaser@imath.

Let’s contribute to BuddyPress’ next way of parsing URLs: test BP Rewrites 1.0.0-beta2

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.

Happy testing 🙏 😍 🤝

#10-0-0, #feature-as-a-plugin, #rewrites

Using PR to share your patches on BuddyPress Trac

Thanks to Dion Hulse (@dd32), it’s now easier to share patch directly from your BuddyPress GitHub fork to a specific BuddyPress Trac ticket 🙌. It’s a great improvement and I believe it can potentially attract more people to contribute to BuddyPress code.

How does it work?

First if you haven’t created your BuddyPress fork on GitHub, log in to your GitHub account, head over to the https://github.com/buddypress/buddypress.git repository and click on the “Fork” button !

You’ll get a new repository on your GitHub account to work from to contribute to BuddyPress, here’s mine for instance: https://github.com/imath/buddypress.git

Clone it locally, create a new branch to add your changes, commit and push your changes on your branch, go to your fork’s page on GitHub and click on the link to create a Pull Request. You’ll be directed to the page where you’ll be able to link your PR to an existing BuddyPress Trac ticket.

Find the <!-- insert a link to the BuddyPress Trac ticket here --> text and replace it with the Trac Ticket link, for example https://buddypress.trac.wordpress.org/ticket/8647. Of course, if the ticket doesn’t exist yet, you can always create a new one from there.

NB: BuddyPress core committers, do not merge PRs from the BuddyPress GitHub repository, the feature’s goal is to ease code review, we still need to commit changes from our SVN repository.

Click on the “Create pull request” green button and go to your BuddyPress Trac ticket’s page.

As shown in the above screenshot, your pull request will be included into the “Pull Requests” section of the corresponding Trac Ticket. From there BuddyPress contributors can enjoy the GitHub code review features clicking on the View PR’s link or get the patch using the “View patch” link.

To get more information about this feature which is also available on the WordPress Trac, you can read this documentation page of the WordPress Contributor’s handbook.

Getting the most out of this feature

As you may have noticed, we also have some information about automatic checks applied to pull requests. We currently haven’t set these from a GitHub action, but it would be interesting to include PHP Unit tests and why not WordPress code standards checks, see #7228.

#github, #trac

BP Rewrites’ first beta

Hi BuddyPress contributors!

Do you remember when I’ve first introduced you to this feature as a plugin on August 2021? It’s now time we take a new step about it: prepare the plugin to be hosted on the WordPress.org plugin directory to encourage massive testing!

Why do we need massive testing?

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?

From a developer’s point of view

As @boonebgorges wrote into this ticket first lines:

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.

Happy testing 🏈 🐏 🐅

#10-0-0, #feature-as-a-plugin, #rewrites

BP Dev-Chat Summary : February 16, 2022.

10.1.0 maintenance release

@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.

Next Dev-Chat

It will happen on March 02 at 19:30 UTC in #BuddyPress.

First Contributing-to-docs-hour

It will happen on March 02 at 20:00 UTC in #BuddyPress

#10-0-0, #dev-chat, #summary

BP Dev-Chat Agenda February 2, 2022

Hi!

Note : we haven’t published a dev-chat summary for January 19 meeting, as we mainly worked on fixing some last minute issues to prepare the 10.0.0 stable version (which was released on January 20 around 18:40 UTC).

Our development meeting will happen on February 2 at 19:30 UTC and of course in #BuddyPress. Here’s our agenda:

  • 10.0.0 feedbacks & results
  • 10.1.0 release schedule
  • Organizing our next 4 to 6 months documentation effort

If you have specific/additional points you need to discuss about, please share them into the comments area of this post.

👋

#10-0-0, #agenda, #buddypress, #dev-chat, #documentation

Legacy Widgets in BuddyPress 10.0.0

BuddyPress 9.0.0 main focus was to build a new BP Block Widget for each existing BP Legacy Widget. Starting in 10.0.0, BuddyPress is no more loading Legacy Widgets by default. It only keeps on loading them if:

  • Your WordPress version is < 5.8.
  • Your active theme doesn’t support Block Wigdets.
  • You activated the Classic Widgets plugin.
  • You decided to opt-out the new Block Widget Editor using the use_widgets_block_editor filter.

If your WordPress version is >= 5.8 and your active theme supports Block Widgets and you haven’t opted-out the Block Widget Editor using the Classic Widgets plugin or the filter but still want BuddyPress to load its Legacy Widget, you can do so using this filter:

// This filter makes sure BP Legacy Widgets will be loaded.
add_filter( 'bp_core_retain_legacy_widgets', '__return_true' );

#10-0-0, #widgets

More engaging logging activities in 10.0.0

By default, BuddyPress has had an elementary style for secondary activities for a long time, now it’s time to make it more attractive.

Default secondary BuddyPress activities

These simple activities about specific user interactions or events (e.g., you joined a group) are more visually attractive to improve user engagement in your community. The most impressive new activity is generated when a user updates their profile photo; it will include the profile photo that spurred the creation of the activity item, even if it has been updated.

New Interactive activities

The new update also saves your avatar change timeline. For example, when a user uploads a new avatar, the previously uploaded one is moved inside a history subdirectory of the user’s avatar directory. This avatar’s history is then available for the new_avatar activities to display the avatar the user had when these were published.

We’ve added a new « recycle » tab inside the change profile photo UI to manage and delete old uploaded avatars.

Thanks to this recycle tab, users can manage their avatar’s history. They can choose to:

  • Reuse a previously uploaded avatar as their current profile photo,
  • Permanently delete an avatar from their avatars history.

It also deletes the activity when a historical avatar has been deleted. It also covered avoiding multiple new_avatar activities per hour. You can change your avatar numerous times in a short time frame, and it will use the last avatar for the activity.

The new functions added for these updates

  • bp_attachments_list_directory_files() returns a list of file objects contained into the directory thanks to its absolute path passed as the function argument.
  • bp_attachments_list_directory_files_recursively() returns a list of file objects contained into the directory and its subdirectories thanks to the directory absolute path passed as the function argument.
  • bp_avatar_get_version() can be used to get a version of an avatar according to its timestamp. Since [13175] the BP_Attachment_Avatar class is using a timestamp inside the avatar file name instead of a generated unique string (uniqid()), this change allows us to request avatars according to the timestamp included into their names.
  • bp_avatar_get_avatars_history() can be used to get the file objects list of previously uploaded avatars.
  • bp_activity_type_part() function to return the name of the activity type template part.
  • edit the bp_activity_has_content() function to generate a richer content for activity types supporting the feature. For such activities the $activities_template global is extended adding a generated_content property to each activity in the loop having a type supporting the “generated-content” feature.
  • Introduce the bp_activity_generated_content_part() template tag which use the current activity generated_content property to output the requested information passed as the function parameter.

The new template tags introduced with current update:

  • bp_activity_the_content_body() to bypass the activity types template parts look up or to use this tag inside an activity types template part.
  • bp_activity_has_generated_content_part() is checking if the property of a generated content exists
  • bp_activity_generated_content_part() is outputing the the property of a generated content
  • bp_activity_get_generated_content_part() is returning the output after making sure it has been sanitized.

The new update will need theme developers to update the buddypress/activity/entry.php template if they have overridden it inside their themes.

PS: all screenshots were made using the BuddyX theme (WordPress 5.8.2 ).

#10-0-0, #activity

BP Dev-Chat Summary : January 5, 2022.

Some complementary explanations about the 9.2.0 release

@im4th started the meeting saying some words about this minor version which was released on January 3rd. The download spike (~39K downloads) was reached on January 4th. He apologized about the fact he took the decision quite in a rush without discussing about it during a dev-chat. He explained he wanted to have the BP Search Block released in the WordPress.org directory the soonest so that he could focus on the BP Rewrites feature as a plugin for the coming 15 days. 9.2.0 is including a change needed by the BP Search Block (activity search redirection support).

About BP Rewrites, @johnjamesjacoby wants to dive deeper into the plugin. @im4th said it was ok to delay its release after BuddyPress 10.0.0, if needed, as it’s a BP plugin. He also shared his opinion about a BP Core potential merge.

I believe it needs to stay an add-on for at least 2 major BuddyPress releases, there are too many plugins we need to make sure they still behave right before thinking about merging it into BP Core.

imath

Finishing the 10.0.0 Hello BuddyPress screen

If you’ve started testing the RC1 release (if not, do it now!), you already saw it has been finished (See #8605). During the chat, we’ve decided about the 10.0.0 features we want to highlight into this screen:

We also decided to release RC1 as soon as we could (it happened 2 days later) as we already postponed twice our schedule.

Last 10.0.0 schedule

  • 10.0.0-RC: January 7, 2022 🏁 ✅
  • 10.0.0 stable: January 17, 2022 🎯

Open floor

@dcavins has been using the 10.0.0-beta2 release on some decent traffic sites and it seems to be working well 💪 😎

@vapvarun brought up to our attention this support forum topic. Our discussion about it lead to an important decision for our next major release : if ! is_buddypress() no more BP Template Pack CSS/JS. @imath also wishes we use a more modular approach for our JavaScript assets as well as less/no dependency to jQuery.

Next Dev-Chat

It will happen on January 19 at 19:30 UTC in #BuddyPress. We should be able to check the first feedbacks about 10.0.0 😉

#10-0-0, #dev-chat, #summary

BP Dev-Chat Summary : December 15, 2021.

10.0.0-beta1 1st feedbacks

A theme related issue was posted into our support topic @dcavins gave some explanations of possible reasons for this issue and the reporter said he would ask the premium theme authors for support.

10.0.0 remaining tickets

  • @vapvarun will soon post a patch about #7540.
  • During the chat @im4th said he would work on #8088, #8589 and #8474. He fixed the 2 first and committed fixes about the third.
  • About #8604 @dcavins agreed suggested changes were making sense. The patch still needs to be built.

10.0.0 stable release tasks repartition

@dcavins wrote a codex page about alternative registration workflows and volunteered to take in charge the credits list and part of the « Hello BuddyPress 10.0.0 » screen.

10.0.0 schedule

  • 10.0.0-RC: TBD 👈
  • 10.0.0 stable: January 5, 2022 🎯

Next Dev-Chat

It will happen next week on December 22 at 19:30 UTC in #BuddyPress.

#10-0-0, #dev-chat, #summary