Shortly before the dev chat started @dcavins shared his progress about the Site Membership Requests feature: he did preparative work needed for the feature by improving the BP Signup Class and fixed 2 tickets (#8540, #7938).
Thanks to a discussion between @vapvarun & @im4th about 2 BP plugins @vapvarun will soon make available on the WP plugins directory (about global BP Search and using the big G reCaptcha service to secure some parts of BuddyPress), @im4th will explore the possibility to add 2 new BP Blocks: 1 to perform global search, the other to display a member’s community statistics.
@espellcaste asked for a dev review about his approach on adding pagination to message threads (#8508) and thanked @im4th for the one he provided about #7614.
@espellcaste also introduced some very interesting functions to get a Group object, making it possible to use template functions outside of the Groups loop. You should have a look to this commit.
@im4th strongly encourages all BP Plugin/theme developers to give a test to this feature as a plugin to contribute to the next way BuddyPress will parse URLs.
Next Dev-Chat
It will happen on September 15 at 19:30 UTC and of course in #BuddyPress. If you have ideas or questions, feel free (and we are strongly encouraging you) to comment this summary to share them!
@im4th explained the work @dcavins, @johnjamesjacoby and him did about the security fix that was ported back to previous BuddyPress branches (from 9.0 to 2.9): 8 released were packaged in a night. Many thanks to David & John for their help during this amazing night!
10.0.0
@sbrajesh informed us he needed some more time to finish the first version of the BP relationships API.
We’ve been talking about the Group hierarchy as a possible feature for 10.0.0 @dcavins informed he had previously worked into this area from a custom plugin.
The first beta of 10.0.0 should happen on November 20. Target date for the final release is December ~24 🎅🏼
Open floor
We’ve been talking about the opportunity to move the dev-chat time but we will finally keep on meeting every other Wednesday at 19:30 UTC. Although it’s very late for @vapvarun & @sbrajesh, they are young enough 👶🏽👶🏾👶🏻 to handle it. Many thanks to them 🤝
We confirmed the BP Media component as one of the top features for 10.0.0. As there are many plugins playing into this area, we think packaging it into a separate plugin and make it easy to install from our BP Components Administration screen is the best way to go. Users will be able to choose whether they need these extra lines of code or not 😉.
The site membership requests feature to compliment the site membership invites was also confirmed. @dcavins already started working on it suggesting improvements to our BP Signup API (see #8450).
Open floor
We also talked about adding the Block based activity post form we’ve been working on from the BP Blocks plugin.
@im4th thinks he had progressed enough about the BP Rewrites plugin to completely open it to any contributors. He has published a post about it on this blog a few days after the dev chat.
August 18 Dev-Chat Agenda
During last meeting some of us couldn’t attend, so let’s take some more time to talk about other possible top features to confirm for 10.0.0.
Let’s move the time of our every other Wednesday meeting so that it’s not happening so late for Asia/Pacific timezones.
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 😍.
PS: the link is Activate on non mulitiste configs.
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.php files, 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 👌
Download spike for it happened on July 20 and reached ~33.400 downloads 📈 🎈.
Nothing major about it into Support forums, so @imath was able to quote @vapvarun saying: “We did not break anything big” 😅.
This BP Blocks focused (& short time framed) release was an interesting experience, thanks to a discussion launched by @johnjamesjacoby a bit before the dev chat, we were able to discuss about the benefits of working from a “feature as a plugin” GitHub repository. In short: it can save us some time ⏱, but bringing back code into our Trac is making us feel safer from being completely GitHub dependent.
10.0.0 is a magic number!
10 is after 9, and we all feel we need to make this release a bit specific.
@sbrajesh has been working on the BP Relationship API and is confident he’ll be able to share a first alpha around August 18. 💪
Below are our first thoughts about 10.0.0:
A “regular” development cycle, Christmas🎄 as a release date could be a good idea!
It’s time BuddyPress has a Media Component, Releasing 10.0.0 once it’s ready was suggested 😇
Using rewrites to parse BP URLs might be a bit too early but we’ll have a “feature as a plugin” really soon to check what it means in terms of back compatibility with Plugins using the BP Legacy URL parser.
Carry on improving the BP REST API by using it more frequently into BP features (like we did for BP Blocks in 9.0.0)
A new great BP Theme seems difficult to achieve, unless we have a lot of interested contributors jumping in!
A site membership requests feature to compliment the site membership invites.
Nothing’s set in stone yet! Don’t hesitate to show your support for one (or more) of the above points to help us decide. And if you have great ideas, be there to share them with us during our next development meeting 👇
August 4 Dev-Chat Agenda
We had 2 weeks to think about possible features for 10.0.0, let’s decide about the ones we’ll work on during this magically numbered release cycle 🪄.
I have the great honnor to introduce you to “Mico” our latest major release. It’s ready for the new WordPress 5.8 Widget Block Editor. It was quite a challenge when we decided to build this release about a bit more than a month ago. We used a short time frame development cycle and we did it! I’m very proud of the work we’ve accomplished together: congrats to all the development team members, the contributors and the polyglots team members.
Have fun with the new 10 BP Blocks included into this release 🍕
We really need you to quickly test this release candidate as we plan to release it just before WordPress 5.8. If you want to test the 10 new Widget Blocks into the new Widget Block Editor, you’ll need WordPress 5.8-RC3 💪
Following the discussion we had during June 23 meeting about the frequently requested Follow feature, and a very interesting discussion between @sbrajesh, @espellcastewe and @johnjamesjacoby, we decided to improvise a new Dev Chat about a possible larger scope about it. We shared our views about building a wider vision for “relationship types” in BuddyPress. A new API that would firstly be used for the Follow feature, but could also be used for potential other needs: user likes, improved user favorites, blocking users, what may come to our mind in the future!
@sbrajesh will lead this new project using the “feature as a plugin” model like WordPress does from a BuddyPress GitHub repository. If you’re interested in contributing to this project, please “raise your hand” commenting this summary.
July 7 regular dev-chat
@im4th starts with an apology: unlike what was scheduled (July 8), we were not able to release the 9.0.0 first beta so far. Sorry about it.
9.0.0 🎯
We’ve migrated 90% of Widgets as Block Widgets from the GitHub repository we use to build BuddyPress blocks. We also improved some BP REST API endpoints and we’re on our way to include a new endpoint to deal with Sitewide Notices. BP Block Widgets have been built on 2 principles: use the BP REST API every time it’s possible and use Modern JavaScript on front-end and the Widget/Post Block Editor’s APIs (mainly built on top of React.JS) on back-end.
@dcavins has made great progress about the Sitewide Notices Block Widget (👉 the last one to reach 100%) and about the corresponding REST API Endpoints. @espellcaste gave great advices about the BP REST API to speed up the process.
We also talked about directly packaging a Release Candidate without doing a Beta release. As the 9.0.0 development cycle is focused on migrating Widgets as Blocks, we have a very limited risk of messing with other parts of BuddyPress. @im4th said he’ll work on merging the BP Blocks code into BuddyPress core and will try to find the time to quickly build a Beta Release and some time after the Release Candidate (he hates when he doesn’t do what he has written he would do).
We finally talked about the great work @vapvarun has done building a test drive to host the BuddyPress code reference. The goal is to make it available asap and before the end of the year here. The main difficulty is to generate the documentation using the WP CLI parser command directly from the server (10 minutes). @im4th wondered if this could be achieved using the WP import/export tool (the documentation plugin is using custom post types). This is an approach we’ll try to test to avoid possible downtimes of the BuddyPress.org network.
9.0.0 schedule
Beta: July ? 🤔
RC: July 12 to 14.
Final: July 16 to 19.
Next Dev-Chat
It will happen on July 21 at 19:30 UTC and of course in #BuddyPress. If you have ideas or questions, feel free (and we are strongly encouraging you) to comment this summary to share them!
Additional note about meetings during 9.0.0 development cycle
As we are running a short development cycle, @im4th will be available every Wednesday at 19:30 UTC in #BuddyPress for an hour or more time if needed. Don’t hesitate to ping him (@imath) for help or inputs about contributing to this version of BuddyPress.
