Opened 5 years ago
Closed 5 years ago
#8187 closed defect (bug) (fixed)
members page takes over home page of subsite "members" in a multisite subdirectory installation
Reported by: | santiazpi2 | Owned by: | imath |
---|---|---|---|
Milestone: | 6.0.0 | Priority: | normal |
Severity: | normal | Version: | 5.0.0 |
Component: | Core | Keywords: | has-patch commit |
Cc: |
Description
When you create a sub-site in the directory "members" in a multisite directory installation and you activate Buddypress in that subsite, the members page will take over the assigned home page, whether it is latest posts or a static page.
Steps to reproduce:
- Create a new WordPress mutisite site with subdirectories
- Install Buddypress
- Create subsite in directory "members"
- Activate Buddypress in subsite "members"
- Go to home page of sub-site,
=> | Buddypress Members page becomes the home instead of Latest posts (or a static page when you select that option Settings > Reading). |
To bypass the bug, you can change the slug of the members page to something else.
Tested to change to slug "members" to and from buddypress page and regular page, to prove: buddypress takes over home, regular page does note.
Tested on a brand new installation with twenty-twenty and twenty-nineteen and Buddypress as the only active plugin.
Did not test with other normal buddypress pages, such as "activity" on subsite activity, etc.
Attachments (2)
Change History (6)
#2
@
5 years ago
- Keywords has-patch added
- Milestone changed from Awaiting Review to 6.0.0
Here's my review about this report.
1) I wasn't able to reproduce the described issue. If WordPress Multisite is installed using subdirectories and BuddyPress is activated on a sub site having the members
path, then the permalink to the Members component is site.url/members/members/
and site.url/members
is rightly displaying subsite's home page.
2) But I've found a potential slug conflict: when BuddyPress is network activated on a "subdirectory installed" WordPress Multisite & if a new site is created using the slug of a BP Component of the root site's.
To fix this issue, we need to add the component's page slug to the WordPress's subdirectory_reserved_names
. See the beginning of the attached patch.
I've added unit tests and deprecated 2 functions we are no more using.
@santiazpi2
Thanks for reporting this issue. A quick fix is to edit the page's permalink for something else than
members
into the WP Editor.I'll look deeper into it soon.