Thanks in advance to the contributors who will test this BuddyPress Add-on and help BuddyPress Core to migrate its legacy URL parser in favor of the WordPress Rewrite API doing so!
Tag Archives: rewrites
BP Rewrites 1.3.0 is available
Hi!
A new maintenance release of the BuddyPress add-on giving you the power to control every BuddyPress generated URL is now ready for download. Please upgrade.
BP Rewrites 1.2.0 is available
Hi!
A new maintenance release of the BuddyPress add-on giving you the power to control every BuddyPress generated URL is now ready for download. Please upgrade.
BP Rewrites 1.1.0 is available
Hi!
The first maintenance release of the BuddyPress add-on giving you the power to control every BuddyPress generated URL is now ready for download. Please upgrade.
BP Rewrites 1.1.0 Maintenance Release
It’s now easier to test the BP Rewrites add-on
Hi everyone,
We’ve just deployed the BP Rewrites add-on on the official WordPress Plugin directory! Please take a few minutes to read the announcement post on BuddyPress.org and start testing it massively. Our goal is to improve it together and merge it into BuddyPress core when we all feel it’s ready.
Thanks in advance for your help and contributions.
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 💚
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 🙏 😍 🤝
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
fixed
Remove superfluous parameters on
remove_filter() calls. See #25.Props 💚
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 🙏 😍 🤝
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
Boone B. Gorges, 9 years ago 😱bp_core_set_uri_globals()) is slow, error-prone, non-extensible, non-testable, and out of step with WP best practices.
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.
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 🏈 🐏 🐅
BP Rewrites, let’s contribute to the next way BuddyPress will parse URLs
Hi BuddyPress Contributors!
Using the WordPress Rewrite API to replace our Legacy URL parser is a challenge we’ve been trying to achieve for 8 years.
It’s a pretty massive and complex change because BuddyPress plugins/themes and even BuddyPress Core 😬 got used to directly write URLs by adding chunks after a directory, a single member item or a single group item permalink.
Today, our Legacy URL parser is analyzing these URL chunks to globally set variables (eg: buddypress()->current_action) we can check using specific functions (eg: bp_current_action()) to decide how the plugin should behave.
As it’s working mostly fine, we’ve been postponing this change for a while which is making it harder today to actually migrate to the WordPress Rewrite API. As I often write when announcing a release candidate on our official website:
“Release Candidate” means that we believe the new version is ready for release, but with more than 200,000 active installs, hundreds of BuddyPress plugins and Thousands of WordPress themes, it’s possible something was missed. BuddyPress ?.0.0 is slated for release on Month dd, YYYY and we need your help to get there.
Not to mention the potential customizations advanced users can do using specific constants, specific WordPress configurations, or by adding custom code into the mu-plugins directory or inside a bp-custom.php file.
To safely make this change: we need to have enough confidence into the backward compatibility mechanism we’ll put in place. There’s no secret: the only way to reach this level of confidence is to test, test and test again. The more we are to test and the sooner we do these tests during the development cycle, the better it is for end users, plugin developers, theme designers, BP support team, BP development team: anticipating is less painful than healing!
Your contribution is the key to the success of our challenge.
Why migrating? isn’t the Legacy URL parser doing a good job?
It does! But we believe using the WP Rewrite API will improve users BuddyPress experience making it possible to directly use the plugin without having to change the permalink structure if the site is using plain permalinks and making it a piece of cake to customize URL slugs. Moreover, we think following WordPress best practices in this area is important for our project and will help us increase our “forward compatibility” with the WordPress Full Site Editing feature.
BP Rewrites is a “Feature as a plugin”
We think using the “feature as a plugin” mode can:
- make things easier for you (actually us all!) to do this huge amount of testing,
- accelerate the development of the code needed to achieve this “WP Rewrites” migration.
1. Once the team will be happy about our improvements on the feature, we’ll make BP Rewrites available from the WordPress.org Plugins directory. To have it running on your site, you’ll simply need to install & activate it like any other plugin. As soon as you deactivate BP Rewrites, it puts everything back to the state it was before its activation.
2. Working on the 9.0.0 release mainly from the BP Blocks GitHub repository showed us it was accelerating our development process. Let’s hope it will be the same for BP Rewrites. We haven’t received more contributions to BP Blocks from GitHub users, but at the very list we make this possible and everyone’s very welcome to contribute to code!
You can already help us with tests & code!
If you’re comfortable with using GitHub and can easily put up a local development environment, or install the BuddyPress one (it requires Docker) or have already one in place, feel free to start contributing to BP Rewrites 😍.
Please take a few minutes to read these contributor guidelines to quickly get started.
What happens once BP Rewrites is activated?
As soon as you activate BP Rewrites, BuddyPress is using the WordPress Rewrite API, you have no other installation step to achieve. The Legacy directory pages are automatically migrated as specific buddypress custom post type items (let’s call it “BuddyPress directory” post type) used to maintain backward compatibility and make it possible to revert to the BP Legacy URL parser simply by deactivating the BP Rewrites plugin.
Without BP Rewrites 
With BP Rewrites
If you included BuddyPress pages into a WordPress menu, the menu will automatically be updated to use the “BuddyPress directory” post type.
Without BP Rewrites 
With BP Rewrites
With BP Rewrites, there’s no need to associate BP Directories with WordPress Pages anymore, as a result the BuddyPress Pages settings administration screen is replaced by the BuddyPress URLs settings administration screen.
Without BP Rewrites 
With BP Rewrites
Customizing slugs is a piece of cake!
If you go to this new Settings > BuddyPress > URLs administration screen you’ll be able to customize the BuddyPress URL slugs very easily. In the following example I translated the default BuddyPress slugs by their french meaning.
Under the hood changes
To maintain backward compatibility we are still setting global variables (eg: buddypress()->current_action), so using the specific functions (eg: bp_current_action()) to decide about the behavior of your plugin/theme/custom code can still be done. The only difference is you need to wait a bit longer during the WordPress loading page process to use these functions.
The BP Legacy URL parser is making them available at the 'bp_init' hook (which is very early!) while the BP Rewrite URL parser is now making them available once the WP Query has been parsed: at the 'bp_parse_query' hook. The same “delay” applies to the BuddyPress Components navigation set up, the BuddyPress canonical stack set up and the BuddyPress document title set up.
What still needs to be done?
- At the risk of being very redundant, we all have to test, test and test again!
- We also need to decide about how we can deal with the bad habit we all took when writing BuddyPress URLs into our code base: rather than directly writing URLs by adding chunks after a directory, a single member item or a single group item permalink, we need to introduce Core functions to make sure the custom slugs will be taken in account everywhere. If you look at the code inside the BP Rewrites
src/bp-{component-id}/bp-{component-id}-template.phpfiles, you’ll see there’s a huge work in front of us, and I’m pretty sure the first alpha version of BP Rewrites missed some “Legacy built” URLs. - We’ll probably need to deprecate a lot of functions to achieve the previous point.
- We need to write PHP Unit Tests !!!
- We need to document how Plugins/Themes/Custom codes can use our BP Rewrite API.
- I’m probably missing some points, so don’t hesitate to add your thoughts in comments 👌
Thanks in advance for your contributions 😍
BP Dev Updates 