Contact Us not working, receiving alert messages even though all fields filled in

blackeyed5:

OH. MY. GOD.... That worked!!!!

Seriously... I cannot believe that fixed everything. The https is fixed, and I can send a message! And I even received it in my email!!

one thing though...there are some other pages in the sidebar where the https is still broken, like https://shop.atomicorchard.com/index.php?main_page=gv_faq and https://shop.atomicorchard.com/index.php?main_page=discount_coupon

I'm guessing do the same thing in their tpl files?

blackeyed5:

Seriously... I cannot believe that fixed everything. The https is fixed, and I can send a message! And I even received it in my email!!

one thing though...there are some other pages in the sidebar where the https is still broken, like https://shop.atomicorchard.com/index.php?main_page=gv_faq and https://shop.atomicorchard.com/index.php?main_page=discount_coupon

I'm guessing do the same thing in their tpl files?

Hmm....they don't appear to have a similar line of code though...

blackeyed5:

OH. MY. GOD.... That worked!!!!

Awesome.. I'm trying to figure out if it has already been identified on the forum.. Can't remember which ZC version it was specifically, but after 1.5.1 at some point the contact_us page was identified as one of the pages to be secured... For some reason Anne's version of the template doesn't have the command to reach the next form (itself ulitmately) using a secure connect (if such a secure connection exists then it is offered securely, if not then back to http: )

How are they coded? do you see: http:// and the rest? or something else?

And technically if having issues with the side boxes (which I do see several a href links that are http: instead of https: then need to be looking in your sidebox templates... (or however the code is setup to provide the links that are in the sidebox, ie. could be in a sidebox module...)

Ideally (and if considering using a URI rewriter) all local links should be written using the zen_href_link function.. Otherwise links to off site locations should be written with //servername dot com/path/file That way there will not be any mixed content though there may be links that will not work if https..

mc12345678:

Awesome.. I'm trying to figure out if it has already been identified on the forum.. Can't remember which ZC version it was specifically, but after 1.5.1 at some point the contact_us page was identified as one of the pages to be secured... For some reason Anne's version of the template doesn't have the command to reach the next form (itself ulitmately) using a secure connect (if such a secure connection exists then it is offered securely, if not then back to http: )

Well, thank you very much for helping me fix this one very frustrating problem. I really appreciate it. Like I promised, I would send a free t-shirt to whoever fixed it, so if you want one, send me a message through that form (seems fitting) with your address and shirt size. If you want one, that is.

mc12345678:

How are they coded? do you see: http:// and the rest? or something else?

And technically if having issues with the side boxes (which I do see several a href links that are http: instead of https: then need to be looking in your sidebox templates... (or however the code is setup to provide the links that are in the sidebox, ie. could be in a sidebox module...)

Ideally (and if considering using a URI rewriter) all local links should be written using the zen_href_link function.. Otherwise links to off site locations should be written with //servername dot com/path/file That way there will not be any mixed content though there may be links that will not work if https..

Well, they're not all technically side boxes I don't think? some of the pages are in the information dropdown menu. Here are all the ones that are still broken:

Featured Products
New Arrivals
All Products
Gift Certificate FAQ
Discount Coupons

I'm going to sign off for tonight. I'll try to figure out where the files are to change that code to https: for those files. Thank you so very much for again fixing the Contact form. Sincerely, I really appreciate it. You're a life saver.

blackeyed5:

Well, they're not all technically side boxes I don't think? some of the pages are in the information dropdown menu. Here are all the ones that are still broken:

Featured Products
New Arrivals
All Products
Gift Certificate FAQ
Discount Coupons

Ahhh, that's in:
includes/templates/winchester_black/templates/tpl_modules_mobile_categories_tabs.php

Pretty much the same issue, though I would recommend in most of those cases to use $request_type rather than to hard-code the remaining links to SSL, so like line 56, change from:

  <li><a href="<?php echo zen_href_link(FILENAME_SHIPPING); ?>"><?php echo BOX_INFORMATION_SHIPPING; ?></a></li>

to

  <li><a href="<?php echo zen_href_link(FILENAME_SHIPPING, '', $request_type); ?>"><?php echo BOX_INFORMATION_SHIPPING; ?></a></li>

This will make the link so that it uses the same "prefix" as the way the current page is displayed... So if on an https: page, then the link will be https: if on a http: page, then the link will be http:

You will more than likely have to go through several files to "fix" this to be all https if that's really what you're going for.

Btw, trying to write up an explanation of the conditions in which this occurred... As lat9 pointed out, your includes/configure.php file appears to be from ZC 1.5.1... What version of ZC are you currently using? (I was kind of assuming 1.5.4, but have to always be careful with assumptions...)

mc12345678:

Ahhh, that's in:
includes/templates/winchester_black/templates/tpl_modules_mobile_categories_tabs.php

Pretty much the same issue, though I would recommend in most of those cases to use $request_type rather than to hard-code the remaining links to SSL, so like line 56, change from:

<li><a href="<?php echo zen_href_link(FILENAME_SHIPPING); ?>"><?php echo BOX_INFORMATION_SHIPPING; ?></a></li> ``` > to > ``` <li><a href="<?php echo zen_href_link(FILENAME_SHIPPING, '', $request_type); ?>"><?php echo BOX_INFORMATION_SHIPPING; ?></a></li> ``` > This will make the link so that it uses the same "prefix" as the way the current page is displayed... So if on an https: page, then the link will be https: if on a http: page, then the link will be http: > > You will more than likely have to go through several files to "fix" this to be all https if that's really what you're going for. > > Btw, trying to write up an explanation of the conditions in which this occurred... As lat9 pointed out, your includes/configure.php file appears to be from ZC 1.5.1... What version of ZC are you currently using? (I was kind of assuming 1.5.4, but have to always be careful with assumptions...)

Ok, thank you. Would I use that same step (inserting the $request_type) in all of those files to fix it? Or will I have to do something different for each?

Yeah, I'm using 1.5.1... Is that bad? Is it a necessity to upgrade to 1.5.4? Is it a complicated process to upgrade at this point?

blackeyed5:

Ok, thank you. Would I use that same step (inserting the $request_type) in all of those files to fix it? Or will I have to do something different for each?

Yeah, I'm using 1.5.1... Is that bad? Is it a necessity to upgrade to 1.5.4? Is it a complicated process to upgrade at this point?

If you're just starting your site (which it appears to be so), it is WAY easy to do the upgrade/rebuild (also understand that version 1.5.1 is over 3 years old as compared to 8 months for ZC 1.5.4)... Should upgrade if your host supports the elevated PHP that is becoming the new standard (ie., once PHP 5.3 is not offered on your server then either changes need to be made to support 5.4 on your current ZC or of course the upgrade/rebuild)

Same type of step would be expected if the link is generated using zen_href_link (style that Anne would keep with), if it is a hard coded address such as http:// something or other, then just remove the http: at the beginning so that it would be // something or other...

I just noticed in that file they have: <li class="menu-contact"><a href="<?php echo zen_href_link(FILENAME_CONTACT_US, '', 'NONSSL'); ?>" class="mcontact"><?php echo TITLE_CONTACT; ?></a></li>

Should I change that to: $request_type instead of 'NONSSL' for good measure? or just leave it alone since it's working now?

mc12345678:

If you're just starting your site (which it appears to be so), it is WAY easy to do the upgrade/rebuild (also understand that version 1.5.1 is over 3 years old as compared to 8 months for ZC 1.5.4)... Should upgrade if your host supports the elevated PHP that is becoming the new standard (ie., once PHP 5.3 is not offered on your server then either changes need to be made to support 5.4 on your current ZC or of course the upgrade/rebuild)

Same type of step would be expected if the link is generated using zen_href_link (style that Anne would keep with), if it is a hard coded address such as http:// something or other, then just remove the http: at the beginning so that it would be // something or other...

Hmm...so you're saying I would have to start from scratch if I were to upgrade?

btw, what you suggested doesn't work...it'll switch to for a second to a lock icon, and then go back to broken lock.

blackeyed5:

Hmm...so you're saying I would have to start from scratch if I were to upgrade?

btw, what you suggested doesn't work...it'll switch to for a second to a lock icon, and then go back to broken lock.

Sorry to have possibly "forgotten" the condition, but if you are wanting all pages to be https: then the includes/configure.php needs to be modified to serve all pages as https:

Otherwise the issue is typically mixed content which a link to a non https site from http or vice versa (> <a href=" .. ">some text</a> should not cause the "security" to be in question... Now src=" .. " type arguments need to be written like I have described above removing the http: or https: as applicable... ..

Regarding upgrade/rebuild, yes and no on "starting from scratch" you have a database, and there are some files that haven't changed much, basically transport template, install plugins (merging files) and then go through the proceess of working with the database (some things are out of sequence for sake of discussion.)

DrBytes upgrade process by rebuild (needed mostly because of core changes):
http://www.zen-cart.com/entry.php?3-How-do-I-rebuild-my-site-on-the-new-version-instead-of-upgrading

mc12345678:

Sorry to have possibly "forgotten" the condition, but if you are wanting all pages to be https: then the includes/configure.php needs to be modified to serve all pages as https:

Otherwise the issue is typically mixed content which a link to a non https site from http or vice versa ( should not cause the "security" to be in question... Now src=" .. " type arguments need to be written like I have described above removing the http: or https: as applicable... ..

Regarding upgrade/rebuild, yes and no on "starting from scratch" you have a database, and there are some files that haven't changed much, basically transport template, install plugins (merging files) and then go through the proceess of working with the database (some things are out of sequence for sake of discussion.)

DrBytes upgrade process by rebuild (needed mostly because of core changes):
http://www.zen-cart.com/entry.php?3-How-do-I-rebuild-my-site-on-the-new-version-instead-of-upgrading

That first part about the src=" .. ", I'm not sure what you mean. But essentially you're saying I should just leave it as mixed content? I'm just worried about visitors seeing that warning sign about the SSL and thinking the site is "unsafe".

I'll check out the link you sent about upgrading tomorrow. I'm not really a programmer (as you can tell), so working with databases and all of that would all sort of be new to me...I'm just dreading all this progress we made fixing all these bugs would be all for naught once I upgrade.

blackeyed5:

That first part about the src=" .. ", I'm not sure what you mean. But essentially you're saying I should just leave it as mixed content? I'm just worried about visitors seeing that warning sign about the SSL and thinking the site is "unsafe".

I'll check out the link you sent about upgrading tomorrow. I'm not really a programmer (as you can tell), so working with databases and all of that would all sort of be new to me...I'm just dreading all this progress we made fixing all these bugs would be all for naught once I upgrade.

No, not saying to keep/allow mixed content. Saying be sure that the thngs being changed are the cause of the mixed content... So, I admit that I don't use every browser available, but I do test out several and maybe one of them needs updating but I don't know of any/seen any that once the page is loaded and before a click on a link complain that the page contains say the following between the body tags of a page loaded with https:

<a href="https://www.google.com">Secure</a><br />
<a href="http://www.google.com">Non-Secure</a><br />

Now, perhaps upon clicking the above Non-Secure link it will notify about the pending change from secure to non-secure, but that is a transition notification that if anyone has turned on more than likely understands what is going on and what/when to expect such notifications. (Or your site is the first one that they have visited after installation of the new browser...

Anyways, I feel that I went off somewhere, so the thing that is first important in going down the path of making the secure icon stay solid/appear is that the changes being made are/have been identified as affecting the indicator. One typical html tag that has an effect on the mxed content notification is the use of images that reference the alternate connection type in the src= portion of the tag... To keep that "connection typeless" it caan be entered as //siteurl/path/filename. Or as a relative path of folderpath/filename.

Now the other thing though that I was talking about. The htaccess rule for the shop subdirectory to force all connections to https is unnecessary if in includes/configuration.php HTTP_SERVER already includes https:

As to the upgrade. One great thing about ZC is that if properly setup and maintained, generally speaking changes made to the site are made only to template override directories. This allows upgrade of the underlying core files without directly affecting the template files... Now, after or as part of that underlying upgrade the template override files should be compared to the base version of the same files to identify/incorporate applicable/needed changes to ensure continued operation. In other words if upgraded/rebuilt by the instructions provided in this site (mainly the link to follow) your work to date will be preserved...

http://www.zen-cart.com/entry.php?3-How-do-I-rebuild-my-site-on-the-new-version-instead-of-upgrading

mc12345678:

No, not saying to keep/allow mixed content. Saying be sure that the thngs being changed are the cause of the mixed content... So, I admit that I don't use every browser available, but I do test out several and maybe one of them needs updating but I don't know of any/seen any that once the page is loaded and before a click on a link complain that the page contains say the following between the body tags of a page loaded with https:

<a href="https://www.google.com">Secure</a><br />
<a href="http://www.google.com">Non-Secure</a><br />

> 
> Now, perhaps upon clicking the above Non-Secure link it will notify about the pending change from secure to non-secure, but that is a transition notification that if anyone has turned on more than likely understands what is going on and what/when to expect such notifications. (Or your site is the first one that they have visited after installation of the new browser... 
> 
> Anyways, I feel that I went off somewhere, so the thing that is first important in going down the path of making the secure icon stay solid/appear is that the changes being made are/have been identified as affecting the indicator. One typical html tag that has an effect on the mxed content notification is the use of images that reference the alternate connection type in the src= portion of the tag... To keep that "connection typeless" it caan be entered as //siteurl/path/filename. Or as a relative path of folderpath/filename.
> 
> Now the other thing though that I was talking about. The htaccess rule for the shop subdirectory to force all connections to https is unnecessary if in includes/configuration.php HTTP_SERVER already includes https:
> 
> As to the upgrade. One great thing about ZC is that if properly setup and maintained, generally speaking changes made to the site are made only to template override directories. This allows upgrade of the underlying core files without directly affecting the template files... Now, after or as part of that underlying upgrade the template override files should be compared to the base version of the same files to identify/incorporate applicable/needed changes to ensure continued operation. In other words if upgraded/rebuilt by the instructions provided in this site (mainly the link to follow) your work to date will be preserved... 
> 
> <http://www.zen-cart.com/entry.php?3-How-do-I-rebuild-my-site-on-the-new-version-instead-of-upgrading>


I may end up just starting over. Since all the updates I made are here for reference, might not take that long since I know what the solutions are.  If that's the case, will I run into any issues having SSL BEFORE installing zen cart?

blackeyed5:

I may end up just starting over. Since all the updates I made are here for reference, might not take that long since I know what the solutions are. If that's the case, will I run into any issues having SSL BEFORE installing zen cart?

Now that you have verified that SSL is setup properly on your host, no there is no issue with installing ZC and identifying to ZC that you have SSL enabled...

If such testing had not occurred, then I would have suggested installing with SSL considered disabled, then attempted to go to the various pages (manually entered) with https as the prefix... This way (more of an issue in a live site) if going to the page worked, then it indicates that the SSL works.. If not, then would need to get with the host... If the store was first enabled with SSL and it didn't work, well, then anyone visiting those pages would be greeted with basically nothing. :)

Better to have a customer browse and know that their security is being looked after (ie. disabling purchasing but allowing them to look while troubleshooting SSL) than to have a customer be greeted with a blank screen or some other form of error indicating that the store is not being managed...

Anyways... It is your business, hopefully you are looking out for making the profit you deserve with whatever decision(s) being made...

Let me add that understand if you follow the process previously provided, you are in a sense starting over, but without all of the database work (ie. adding product, making changes to settings, etc...) as it primarily addresses the files and then gives a process to make the database up-to-date with the new version...

That's the REALLY simplified explanation of the instructions. :) (Don't cut corners though...)

mc12345678:

Let me add that understand if you follow the process previously provided, you are in a sense starting over, but without all of the database work (ie. adding product, making changes to settings, etc...) as it primarily addresses the files and then gives a process to make the database up-to-date with the new version...

That's the REALLY simplified explanation of the instructions. :) (Don't cut corners though...)

Yeah, that's what I gathered from the instructions. Since I don't have any products up yet or any real database info I need to keep, it might just be easier to start completely over so there are no issues. Thanks, I'll do that this weekend. I don't manually have to make any initial changes to the files for SSL besides choosing that option in the admin screen when setting up the cart?

You won't need to modify the includes/configure.php and admin/includes/configure.php to support the SSL if during installation you use https type links when answering the questions asked during installation... Now if you install the template again fresh, you will more than likely need to make the same change in the same file again.. Or (again depending on how you do your "rebuild") if the template is installed, then you could copy the template files from the old install to the new one...

Again just answer the questions asked with the end goal in mind.