Hello, here‘s the third post of our series about the new direction we plan to take regarding plugin maintenance and evolutions. In our first post we shared with you our new purpose « Get together safely, in your own way, in WordPress »; in our second post we talked about how we think we can better organize the BuddyPress plugin. Let’s see how the feedback you shared with us here & there contributed to the BuddyPress features roadmap we‘re thinking about tackling in 2023 & 2024.
Key feedbacks about BuddyPress features.
- « Media Attachments »
- « Private access to members component »
- « Private membership management »
- « Private conversations revamped to look more like private chats »
- « Blocks for all BuddyPress components »
- « Follow Feature »
- « Some kind of connection with Woocommerce as much as possible »
- « Privacy, social networking, and following features are all missing »
- « Likes / Reactions, media posting, hashtags, user activity as main activity page, suggestions like who to befriend and what groups to join »
- « A complete Groups hierarchy with (multiple) parents, siblings and child groups »
Have I told you, we absolutely need to build some privacy features 🔐?
Considering the WP Blocks API, I’ve personally been following the great work the Gutenberg team has accomplished since WordCamp Europe 2017. I was in the huge room when Matt announced the feature as a plugin was ready to be tested; it’s a game changer and I’m totally in favor of going full blocks in BuddyPress.
I believe, as a WordPress plugin, we need to be exemplary, making sure BuddyPress is playing as nicely as possible with the Gutenberg project improvements progressively included in WordPress Core.
We already have a dozen of blocks available across our components, and, although we’re not currently fully enjoying Block templates, we have made sure you can safely activate Block themes and carry on having your community content injected into this next generation of templates thanks to our dear BP Theme Compatibility API.
We’ll make 2 or 3 more significant steps in 2023 in the « Blocks » direction with our Attachment Add-on, an Activity editor based on the WP Block API, and, if we can increase the time & energy contributors can dedicate to BuddyPress, we’ll build a brand new & modern BuddyPress block theme 🎨 before the end of next year.
This last point is a very important step as you’ll be able to customize your community pages within the Site Editor of your WordPress dashboard. I’m convinced the faster we « blockify » BuddyPress, the sooner we’ll differentiate ourselves fromour competitors. If you’re a theme designer or interested in theming community sites, join us to explore new territory: contribute to the next BuddyPress Block theme.
About the follow, likes or a better performing favorite features, the team is 💯 interested about being able to provide a solid API to establish relationships between a wide variety of objects (users,posts, activities, groups, etc…), we thought we could have put something together about it to implement a follow functionality but unfortunately the project leader had no available time to make it happen. Who’s volunteering to take this over?
More globally, I can ensure you all, we’re fully open to building great new features 🤩. We can provide tools, expertise, code reviews or simply code, experience, etc, but we do need a lot more contributor time, energy & motivation (in particular we need newcomers).
Using our new way of BuddyPressing: a more compact Core plugin and external Add-ons, we have the freedom to code without overthinking about whether it should be included into Core or not.
Our next post of this series will go deeper into the BuddyPress user interfaces (theme / administration / mobile) your feedback confirmed we should improve.
Props: many thanks to @dcavins for his review 😍
[…] Visit Direct Link […]
[…] @im4th & @dcavins talked about the third post of this series: @dcavins did the review process and it’s now available on BuddyPress.org. […]
Some good ideas and some bad ones
Media attachments is great as a standard is required and Bp attachments seems a good start but most features built so far are reliant on JavaScript. This is terrible practice. Also the functionality is based on the file system. A proper database api is essential eg BP_attachment_query
Privacy social networking you are doing it, it’s a mistake. Privacy is not a binary thing. Leave it in plugin land. You’ll do it anyway 🙁
Blocks for components, seems logical
Follow – please don’t build it. Just work on a proper relationships api, that would allow others to build it (and much more) elegantly. A relationships api is a great idea
Likes / Reactions, hashtags, suggestions etc. please don’t bother. This is plugin land, just improve the apis. Eg if the activities supported taxonomies a plugin dev could elegantly create taxonomies for hashtags, visibility etc
Group hierarchies – makes sense but I can’t see it being highly useful. Custom group taxonomies are desperately needed and custom group statuses are also more urgent. Heck in in terms of groups it would be nice if every group management feature was available on the front end but strangely there are still many things you can only do on the backend.
Hi Peter,
Thanks a lot for your comment and feedback.
As I already told you somewhere in Track, “Plugin land” is a concept I have difficulties to understand as BuddyPress is a WordPress plugin 😅, so to me “Plugin land” is BuddyPress land.
All your concerns are Plugin author ones, I understand these, but i doubt we can expect Plugin authors to freely satisfy all BuddyPress end users need: actively maintained features. Our new way of BuddyPressing is the direction we will take:
– shrinking one step at a time BuddyPress to its Core features,
– moving optional components or new ones into external Add-ons,
– and putting backward compatibility inside the BP Classic plugin
This way, Plugin authors can challenge all BuddyPress Add-ons, and offer End users their alternatives. If some features like the visibility one (the Privacy we’ll do anyway) will be in core we’ll put the filters in place so that a Plugin can override it and offer an alternative to it.
Let’s have End users need in mind first: try to satisfy it and give them as much choices as possible with one principle in mind: the freedom to code any features we think are important for the BuddyPress end users.