Skip to:
Content

BuddyPress.org

Opened 6 years ago

Closed 4 years ago

Last modified 3 years ago

#5087 closed defect (bug) (fixed)

BP component as front page messes up blog search

Reported by: modemlooper Owned by: boonebgorges
Milestone: 2.4 Priority: high
Severity: normal Version: 1.5
Component: Core Keywords: has-patch needs-docs
Cc:

Description

If you have a Buddypress page set as the home page then blog search is killed because search sends you to /?s=xxx and then is searches the component instead of listing blog posts.

Not sure if this is a theme issue. Thoughts?

Attachments (1)

5087.diff (2.4 KB) - added by boonebgorges 4 years ago.

Download all attachments as: .zip

Change History (23)

#1 @johnjamesjacoby
6 years ago

  • Milestone changed from Awaiting Review to 1.9

Somewhat of a known issue, though not documented. It's because the search query string is globally the same, all of them listening for 's' instead of their own. We started working around this is a few places, but it's likely that it never was finished.

Moving to 1.9 to think about how to solve this later, possibly related to rewrite rules.

#2 @boonebgorges
6 years ago

  • Milestone changed from 1.9 to 2.0

#3 @r-a-y
6 years ago

  • Milestone changed from 2.0 to 2.1
  • Version changed from 1.7 to 1.5

Moving to 2.1 when we can tackle this with rewrite rules.

#4 @boonebgorges
5 years ago

Marked #5643 as duplicate.

#5 @mth75
5 years ago

is it possible to asign this bug and give it a higher priority?, core functionality from WP is losses.

#6 @boonebgorges
5 years ago

The bug is already slated for the 2.1 release, so I don't think there's much good in increasing priority at this time.

As a temporary workaround, you can reconfigure your blog search to go to a blog archive page, rather than the home page URL.

#7 @DJPaul
5 years ago

  • Milestone changed from 2.1 to 2.2

Moving to 2.2 with the rest of the other rewrite rule-related tickets.

#8 @DJPaul
5 years ago

  • Milestone changed from 2.2 to Future Release

#9 @thunksalot
4 years ago

  • Priority changed from normal to high

Does anyone know a work-around for this? It doesn't appear that a bug fix is imminent.

Seeing how this keeps getting kicked down the road, I'd like to echo @mth75 and ask that the priority of this be raised. Having the Activity page as the homepage of my community was much better for promoting engagement, but then I discovered that it was breaking search and had to put it back to a static homepage. :(

@boonebgorges
4 years ago

#10 @boonebgorges
4 years ago

  • Keywords has-patch added
  • Milestone changed from Future Release to 2.4

5087.diff is a suggested strategy. It does the following:

  • When parsing URIs, bail on URLs like example.com/?s=foo if a BuddyPress component page is set to 'page_on_front'.
  • The check has to go late in the catchuri() function, because we need to be able to detect current_action in order to allow example.com/members/boone/activity?s=foo to continue to work when members is the front page. Not terribly elegant, but it gets the job done.
  • The change will break directory search boxes. I changed the default Members directory search form so that the search term is in $_GET['members_s'] instead of $_GET['s']. The same fix would have to be applied to the other components (mainly groups, since Activity doesn't have a native search box).

The downsides of this approach, as I see them, are:

  1. Any custom search forms or other routers that direct traffic to [member_directory_url]?s=foo will break in cases where the front page is set to the member directory. This is definitely a corner case, but worth considering.
  2. The URL example.com/?member_s=foo is not very attractive. I'm open to better ideas for the URL param. For pagination we use apage for activity, etc - maybe msearch is better, though it's equally untranslatable.

I think what I'm suggesting here is imperfect, but better than the current state of affairs. Anyone have thoughts about it?

#11 @boonebgorges
4 years ago

#6620 was marked as a duplicate.

#12 @boonebgorges
4 years ago

  • Keywords 2nd-opinion removed

Circling back around to this. The query arg 'members_s' is ugly, and doesn't allow for translation. So I'm going to add a layer of abstraction, so that components can register their own 'search_query_arg'. We'll make this the reasonably attractive 'members_search', 'groups_search', etc in core, and plugins/sites can filter if they want.

#13 @boonebgorges
4 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

In 10110:

When a copmonent directory is set to the front page, don't interfere with blog searches.

WP's default search query arg is 's', so that URLs like example.com?s=foo lead
to a search of blog posts on the term 'foo'. When a BuddyPress component page
like Members is set to the front page, it interferes with this behavior in two
ways: (1) BuddyPress interprets example.com?s=foo as a Members directory
request, and (2) the 's' query arg is interpreted as a Members search term.

We fix this conflict as follows:

  • During the URL parsing process, don't interpret requests of the form example.com?s=foo as being BP component requests, even if a BP component is set to the front page.
  • In order to make BuddyPress component searches continue to work, we change the default search query arguments for each component to be unique. For example, member directory searches look like example.com?members_search=foo. Components register their own 'search_query_arg', and these args can be filtered with the new 'bp_core_get_component_search_query_arg' filter.

Fixes #5087.

#14 @DJPaul
4 years ago

  • Keywords needs-docs added

Noting here that when we update the codex release note for 2.4, we should note that the parameter has been changed in case anyone has hardcoded links.

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


4 years ago

#16 @boonebgorges
4 years ago

In 10363:

Use correct search_query_arg for members component.

[10110] introduced the wrong string. See #5087.

Props modemlooper.
Fixes #6733.

#17 @boonebgorges
4 years ago

In 10364:

Use correct search_query_arg for members component.

[10110] introduced the wrong string. See #5087.

Merges [10363] from the 2.4 branch.

Props modemlooper.
Fixes #6733.

#18 @r-a-y
4 years ago

In 10378:

Make sure search terms are passed when rendering pagination.

r10110 altered the search query parameter for each BuddyPress component
(see #5087). However, we also need to change the search query parameter in
our template loops so pagination will work when a search is in effect.

This commit alters the Members and Groups component template loops to use
the new search query parameter and alters the JS to find the correct search
term value.

See #6745 (trunk).

#19 @r-a-y
4 years ago

In 10380:

Make sure search terms are passed when rendering pagination.

r10110 altered the search query parameter for each BuddyPress component
(see #5087). However, we also need to change the search query parameter in
our template loops so pagination will work when a search is in effect.

This commit alters the Members and Groups component template loops to use
the new search query parameter and alters the JS to find the correct search
term value.

See #6745 (2.4-branch).

#20 @r-a-y
4 years ago

In 10406:

Use component search parameter instead of hardcoded 's' parameter.

This commit primarily fixes issues with extended profile links using the
older 's' parameter instead of the newer members search query argument.
See #5087.

Props kennibc.

See #6770 (2.4-branch).

#21 @r-a-y
4 years ago

In 10407:

Use component search parameter instead of hardcoded 's' parameter.

This commit primarily fixes issues with extended profile links using the
older 's' parameter instead of the newer members search query argument.
See #5087.

Props kennibc.

See #6770 (trunk).

#22 @DJPaul
3 years ago

  • Component changed from Component - Any/All to Core
Note: See TracTickets for help on using tickets.