GET query string being stripped from url

[mc12345678]

I turned off USU on the live site and it had no effect. I also commented out the notifier and had the first line echo the contents of the GET variable. It was empty. Still scratching my head.

Well, sorry I didn't mean for the live site to be modified. I don't know why I thought this sub-foldered site had USU active (or even installed) I would not have expected any results from that particular test of the live site's USU change.

[badarac]

No worries. I'm trying anything no matter how crazy it seems ;-) I'm going to do a fresh install on my server and put that page only on. At least then I'll have some control over the environment and can easily look at server logs.

[balihr]

Would you mind posting the entire contents from includes/modules/pages/request_a_quote/header_php.php ?

[badarac]

I will but I'll need to remove all customer info first.

[badarac]

So just a quick update. I decided to do the fresh install on my server. I used the demo data and the only change was the request a quote page. It worked fine. I did a fresh install with the demo data and the request a quote page to the client server. I used a new directory and database to ensure it was pristine. It stripped the query string off. That tells me that it's something server related. Any suggestions on what might cause this on the server side?
csf? Imunify360?

[mc12345678]

So just a quick update. I decided to do the fresh install on my server. I used the demo data and the only change was the request a quote page. It worked fine. I did a fresh install with the demo data and the request a quote page to the client server. I used a new directory and database to ensure it was pristine. It stripped the query string off. That tells me that it's something server related. Any suggestions on what might cause this on the server side?
csf? Imunify360?

Two additional "test" ideas. One is to also temporarily rename the .htaccess file and try again. Two is to rename the prod parameter for the purposes of the plugin to perhaps something else. Three might be to setup the local test site to otherwise mimic the live site where there is an htaccess in the root and the sub-directory with store to perform operation.

Thing is, if understand correctly, the live site is still the "old" site where the plugin is working, this new site sounds like it is in a subdirectory off of the live site, so it otherwise has the same environment as the live site doesn't it? Or is something causing a difference such as the last couple of lines of the htaccess file where a php version is called out?

[badarac]

You are correct. The new site is in a subdirectory on the live site which is in the root. The .htaccess is in the root. I currently have the site on my server installed in a subdirectory. I'll copy the .htaccess from their live site to my server and see what happens. Maybe earlly tomorrow I'll try renaming the .htaccess file on their server and see if it makes a difference. I'll keep you posted

[badarac]

So I can recreate this on my server. The interesting part is that it either works or doesn't depending on the page the url is entered. If the url containing the query string is entered on any page other than either the contact_us or request_a_quote the query string parameters past the main_page are gone. On the contact based pages the entire query string is available. I can see that by doing a print_r($_GET) in application_top. I replaced the script in header_php.php with the contents of that file for contact_us and get the same result. So this seems to be related to the page that you're coming from and not going to.

[mc12345678]

Hate to ask, but could you present your findings in some sort of clearer manner?

I've read the above several times. Not sure what conditions gave what, from, to, what file(s) were changed for the testing, what setup was mirrored... looks like some good testing, just don't see what it was/the results.

[badarac]

Sorry. The testing is being done on a fresh install of 1.5.6c with no mods and using the responsive_classic template. The request_a_quote page was added for testing. In an attempt to discover where the query string is being lost I added an echo of the $_GET parms and array in several location (application_top, sanitize class, header_php...). What I have discovered is that if the page displayed in the browser is contact_us or request_a_quote and the url is entered in the browser which includes the query string http://domain.com/test/index.php?mai...itemnumb=04002, the entire query string is returned in all of the echos of the array.

Array ( [main_page] => request_a_quote [prod] => 22 [itemnumb] => 04002) From app top

If the page displayed in the browser is not one of those pages (for example a product page, the home page, a category page...) and the same url is entered in the browser, the only get parameter passed is the main_page

Array ( [main_page] => contact_us ) From app top

Hope this makes it more clear