#5318 closed enhancement (fixed)
using bp_has_members in widgets and conflicts with $_REQUEST['s']
Reported by: | megainfo | Owned by: | boonebgorges |
---|---|---|---|
Milestone: | 2.0 | Priority: | normal |
Severity: | normal | Version: | 1.9.1 |
Component: | Members | Keywords: | needs-patch 2nd-opinion |
Cc: |
Description
bp_has_members get filter passed by parameter "?s=" and it's implying wrong results for all widgets using bp_has_members when the current URL contain "?s=" as parameter.
Change History (7)
#2
@
11 years ago
I think if we default to use ?s
for the new search param and switch the members widget to use a different param like ?ws
, we should be safe.
#3
@
11 years ago
- Milestone changed from Awaiting Review to 2.0
- Type changed from defect (bug) to enhancement
Yeah. On reflection, this sounds more like a workaround than a real fix, since any other kind of member loop will still suffer from this problem. That said, I think there's value in having a separate parameter for widgets, if only to protect against the case where a members widget appears on the members directory. So, on balance, let's go with this kind of fix for now.
#4
@
11 years ago
So, maybe an even easier workaround is to pass search_terms => false
to the bp_has_groups()
loop in the widget. Since our widget doesn't contain an interface for searching, I don't think we need to support it there. (If someone wants a group search widget, they can build it.) What do others think?
Good catch. I can see why this would be a problem. WordPress (and probably others) use
?s=
for its default search param.Ideally, we'd use our own URL param for this (kinda like we use
acpage
for activity pagination links). But I'm not sure off the top of my head whether we can do this while maintaining backward compatibility in all cases. Any thoughts?