GET query string being stripped from url

[mc12345678]

Have you tried varying the parameters? Swapped the position of prod with the other parameter, used one or the other but not necessarily both?

Had the site been navigated at least once or twice before clicking the link? Wondering if there is a session started/not type issue?

[badarac]

I have tried it altering the position, number, and name of the parameters. It gives the same results. By accident I changed the parameter while on a category page and left the page name the same http://twistingroads.com/test/index....itemnumb=12345. That actually passed the parameters correctly

Array ( [main_page] => index [prod] => test [itemnumb] => 12345 ) From app top

So it appears that we've narrowed it down some more. It looks like it must be called from a non-contact form page to a contact form page. I left the domain name on this one since it's to the demo store on my server and contains no customer data.

EDIT: I missed answering the last question. I have tried this with both a new session and back and forth on the same session.

[lat9]

Is the site running SSL-all-the-time? I'll note that the contact_us page, starting with zc155, is an SSL-only page while the link you posted appears to be non-SSL.

[badarac]

No but I'll fix that right now ;-)

[badarac]

We have a winner!!!! The query string is lost going from a non-ssl to ssl page. I just copied the original header_php and template back and it now works correctly. This is probably something that should be address at some point in the code but I'll just have the client site load every page in ssl . THANKS EVERYBODY!!!

[mc12345678]

We have a winner!!!! The query string is lost going from a non-ssl to ssl page. I just copied the original header_php and template back and it now works correctly. This is probably something that should be address at some point in the code but I'll just have the client site load every page in ssl . THANKS EVERYBODY!!!

Did you still have the trigger code recommended for the redirect such that might be able to see where/if the redirect occurs? Seems that if the socalled always SSL page causes a redirect that it should hold the get parameters at least even if the post parameters get lost. Further, this might have been overlooked because of using screen printed information rather than file written where the information sent to the screen might have gotten "removed" but not so in the file(s).

[badarac]

I didn't still have that trigger code on. I can put it on and set my server back to the problem state if you'd like though.

[mc12345678]

I didn't still have that trigger code on. I can put it on and set my server back to the problem state if you'd like though.

How to put it. I was trying to identify additional ways to test/check for the information. The issue with the "all SSL" setup last I thought about it was that it was supposed to check to see if the store is setup/supports SSL and if so to ensure SSL was being used. In the "basic" use, there are no other parameters used. Therefore, there is no "reason" to obtain the parameters and maintain them while redirecting.

Further to add to this, if the previous "data" capture was screen side (final result) by use of print_r, then yes a redirect that doesn't include the original url parameters will result in their loss and as seen visual display of not existing. A more permanent record of their existence (trigger_error) would have identified that they existed on first arrival, but then were removed upon second/subsequent arrival.

So, does the trigger_error need to be put back in? Not necessarily. What would specifically help in further resolution to this is the portion of the code in the header_php.php file where a check is done for SSL and the subsequent zen_redirect line. Then as part of that to also identify the includes/configure.php setup associated with HTTP_SERVER and ENABLE_SSL. The domain can be obscured, but the protocol used for communication would be important.

[badarac]

This is the redirect section from header_php.php

} // end action==send


if (ENABLE_SSL == 'true' && $request_type != 'SSL') {
  zen_redirect(zen_href_link(FILENAME_REQUEST_A_QUOTE, '', 'SSL'));
} 

This is the config file showing the protocol. I've edited it to reflect the state when the problem occurred

 * Enter the domain for your store
 * HTTP_SERVER is your Main webserver: eg-http://www.yourdomain.com
 * HTTPS_SERVER is your Secure/SSL webserver: eg-https://www.yourdomain.com
 */
define('HTTP_SERVER', 'http://domain.com'); --- Currently set to https
define('HTTPS_SERVER', 'https://domain.com');
/**
 *  If you want to tell Zen Cart to use your HTTPS URL on sensitive pages like login and checkout, set this to 'true'. Otherwise 'false'. (Keep the quotes)

 */
define('ENABLE_SSL', 'true');

/** 

Let me know if there's anything else you need.

[balihr]

if (ENABLE_SSL == 'true' && $request_type != 'SSL') {
zen_redirect(zen_href_link(FILENAME_REQUEST_A_QUOTE, '', 'SSL'));
}

Wait, was this there all the time? This is actually the reason why I asked you to post the contents of the header_php.php file...