Warning: array_merge(): Argument #2 is not an array in bef_replace_query_string_arg()

I think this speaks to a bigger issue with your site. Yes, parse_url() will return FALSE for malformed URLs, such as the first example you gave (":" is not allowed in query strings). The problem is that we can't be validating the incoming request in bef_replace_query_string_arg(). That function expects a valid query string and gives a warning when it does not get one.

I'm seeing the same warning filling my logs, and it's not clear from the above what we should do about it. The requests are like this:

http://example.com/events/2016/:5054

Are you saying that the problem lies in request_uri() in this case, or is the problem in parse_url()?

Bots and hackers probe websites using invalid query strings all day, every day. Shouldn't that be the default expectation, rather than thinking everyone is going to be well-behaved?

If it's likely that parse_url() will return false sometimes, then what's the problem with testing for false before using its output?

Anyway, the following implementation of hook_init() appears to solve the problem for me, without hacking BEF -- though I'm not sure if it will cause problems elsewhere.

function mymodule_custom_init() {
  // Prevent "Warning: array_merge(): Argument #2 is not an array in
  // bef_replace_query_string_arg() (line 703 of
  // sites/all/modules/contrib/better_exposed_filters/better_exposed_filters.theme)"
  // for requests such as http://example.com/events/2016/:555
  if (isset($_SERVER['REQUEST_URI'])) {
    $_SERVER['REQUEST_URI'] = str_replace(':', '%3a', $_SERVER['REQUEST_URI']);
  }
  else {
    if (isset($_SERVER['argv'])) {
      $_SERVER['argv'][0] = str_replace(':', '%3a', $_SERVER['argv'][0]);
    }
    elseif (isset($_SERVER['QUERY_STRING'])) {
      $_SERVER['QUERY_STRING'] = str_replace(':', '%3a', $_SERVER['QUERY_STRING']);
    }
  }
}

Patch for fixing this warning.

Sorry, warnings are not major.

+++ b/better_exposed_filters.theme
@@ -701,7 +701,7 @@ function bef_replace_query_string_arg($key, $value, $multiple = FALSE, $remove =
-  $urllist = array_merge($urllist, parse_url(request_uri()));
+  $urllist = array_merge($urllist, parse_url(urlencode(request_uri())));

urlencode should only be used on the query string portion of the URI, in this case we're using it on the path and query string. Also, I'm worried about double-encoding if we do this -- usually urlencode is for when you're printing a query string, not when you're consuming it.

Agreed, however, that bots are constantly pounding our sites with bogus URLs and we shouldn't be filling up the log files because of it. I prefer the option to test the return value of parse_url before using it and will look at making that change later today.

Sorry for the long delay in getting back to this issue!

Hi, there will be no more future development for 7.x branch. If you see this issue in 8.x, feel free to file an issue. Closing this as Closed(wont fix).

Are you saying that 7.x is now unsupported?

@markabur 7.x is fully supported even now and in the future. If you think this issue still exists in 7.x feel free to report