Contact Us emails failing validation

[mikestaps]

Sort of waiting for a response to that question; however, was also thinking, you were having this issue on both your production and test stores. Did the drop down version of the contact us menu have the same selection list as is available on your contact us page? Also do you have it setup with the "name" <email address>? or is it just email address? I thought one of the other setup attributes was to have both parts provided in the store's setup for the Set "Contact Us" Email Dropdown List selection. (Seeing that you do have a drop down list selection, though that doesn't address the automatic emails that are not being received.)

Drop downs for both sites are the same, and emails are set to "name <address>".
It is looking like the not receiving order conf. emails is due to email provider blocking. The "boss" won't give up his beloved AOL email, and AOL is blocking stuff even without filters set to do so.
I added another address to the order conf. send to list and it's working fine. Also turned on email archiving, order conf. emails are sending fine, just not getting through AOL. Hopefully this will be the straw that breaks the camels back and I can get him to ditch the AOL!!!

Thanks for all of the help and ideas!

[Limey]

I have something similar. Emails fail validation from the 'contact us' form and quick-contact header, but emails get through from the admin >Tools > send email. I deduce that it's not a server/hosting issue from the latter, but am failing to find what it might really be. Might it be some issue with the template or its implementation of Megamenu????

v1.5.1

error log "[31-Jan-2014 12:16:05] ERROR: Failed sending email to: "" <> with subject: "Website Inquiry from ** **" (failed validation)"

email_debug.php is not activated from the contact options, but is from: Admin >Tools > Send Email

Thanks

[mc12345678]

I have something similar. Emails fail validation from the 'contact us' form and quick-contact header, but emails get through from the admin >Tools > send email. I deduce that it's not a server/hosting issue from the latter, but am failing to find what it might really be. Might it be some issue with the template or its implementation of Megamenu????

v1.5.1

error log "[31-Jan-2014 12:16:05] ERROR: Failed sending email to: "" <> with subject: "Website Inquiry from ** **" (failed validation)"

email_debug.php is not activated from the contact options, but is from: Admin >Tools > Send Email

Thanks

That type of log has been what I have seen when a bot/user tries to "spoof" the system to try to send email. Regarding the template's implementation, yeah it probably isn't including the recent updates made to v1.5.1 that were incorporated into the contact us and sign-in/new user pages. There are some suggestions earlier on in this thread about coding that could be applied, and there are many others around as well. I modified the response of the mega_menu to hide the contact us drop down when otherwise on the contact_us page, and to incorporate the changes made in v1.5.1 of ZC. I have seen another do something similar, but what they did was to first take the information entered at the drop down, and enter it on a newly loaded page, to have the user make some more selections and then submit the contact us form for a sort of second set of validation. I believe I saw this one described in the responsive sheffield blue template thread posted by another user. Please remember, posts should be associated with the primary topic of the thread. So, if/when visiting that thread further discussion on this aspect probably should be taken to a thread different than the thread on that template.

All that said: do you get that type of error when you personally test the contact us page from the website? Or is that just an error log that has been received and considered to have been a problem with the contact us page because of knowledge of other "variables"? (Ie are you able to send a message from the store/reproduce the problem?)

[Limey]

All that said: do you get that type of error when you personally test the contact us page from the website? Or is that just an error log that has been received and considered to have been a problem with the contact us page because of knowledge of other "variables"? (Ie are you able to send a message from the store/reproduce the problem?)

Yes the same error when I personally test the contact us page. ie I can't send messages from the store.

[mc12345678]

Yes the same error when I personally test the contact us page. ie I can't send messages from the store.

How about if you change back to the classic template... Does email sending work from contact us page? Might indeed have something "different" between the two sets of files (the override file for your template and the default version of the same file.) I would start with the file first, and deal with the mega-menu afterwords. It is something of an imitation of the file, and worst case can be disabled but still have a contact us form. Have you previously tried to install anything like recaptcha, but then not fully removed it or copied over the files from one template to the other?

[RixStix]

[31-Jan-2014 12:01:45] ERROR: Failed sending email to: "MYDOMAINeditedFORsecurityReasons.com" <> with subject: "Website Inquiry from DomainNameRemoved.com" (failed validation)

Have you setup your
Admin: Configuration: Email Options => so that you have valid email addresses in all the proper places?

Not saying that's the only problem but I can duplicate that error message which I copied from the /logs folder after removing the email addresses from the configuration.

[Limey]

[31-Jan-2014 12:01:45] Have you setup your Admin: Configuration: Email Options => so that you have valid email addresses in all the proper places?

Thanks again. I resolved it by getting a different 'definitive' answer from the hosting support compared to the one I had yesterday - and it was to do with their settings. If I weren't so glad to have sussed it I could have been irritated. Thanks to all.

[Limey]

Thanks, It was the host's setting after all. I got different guidance than before and I'm back in business. Many thanks tho'.

[mc12345678]

Thanks, It was the host's setting after all. I got different guidance than before and I'm back in business. Many thanks tho'.

So to confirm, there was no setting that an operator of a ZC store could correct without the assistance of the host making some sort of server change. Is that correct?

[lat9]

So to confirm, there was no setting that an operator of a ZC store could correct without the assistance of the host making some sort of server change. Is that correct?

And, if that's the case, letting everyone know what settings had to be changed might help someone in the same situation in the future!