Contact Us, Prestashop 1.6, via Mobile Phone does not work at all

[jetx]

Two stores, version 1.6.0.6 and version 1.6.0.9 (default templates). Both stores contact us forms are not sending emails when sending via mobile phone. Tested with iphone 4S, windows phone 8. Works on a Windows Surface, but not mobile phone. Tested over wifi and 4G. tested using both php mail and SMTP.

When sending the form indicates "Your message has been successfully sent to our team". But this is not the case, not in spam box, the sender receives no notification, neither does the team (nor through BO).

It just does not work. Can anybody confirm whether they can successfully send a contact us form via mobile phone?

This is quite urgent as a good percentage of my customers are shopping via phone, so need a solution. Thanks in advance.

[jetx]

Also tested on version 1.6.0.11. Same issue. This appears to be a bug.

[martinrebo]

Hi,

 

I´m having the same problem with my shop, and so far this is the first post I found about the issue. The Form in contac-us, is working perfectly well on desktop (explorer, firefox, chrome and Safari). But when customers access via phone, they can´t send emails. (neither android platform nor IOS)

 

So is it related to SSL? Friendly URL´s? mail ()function PHP ? Who knows?

 

My PS version is;

 PrestaShop 1.6.0.9 

mail() function PHP

[vekia]

hello

are you able to check your server outgoing emails log?

[martinrebo]

Hello,

 

Recently I started to use Zoho Mail servers, so I´m afraid I cannot check any Log, However I think that perhaps our problem can be solved using the SMTP instead the mail() php function...

 

More info: "When you press the send button in the contact form on a mobile platform, nothing happens... nothing at all, so it seems that the button is not working on a responsive design" 

 

The link to my shop is

https://exclusivasfaro.com/tienda/contact-us

 

So im going to wait a little bit more,  just in case someone has the answer.

 

Thank you Vekia for showing interest in this post,

[vekia]

you know what?

i tested it second ago from my mobile

i received confirmation

[martinrebo]

Wow, that´s amazing

 

Yes, I tried again from Android and IOS, and it is working perfectly normal... 

 

Well, I don´t have a explantation for that, but I feel so relieved that it is working. Thank you very much Vekia for helping me, I really appreciate it, 

 

I guess we can say Problem Solved !! (But the mystery remains unsolved..., perhaps the Mail servers?)

[jetx]

Actually, just went back to using the built in contact form and see the problem still persists. In the exceptions log I see the following entries which I expect relate to the problem.

 

*ERROR* 2015/09/30 - 10:12:48: Data too long for column 'user_agent' at row 1<br /><br /><pre>INSERT INTO `customer_message` (`id_employee`, `id_customer_thread`, `ip_address`, `message`, `file_name`, `user_agent`, `private`, `date_add`, `date_upd`, `read`) VALUES ('0', '15', '1854805572', 'Testing this module for issues', '', 'Mozilla/5.0 (Linux; Android 5.1.1; R7g Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.94 Mobile Safari/537.36', '0', '2015-09-30 10:12:48', '2015-09-30 10:12:48', '0')</pre> at line 765 in file classes/db/Db.php

*ERROR* 2015/09/30 - 12:31:19: Field 'id_customer' doesn't have a default value<br /><br /><pre>INSERT INTO `ganalytics` (id_order, id_shop, sent, date_add) VALUES (8143, 1, 0, NOW())</pre> at line 765 in file classes/db/Db.php

*ERROR* 2015/09/30 - 12:57:05: Data too long for column 'user_agent' at row 1<br /><br /><pre>INSERT INTO `customer_message` (`id_employee`, `id_customer_thread`, `ip_address`, `message`, `file_name`, `user_agent`, `private`, `date_add`, `date_upd`, `read`) VALUES ('0', '15', '1854805572', 'Testing this mesdage thing.', '', 'Mozilla/5.0 (Linux; Android 5.1.1; R7g Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.94 Mobile Safari/537.36', '0', '2015-09-30 12:57:05', '2015-09-30 12:57:05', '0')</pre> at line 765 in file classes/db/Db.php

[jetx]

So the fix for this issue, in case anyone else experiences it, is because too many characters are being entered via the useragent. The fix was to increase the varchar limit for user_agent from 128 to 256 in the customer_message table.