BuddyPress not allow use search like domain.com/search/my+search+text

[Ivinco]

Default wordpress Installation allows to search via url like domain.com/search/my+search+text
BuddyPress don't allow these searches.

I fixed this bug, but maybe is not the best way.

[ 15:11:12 ] :> diff -u bp-core-catchuri-org.php bp-core-catchuri.php 
--- bp-core-catchuri-org.php    2012-04-19 15:10:37.000000000 +0300
+++ bp-core-catchuri.php    2012-04-19 15:10:49.000000000 +0300
@@ -375,6 +375,9 @@
 function bp_core_catch_no_access() {
    global $bp, $bp_no_status_set, $wp_query;
 
+        if ($bp->current_component == 'search') {
+            return true;
+        }
    // If bp_core_redirect() and $bp_no_status_set is true,
    // we are redirecting to an accessible page, so skip this check.
    if ( $bp_no_status_set )


[15:13:56 ] :> diff -u bp-core-functions-org.php bp-core-functions.php 
--- bp-core-functions-org.php   2012-04-19 14:55:11.000000000 +0300
+++ bp-core-functions.php   2012-04-19 14:55:57.000000000 +0300
@@ -825,6 +825,10 @@
  */
 function bp_core_action_search_site( $slug = '' ) {
    global $bp;
+        
+        if ($bp->current_component == 'search') {
+            return;
+        }
 
    if ( !bp_is_current_component( bp_get_search_slug() ) )
        return;

[ericlewis]

Cleaned up Invinco's implementation a bit; added respect for custom title in bp_modify_page_title

[DJPaul]

I think it's really bad that we're using /search/ as a search handler, and that it's stomping all over WordPress query var of the same name. How about we get rid of it.

[boonebgorges]

DJPaul - What kind of backward compatibility problems will this introduce?

[DJPaul]

Lots? The search box in BP-Default's header (all the way back to 1.2) sends a POST to /search/, which we then redirect to the component's index page, with the query passed. bp_core_action_search_site()

[boonebgorges]

I'm less concerned with what we do in BuddyPress (since we can easily rewrite our own search boxes to go to ?s= or whatever) than with what will happen with third party plugins and themes. Is there a way that we can do away with the 'search' hijacking without also breaking old implementations? Here's one idea: Instead of grabbing all requests to '/search/', only grab those that have $_POST data, throw a deprecated notice, and redirect to whatever our replacement solution is. (That won't make example.com/search/foo work, but did it ever?)

[DJPaul]

I think checking POST is a good idea; if we set any BP-specific keys, we can check for those specifically. I'm pretty sure BuddyPress Default Theme has always used POST for that form submission, rather than GET. It might help us get rid of the BP_SEARCH_SLUG fake Url

[DJPaul]

I'm thinking removing our fake search URL could cause problems with other BP plugins that have copied our implementation detail. It's better to do that at the start of 1.7 so there is enough time to test it properly.

[boonebgorges]

Sold.

[darrenmeehan]

Is this something that should be discussed now? I need to look more into what this will involve, but if I feel my skills are up to this, I'd like to help.

[imath]

Hi!

I think the least we need to do is to stop preventing WordPress to use site.url/search/hello pretty urls. It's not good. I think checking if $_POST['search-terms'] is set won't break plugins as anyway bp_core_action_search_site() is redirecting to home if it's empty.

[imath]

In 12404:

Do not interfere with WordPress "pretty URL" search slug

Props Ivinco, ericlewis

Fixes #4154