New pages slug do not support WordPress subpages

[slaFFik]

I'm setting up BuddyPress 12 from scratch locally, and it looks like I can't make BP pages (directories for members, activity, groups) as subpages to the newly created "Community" page (regular WP page), for example.

When I try to edit the Members slug - BP changes community/members to community-members.

There are no pages selection that used to be in BP where I could map BP "Members" pages to the WP "Members" pages (in the past it was possible to make it a directory as a subpage).

As a user, I'm not sure what to do - the BP plugin does not instruct me with anything.

When I created Members/Activity/Groups top-level pages in WP - they were not picked up by BP.
BP instead changed its directories slugs to members-2, groups-2, activity-2.

And because of that mismatch, I can't change the width of BP pages on the front-end using Site Editor.
It's too narrow in the 2024 default theme.

I'm using BP 12, WP 6.4.2, 2024 theme, no other plugins.

To me, it looks like a regression to BP 11.

[imath]

Thanks for your report @slaFFik.

Are you serious ?

I’m surprised as one of the BP Core committers, you’ve waited almost 6 months since beta1 to complain about what you consider a regression.

I have a quick solution for you, install and activate​BP Classic to find back the old flavor BuddyPress and be able to do WordPress page association / hierarchy. We not only built an ambitious release we also built a backwards compatibility plugin.

We’ve spend a lot of time (almost a year) to
build 12.0.0 and finally comply with WP Rewrites to let admin customize every BP URL chunks, so details you can fix with the Site Navigation Block from your Site Editor or custom CSS seems really a water drop into the ocean.

To me it’s a real progress and I’m proud of the work we accomplished.

I’m really disappointed with the way you shared your concerns without contributing to a line of code for years.

[slaFFik]

I'm a bit surprised by the reaction but I will try my best to provide more context and thoughts about almost each paragraph in your reply.

1) First of all, thank you for your (and other BP contributors) work on this big release. I have never belittled its importance or value.
I think I even showed my gratitude several times over the past years in BP slack channel, either via words or emojis. That's not much, I know, sorry about that.

2) I have not contributed to BP in any way for the past several years. You are right about that, and that's why I haven't filled any severity/priority/milestone fields. I simply not sure what, have little context, etc. After so many years off (like you rightfully said) - I'm a regular user having memories of how the older version of BP has worked in the past.
I didn't expect that I should not share my experience and frustration.

3) The ticket was created after one of other core contributors said me to do so after I asked the question in the Slack channel.
Isn't what this channel for?

4) To answer your first question:

Are you serious ?

Yes, I am, otherwise I wouldn't create the ticket.
Unfortunately, we have a misunderstanding here that I hope we will clarify.

5) I waited "almost 6 months since beta1 to complain" because 2 reasons: I'm not contributing to BuddyPress right now (for years, as you stated) and because I haven't used BuddyPress for years. I'm not sure how you expect me to provide feedback earlier with these prerequisites.
I didn't participate in v12 development, testing, etc. which is obvious for everyone, especially for you.

6) Your reply about "BP Classic" plugin: that's awesome, thank you for mentioning it.
Initially, I forgot about it, then I saw a notification in BP admin area, then I decided to go "vanilla-BuddyPress". And I provided my feedback based on vanilla BP and my past experience using older BP.

BTW, the notification that mentions BP Classic has no wording about pages structure, it just mentions 3rd plugins and themes (and I have none).

7) Regarding this part:

so details you can fix with the Site Navigation Block from your Site Editor or custom CSS seems really a water drop into the ocean.

This is a visual change, not the URL structure change.
From SEO perspective it might be beneficial to have a /community/ page with some intro content, and then /community/members/ with actual members directory, for example.

With regular pages I can easily do that. With WooCommerce pages (like, My Account, purchases, etc) I can do that. Same with EDD, and different LMS plugins.

BuddyPress (out of the box) doesn't allow me to do that - and that's fine if it's a mindful decision that was made.
I'm not aware of that decision, that's why I wrote about a regression - because I compare my previous experience with older BP with the new experience with new BP.

8) I would (humbly!) appreciated it if you could share with me what's wrong with "the way you shared your concerns". I fail to see what's wrong with it.
Mentioning the "regression"? I specifically said "to me", pointing to my personal opinion which may differ from yours, of course. And that's fine.

I think, if one removes my former BP contributions from the equation and absence of BP development activity, my ticket is fine.

[imath]

Since version 12.0.0 release, a month ago, I'm spending ​my days trying to answer as best as I can to user frustrations about specific setups like the one you're mentioning in your ticket although we extended the beta period to 5 months. Most of these users are friendly which helps, but some of them are just sharing their frustration just like you did. All this could have been avoided if these specific setups were tested during this beta period. So I'm very frustrated.

I thought you would choose a more constructive/friendly way to share this regression, taking some of your time to check the code to realize we're not using WordPress pages anymore and suggest an alternative way to satisfy your need. Instead you choose to put yourself in a user mode not considering all the other benefits of 12.0.0 (I heard using slugs in the same language than the site was also good for SEO) & only sharing critics & frustration: lack of documentation, wrong decisions.

Yes your ticket is fine, I agree it's a regression and I'll work on a fix. Too bad, although I've been in Rewrites for more than 2 years, I only read about this subpage thing a month after release, because I'm not sure this is something I will be able to fix on a maintenance release.

[slaFFik]

I respect your decisions, and as you are de facto the main maintainer of the plugin - alone or together with other contributors you have the full power to completely disregard my ticket as irrelevant. No hard feeling at all.

I understand your position and can understand your frustration after all the time and efforts spent on this huge rewrite. Obviously, I knew that it was not using WP pages logic under the hood, but it looks like I failed to properly express this in my ticket. I was improperly phrasing it and took a position that I usually take when reporting things to paid plugin owners.

BuddyPress is different, because no one is paid, unfortunately (I'd really love Automattic to sponsor you and others, at least part-time!).

If others do not complain about this specific case - you are more then welcome to just ignore it or resolve as wontfix until a critical number of users will start requesting the same thing. I do think that would actually be wise to do. Your (and other contributors) limited availability can be focused on more meaningful features/fixes that the majority of users will benefit from.

Side note: I still want to start using BP in a real world site, as a first-party citizen of the site (one of its main features if not THE one). And I started setting up the site locally to refresh some of my plugins (like BP Groups Extras).

[dcavins]

This is an interesting problem. I can imagine wanting to have your community area grouped together in a subsection of your site. Since BP components are hosted via a custom post type as of BP12 (​https://github.com/buddypress/buddypress/blob/master/src/bp-core/classes/class-bp-core.php#L342), it seems like we have a new advantage and could use the rewrite base/"front" to gather BP components.

Obviously, it's not written that way now, as @imath built the rewrite engine from scratch and we weren't considering this setup. However, the switch to using a custom post type opens up so many interesting and useful avenues and gives us control that the pages approach never did.

Thanks for your report!

[imath]

Thanks for your reply @slaFFik 😍 and sorry I was having a tough day.

I like the way @dcavins imagine how it can be built. Having a base prefix for BuddyPress directories like ˋcommunity` should actually be the default setup to limit slug conflicts with regular WP pages but our history for most cases was to be right behind the site domain, we even created a constant to skip the members slug when displaying a member 😱.

The challenge will be to mimic page hierarchy eg: displaying content when opening site.url/community for example. This part makes me believe we need to take more time and I feel the BP Block theme hierarchy we started to craft from the BuddyVibes should help us uses a specific template for this site.url/community content and customize it from the Site Editor, a bit like front pages for a group or a member.