Contact_us redirects to home page

I have a weird problem that I could use a little help with. Zencart 1.5.4 running on php 5.5. The cart is lightly modified with the exception of the template. The mods installed are Advanced shipper, google analytics 2.4.2, numinix facebook like button, printable price list, image handler, and a template. I'm not sure exactly when it started but when I click on the contact us link it sends me to the home page. Looking at the logs it shows a 302 redirect. There are no redirects set up that I can see in the cpanel or .htaccess files. Here's the weird part. Maintenance mode is set to send the customer to the contact us page. Down for Maintenance: filename is set to contact_us in the config and that works fine. To rule out a template issue I switched to the classic template and it redirects to the home page also. If I enter the url in the browser it redirects too. https://www.domain.com/index.php?main_page=contact_us lands at index.php?main_page=index. Any idea where to look for the possible cause of this?

First thing that comes to mind is to look at the items in the folder: includes/modules/pages/contact_us and compare the file listing and contents to a default install of the same... Pay attention to files ending in .php that are not in a vanilla install and differences in the files that are. Then also look to see if there are any observers that are hooking the header notifiers or ones in the overidden template file if any...

A link to your site would assist

charlestoncurator.com

Have you kept track of the files you have edited?
Have you used the template override system for them?

i would 2nd what mc12345678

specifically, in:

includes/modules/pages/contact_us/header_php.php

i would look for any modified code specifically making us of the function zen_redirect

in addition, i would try logging in as a customer and see if that redirect is still happening as well...

i agree that the behavior is weird in that it works when the site is in maintenance mode, HOWEVER, i would check to see if the redirect is just running a loop and then your browser is giving up... so when you are in maintenance mode, it redirects u to the contact_us page, which now redirects you to the index page, which is maintenance mode so now you are redirected to the contact_us page, etc.

you can check if that is happening by looking at the network tab in the developer tools.

but, i would first check if the same behavior is happening when a customer is logged in and go from there.

carlwhat:

specifically, in:

includes/modules/pages/contact_us/header_php.php

i would look for any modified code specifically making us of the function zen_redirect

One reason I didn't focus specifically on the header_php.php file first is that all too often edited files are saved with some modification of the filename, but the modification usually keeps .php as the extension. Problem is every file in the pages sub-directory that ends in .php is processed. But it got renamed right? Don't matter, ends in .php it is run... The fact that the same response occurs for both the new template and the default says that they share something together. If suggested process of install and maintenance is followed, then likely to be an issue with some sort of modified core code, one or more of the directories that are not overridden or overrideable or the same modifcation was made to identical files (two overides or one override and one "original", etc...)

The next thing would be if that directory appears normal would be to look at the redirects, what it takes to cause them and try to determine what if anything provides the redirect, and then also possibly follow the redirect(s) to see what happens there. There are several useful tools that can be used to follow the progress of processing: super globals, log viewer, etc...

I'll try and catch all of the questions and suggestions here rather than respond to each individually. Yes I've kept track of the changes and I have used the overrides where it's possible. The fact that it affected both the modified and classic template, which is untouched, led me to believe that it must be a core file that was modified. I have used Beyond Compare to identify the changes from the original 1.5.4 files. So far I have not found anything that should cause this. I did a fresh install to a sub-directory using the demo products just to check that it wasn't some sort of a server issue that was causing it. The fresh unmodified install works correctly.

My original thought was that the contents of includes/modules/pages/contact_us may have been modified or corrupted. The compare did not show anything but I replaced the contents with the file from the 1.5.4 zip. There were no extra files there. In fact The .js file was not there. I removed it to correct a problem with customers using ipads not being able to type in the form fields. I did put that back to test if that might have been the problem. It wasn't.

I looked for notifiers hooking the header and only found one. Removing changes from that mod had no impact.

Being logged in had no effect. Carl I'm not sure what network tab you're referring to in developers tools.

MC I'd love for you to expand that list of tools you think might be helpful to debug. I'm going to try and understand how the page is rendered differently if it's in maintenance mode. The difference in flow has got to be where the problem lies. If anybody knows that off the top of you head I'd appreciate a quick synopsis.

I'm also thinking of adding the mods to the unmodified code in the subdirectory to see what breaks things. That's kind of a brute force solution but there aren't that many mods to deal with.

very interesting thread. mc, is there a particular order that all the .php scripts get executed when in a modules/pages directory?

i am no expert on the differences when in maintenance mode, however after a cursory review, there does "appear" to be some difference in the way the maintenance page gets loaded. there is a function called zen_href_params in includes/functions/html_output.php that adds $addparms = 'rel="nofollow"'; to the params list; but i can not see when then gets called. frankly i find it interesting, but also a red herring, as i would try and find out why the page does not load and does the redirect when in normal mode, as that's the real problem. but that's me...

badarac, i'm assuming you know about f12 developer tools? its available in chrome, firefox and a number of other browsers. its a very helpful tool for debugging. there is a network tab on it, that you can see the order of page loads as well as the http status codes. i'll attach a screenshot....

good luck.

Carl,
Thanks. I was thinking admin not browser. Yes I'm familiar with the developer tools in the browser.

mc12345678:

One reason I didn't focus specifically on the header_php.php file first is that all too often edited files are saved with some modification of the filename, but the modification usually keeps .php as the extension. Problem is every file in the pages sub-directory that ends in .php is processed. But it got renamed right? Don't matter, ends in .php it is run... The fact that the same response occurs for both the new template and the default says that they share something together. If suggested process of install and maintenance is followed, then likely to be an issue with some sort of modified core code, one or more of the directories that are not overridden or overrideable or the same modifcation was made to identical files (two overides or one override and one "original", etc...)

The next thing would be if that directory appears normal would be to look at the redirects, what it takes to cause them and try to determine what if anything provides the redirect, and then also possibly follow the redirect(s) to see what happens there. There are several useful tools that can be used to follow the progress of processing: super globals, log viewer, etc...
The highlighted assertion is not-quite-true. What *is *true is that for a given /includes/modules/pages/pagename, all .php files with names that match the following are loaded:

1. header_php*.php (the header_php.php file is loaded first)
2. jscript*.php (loaded as part of the current template's html_header.php processing

I uploaded all the files from the live site to the test site. I went folder by folder to see if I could narrow down the offender. No files broke the contact page. So I thought to myself what is left? I exported the configuration tables from the live site and imported them to the test site. That broke it. Now I need to try and identify what setting is causing the contact page to redirect. This should be fun.

I have used Beyond Compare to identify the changes from the original 1.5.4 files. So far I have not found anything that should cause this. I did a fresh install to a sub-directory using the demo products just to check that it wasn't some sort of a server issue that was causing it. The fresh unmodified install works correctly
Just because you did not see anything that "SHOULD" cause this does not mean that it is not there
As the classic exhibits the same it must be a core file
Try replacing one by one the core files you have edited until you locate the offender

kobra:

Just because you did not see anything that "SHOULD" cause this does not mean that it is not there
As the classic exhibits the same it must be a core file
Try replacing one by one the core files you have edited until you locate the offender
See post 12

Well the good news is that I found it. I did a fresh install and can confirm that if you change the down for maintenance filename in admin/website maintenance to contact_us, when you load the contact_us page it redirects to the homepage. Just for chuckles I changed it to privacy and clicked on the privacy notice link. I then sent the privacy page to the homepage and the contact page worked. Looks like a bug. If a mod wants to move this over to the bugs section that would be fine. I'll start a new thread there if you prefer.

Just got what you are doing...
Why when down for maintenance are you wanting to send them to your contact us page???
The code is working as designed - when down for maintenance any link takes you to the index page
You might have a custom page that you can enter but not one of the carts default pages
The default is down_for_maintenance

kobra, actually i do not think that is what he is doing....

badarac, when i tested the contact us page and found it not working on your site; i did not see if it was down for maintenance (and i assume it was not), but i cannot be sure.

i have a responsibly clean/fresh install of v1.5.4 and frankly i could not reproduce the bug. if i put the site down for maintenance, it would redirect to the contact_us page if that was set up in the configuration. or the down_for_maintenance page if that was set up. when i took it off maintenance, the contact us started working again.

so, i'm happy that you got the problem resolved but frankly i was not able to reproduce the bug.

kobra:

Just got what you are doing...
Why when down for maintenance are you wanting to send them to your contact us page???
The code is working as designed - when down for maintenance any link takes you to the index page
You might have a custom page that you can enter but not one of the carts default pages
The default is down_for_maintenance
The short answer is that's what the client wanted. So what you're saying is that that field in the admin is intended to send to a custom page not by default installed with zencart. Will replacing the file contents for down for maintenance with contact us work? If not do you think my only options would be to modify the code or create a custom contact form as a new page?

carlwhat:

kobra, actually i do not think that is what he is doing....

badarac, when i tested the contact us page and found it not working on your site; i did not see if it was down for maintenance (and i assume it was not), but i cannot be sure.

i have a responsibly clean/fresh install of v1.5.4 and frankly i could not reproduce the bug. if i put the site down for maintenance, it would redirect to the contact_us page if that was set up in the configuration. or the down_for_maintenance page if that was set up. when i took it off maintenance, the contact us started working again.

so, i'm happy that you got the problem resolved but frankly i was not able to reproduce the bug.

That was the intent. The client wanted customers to be presented with the contact form. To recreate the problem change the down for maintenance file name to contact_us. Go to the site ant click on a link to the contact page. It will take you to the homepage. Then set the site down for maintenance and refresh the page. You will see the contact form.

badarac:

That was the intent. The client wanted customers to be presented with the contact form. To recreate the problem change the down for maintenance file name to contact_us. Go to the site ant click on a link to the contact page. It will take you to the homepage. Then set the site down for maintenance and refresh the page. You will see the contact form.

i totally hear what you are saying. i tried what you said, and i was not able to reproduce the bug....