I noticed that the search results page was redirecting the user/site visitor to the HTTP version of the site — even if the user was connecting via HTTPS.

I'm sort-of a noob, so unsure if this is the most appropriate place to submit a code suggestion, but I'm guessing someone will let me know. I modified "custom_search.module" as follows:

added the following line to just before the :
"// build the custom path" section

<----- snip ----->
// Determine HTTP connection port and route to search results accordingly
if($_SERVER['SERVER_PORT'] == 443){ $http_port = 'https'; } else { $http_port = 'http'; }

...
// modifying the "build" line as follows:
$form_state['redirect'] = $http_port.'://' . $_SERVER['HTTP_HOST'] . base_path() . $custom_path;

Comments

jdanthinne’s picture

Version: 6.x-1.6 » 6.x-1.x-dev
Category: feature » bug
Status: Active » Needs review

Ok, I was already testing for https with :
(isset($_SERVER['HTTPS']))

I've added the server port in the condition :
(isset($_SERVER['HTTPS']) || $_SERVER['SERVER_PORT'] == 443)

Please download DEV version from 1st January 2011 and please tell me if it's working better for you.

gorsti’s picture

Version: 6.x-1.x-dev » 6.x-1.7

Hi jdanthinne

I have custom search block on homepage http, which when I moved from local development server to new hosting server is redirecting all search requests to https:// instead of http:// and therefore page errors. I am using 1.7 version of the module.

I note you comment to szwilson was to use the 1/1/11 onwards dev version instead of 1.6, the question now is - should I now use the DEV stream version? I guess this fix wasn't included in 1.7 ?

I am confused that this error doesn't appear on my local server (home brew drupal stack), but does appear on my hosted drupal stack from my service provider.... with exactly same code base..... albeit different PHP version and use of varnish etc.

Thanks,
Gorsti

berenddeboer’s picture

Priority: Normal » Major
Status: Needs review » Active

nah, dev version still always redirects to https.

jdanthinne’s picture

Version: 6.x-1.7 » 6.x-1.x-dev

@gorsti : This has been included in 1.7, but you should always test with latest DEV.

@berenddeboer : what do you mean by "always"?

gorsti’s picture

@jdanthinne thankyou for your fast response. I will test the latest dev on the host server and see if it works, but if the code is already included in 1.7 release (which is what I am using) then I still have the issue that I always get a redirect to https as expressed by @berenddeboer on a http:// server, when using custom search module block.

I don't see this on my local server, only on my hosted solution which uses varnish etc. - I can send status pages, or other environment variables offline if you wish, and am happy to help in any way to resolve this.

Thank you,
@gorsti

jdanthinne’s picture

I've just pushed changes to the DEV version with an other way to find the right base url. (See #1085316: Search is broken in 6-1.7 if you want to make changes by hand).
Please try and review.

gorsti’s picture

@jdanthinne - downloading now! thanks - will post back later this morning. Thanks //G

jdanthinne’s picture

Unfortunately, the new DEV version is not yet generated. Please download when release date says 2011-March-09.
(that's why I put a link to a manual change)

gorsti’s picture

Hi @jdanthinne - so I notice, that DEV didn't work - will wait for 2011-March-09 DEV. Thx /G

gorsti’s picture

@jdanthinne - You beautiful person! that works great!!!!! Thanks a million!!!!! /G

jdanthinne’s picture

Unfortunately, it's not working for multilingual sites yet… see #1085316: Search is broken in 6-1.7.
Some more research to do, but it's in the right direction.

jdanthinne’s picture

Finally, it seems to be working fine with multilingual as well.
Can you confirm that the very last DEV is ok?

heddn’s picture

Status: Active » Fixed

I'm taking some liberty but a bug report for D6 from 2010 is probably fixed or irrelevant. If you disagree, please reopen and provide more details.

Status: Fixed » Closed (fixed)

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