Skip to:
Content

BuddyPress.org

Opened 9 months ago

Closed 6 weeks ago

#9063 closed defect (bug) (fixed)

New pages slug do not support WordPress subpages

Reported by: slaffik's profile slaFFik Owned by: imath's profile imath
Milestone: 15.0.0 Priority: normal
Severity: normal Version: 12.0.0
Component: Core Keywords: needs-docs dev-feedback 2nd-opinion has-patch
Cc:

Description

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.

Change History (27)

#1 @imath
9 months ago

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

#2 @slaFFik
9 months ago

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.

#3 @imath
9 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 14.0.0

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.

#4 @slaFFik
9 months ago

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

#5 @dcavins
9 months ago

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!

#6 @imath
9 months ago

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.

This ticket was mentioned in Slack in #buddypress by espellcaste. View the logs.


8 months ago

#8 @imath
8 months ago

  • Owner set to imath
  • Status changed from new to assigned

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


7 months ago

#10 @imath
4 months ago

  • Milestone changed from 14.0.0 to Up Next

Currently submerged, I'm sorry we'll need to wait a bit longer.

#11 @imath
3 months ago

  • Milestone changed from Up Next to 15.0.0

#12 @imath
2 months ago

  • Keywords needs-docs dev-feedback 2nd-opinion added; needs-patch removed

Hi @slaFFik

I believe you can already get what you need using the current state of the Rewrites API.

You simply need to use these kind of filters:

function prepend_community_slug( $root_slug ) {
	return 'community/' . $root_slug;
}
add_filter( 'bp_activity_root_slug', 'prepend_community_slug' );
add_filter( 'bp_members_root_slug', 'prepend_community_slug' );
add_filter( 'bp_groups_root_slug', 'prepend_community_slug' );

Refresh your permalinks.

Create a WordPress page like "Community", making sure it has the community slug, then use a WP Nav Menu or a Site Editor Navigation to build your "Community Submenu" with BuddyPress directories.

I'm not sure we need to do anything particular to the URLs settings tab UI like adding an option to store the slug to prepend to the Component's root one.

A new documentation page into this area https://github.com/buddypress/buddypress/tree/master/docs/user/advanced explaining the above steps should be enough imho.

What do you think @slaFFik @dcavins @emaralive & @vapvarun ?

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


8 weeks ago

This ticket was mentioned in PR #364 on buddypress/buddypress by @imath.


6 weeks ago
#14

  • Keywords has-patch added

Introduce 2 new filterable functions to get register/activate root slugs. These 2 functions are used to set rewrite rules and permastructs. Using the filter it is now possible to prepend a custom-slug/ to the generated rewrite rules and permastruct.

This was the only missing thing to be able to prepend a custom-slug/ to all directory/specific page root slugs.

Trac ticket: https://buddypress.trac.wordpress.org/ticket/9063

renatonascalves commented on PR #364:


6 weeks ago
#15

Some unit tests would be great.

@imath commented on PR #364:


6 weeks ago
#16

Interesting:
The job running on runner GitHub Actions 20 has exceeded the maximum execution time of 10 minutes.

So we now have 10 minutes per job @renatonascalves should we split the Object cache job ?
Eg: 1 for multisite and the other for regular sites or 1 for Memcache and the other one for Redis ?

renatonascalves commented on PR #364:


6 weeks ago
#17

I do have some changes to apply to the matrix here #362 because it was going overboard.

renatonascalves commented on PR #364:


6 weeks ago
#19

Changes applied at #362

renatonascalves commented on PR #364:


6 weeks ago
#20

The job running on runner GitHub Actions 20 has exceeded the maximum execution time of 10 minutes.

@imath By the way, I found this interesting. The "Setup PHP" action took 7 minutes for some runs. Which is uncommon. So the issue was not about the object cache services. I think some service took longer than usual for some reason. ¯\_(ツ)_/¯

https://github.com/user-attachments/assets/e9045b77-4231-4012-8d40-5ec14b717a89

https://github.com/buddypress/buddypress/actions/runs/10564481957/job/29267558681

@imath commented on PR #364:


6 weeks ago
#21

I'll go with strpos as https://www.php.net/manual/en/function.str-contains.php is only available in PHP 8.0 and up 😨

renatonascalves commented on PR #364:


6 weeks ago
#22

@imath Interesting. I thought there was a polyfill in WordPress core. Added here: https://core.trac.wordpress.org/ticket/49652

We are using it in other places too: https://github.com/search?q=org%3Abuddypress+str_contains&type=Code

@imath commented on PR #364:


6 weeks ago
#24

Ah, wrong guess I thought that was the reason tests were all failing. I believe it's fine with strpos.

#25 @imath
6 weeks ago

In 14011:

Add 2 new filterable functions to get register/activate root slugs

These 2 functions are used to set rewrite rules and permastructs for registration and activation pages.

Using the provided filters it is now possible to prepend a custom-slug/ to these generated rewrite rules and permastructs. This was the only missing thing to be able to prepend a custom-slug/ to all BP directory/specific page root slugs.

Props espellcaste, slaFFik, dcavins.

See #9063
Closes https://github.com/buddypress/buddypress/pull/364

#26 @slaFFik
6 weeks ago

Sorry for the late reply.

Thank you very much for providing a solution!
Works great for my needs and I do believe it will be helpful to others.

#27 @imath
6 weeks ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 14012:

Documentation: explain how to customize BP base URL

Fixes #9063
Closes https://github.com/buddypress/buddypress/pull/367

Note: See TracTickets for help on using tickets.