When solr does not have a search keyword, the get_path function can return a '//' in the url. Please see the attached patch.

Comments

mikejoconnor’s picture

Title: filter urls containg '//' when there are no search keywrods » filter urls contain '//' when there are no search keywrods
mikejoconnor’s picture

Status: Active » Needs review
pwolanin’s picture

Sure, or perhaps we should leave the trailing '/' off the base path?

mikejoconnor’s picture

That's how I approached it the first time. I ran into an issue but I don't recall what it was. I'll see if I can find it again.

pwolanin’s picture

you could possibly use rtrim($path, '/') when it's set, or for this function.

pwolanin’s picture

StatusFileSize
new747 bytes
mikejoconnor’s picture

Unfortunately the patch in #6 will not work. If $basepath is empty, and your call back is your front page you end up with http://example.com//?filters=tid%3A522

pwolanin’s picture

still an issue?

JacobSingh’s picture

I'm not sure how to replicate this exactly.

Mike, can you post more detail or close this out?

Thanks,
j

jpmckinney’s picture

Status: Needs review » Fixed

The only way to achieve '//' is to pass a base_path with a trailing slash ("search/apachesolr_search/") or to pass an empty base_path. I've committed a PHPDoc update to note that base_path should not have a trailing slash. I prefer to force developers to follow an API, than to have a permissive API that does all sorts of clean-up (in this case, trimming trailing slashes). As for an empty base_path, you should just set <front> to "search/apachesolr_search" to achieve the same result. http://drupal.org/cvs?commit=360074

Finally, I don't see how this has anything to do with having no keywords. Nothing is ever appended to the result of Solr_Base_Query::get_path, so the trailing slash in the absence of keywords is not a problem.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.