Regardless of whether the site is using Solr or Core search, the primary nav item that appears for small screen sizes redirects to /search/site, which looks wonky, per the screenshot.
I suggest we implement a simple redirect callback for Commons search so that the primary nav item can be static and the callback can route the request appropriately.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | Screen Shot 2013-03-18 at 8.44.05 PM.png | 26.85 KB | jpontani |
| #2 | Screen Shot 2013-03-18 at 8.45.16 PM.png | 56.11 KB | jpontani |
| Screenshot_3_15_13_6_47_PM.png | 41.89 KB | ezra-g |
Comments
Comment #1
jpontani commentedFacets will now show up initially in the proper region (left panel).
http://drupalcode.org/project/commons_search.git/commitdiff/473eccb
As for why the nav item redirects to the wrong page, still debugging that. It should just point to /search, which will redirect to the site's default search module's provided search path (Solr is /search/site, Core is /search/content)
Comment #2
jpontani commentedSo I added a second page manager variant, and contexts to each (there are 2 variants for Core search).
One is for an empty search (keywords length = 0), that uses AT single column with just the search form:
The second variant is when a search happens (keyword length > 0) that uses the current AT 2 column layout:
Only thing left is some theming love to get the initial variant in line with the current style.
Going this route (I feel) is the better route in that it is less taxing on the server as it doesn't have to check whether or not to render the facetapi blocks, and runs through less code to get to the actual page rendering, and is thus more efficient and takes less time.
Comment #3
jpontani commentedForgot to add the commit reference: http://drupalcode.org/project/commons_search.git/commitdiff/376273c
Comment #4
jpontani commented