Contact Form Not Working
Author: James Ivey
Visited 2303,
Followers 1,
Shared 0
I'm trying to use the "Contact Form Object" page and when I try to receive an email it doesn't work. In the form there is an email address and I'm using my email address to receive the data. I read that "Maybe" I should go to the Data Management page and insert my email address in the field: Allways use the following sender email adddress. It still isn't working. I really don't know what to do at this point.
Please Advise,
James Ivey
Posted on the
It can be that your provider stops mails that are not from there own.
So use an email adres from your provider and not from another provider and see if this works.
Check also that php version at your provider is at 7.1
there are several solutions also in the help forum;
https://helpcenter.websitex5.com/en/post/216526
https://helpcenter.websitex5.com/en/post/217174
https://guide.websitex5.com/en/support/solutions/articles/44001791318-what-are-the-minimum-requirements-for-the-server-
Search X5 The search from Paul can also be very helpful
and the help itself;
https://guide.websitex5.com/en/support/home
James, Have you put something in the "subject" box, i think this may be a requirement to get the form object to work. see below this is without using a database.
Author
I'm in touch with my provider and they are looking at it. Thanks everyone for your help!!!
youre welcome,
if something other then already mentionend comes out then let us know, this can help other users in that case as well.
THX
Author
Need help, my provider doesn't find any good instructions on how to setup the program. He said to me that Incomedia hasn't provided any real good information to setup the database for receiving data form via email. He's way beyond PHP 7.1 he's 7.7 so that's not an issue. He needs a good link that can help him do what's required. I'm at the point that if I new ahead of time was was going to happen with the update that caused all this I'd not made the update!
Hello James
I would like to help you sort this out but unfortunately, the exact issue you're having isn't clear to me.
In your first message, you talk about emails. But now you mentioned that you need help to setup the database for receiving data form via email.
In order to be able to send emails correctly, there's not much configuration you need to do. Go to Step 1 -> Data management and show this list to the provider:
They should be able to tell you which of these methods they support and that is the one you need to use. If you're having issues after that, you need to check with them why the emails aren't getting sent correctly since the software doesn't handle the sending itself
Try this out and keep me posted here
Thank you
Stefano
Author
I'm sending this from my provider, I hope you'll be able to help because it's a real problem.
When sending mail from a created form the 'user' field from the form creation causes both the "TO" and "FROM" headers on the outbound mail (examples below) with the recipient of the information from the form. The problem is that the local machine is not authorized to forward mail as a GMAIL user, so the email is rejected. Normally one would sent the form data From a local account to a foreign account (such as gmail). I would expect the tool to have a place to specifiy a default "FROM" address. This is often something like '***' to prevent accidental replies from cluttering up a mailbox. Using a local user then allows the traffic, but then you can only send the form to a domain local account.
2020-11-20 13:51:35 1kgDNW-0005X1-5y ** *** R=router_from_cfns T=transport_remote_smtp H=d111030.o.ess.barracudanetworks.com [209.222.82.100] X=TLS1.2:ECDHE_RSA_AES_256_GCM_
SHA384:256 CV=yes DN="C=US,ST=California,L=Campbell,O=Barracuda Networks\, Inc.,CN=*.ess.barracudanetworks.com": SMTP error from remote mail server after RCPT TO:<***>: 550
sender rejected
Received: (nullmailer pid 19753 invoked by uid 33);
Fri, 20 Nov 2020 21:21:11 -0000
To: "***"<***>
Subject:
Date: Fri, 20 Nov 2020 14:21:11 -0700
From: "***"<***>
Message-ID: <***>
X-Mailer: PHPMailer 6.0.7 (https://github.com/PHPMailer/PHPMailer)
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="b1_Wrz22kMBjqAeMFz3XGLveHw4OOKcRc8PNgOnppBoRyU"
Content-Transfer-Encoding: 8bit
Received: (nullmailer pid 19762 invoked by uid 33);
Fri, 20 Nov 2020 21:21:17 -0000
To: "***"<***>
Subject:
Date: Fri, 20 Nov 2020 14:21:17 -0700
From: "***"<***>
Message-ID: <***>
X-Mailer: PHPMailer 6.0.7 (https://github.com/PHPMailer/PHPMailer)
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="b1_qtPAKIXdrDerPwRPrUA1BbydHRZE7Boa9bqYjLi6OA"
Content-Transfer-Encoding: 8bit
Hello James,
The option that your provider refers to can be set in Step 1 Settings > Advanced > Data Management > Always use the following sender address
Please refer to the WebSite X5 help file for full details (ref: https://help.websitex5.com/en/v2020.3/pro/index.html?gestione_dati.htm)
▪Always use the following sender address: if this option is enabled, it sets the e-mail address indicated in the field as the sender of all the e-mails that leave the website. This e-mail address overwrites the e-mail address given in the options of the Contact Form Object, that of the customer placing an order through the e-commerce shopping cart and, in the Pro edition, that of the user who automatically registers to access a Members' Area in the website.
This option is useful if the provider blocks e-mails from the server that are sent by a user whose domain is different from this website: for example, an e-mail for an order from www.mywebsite.com will not be sent if the sender's address is not ***. In these cases, the problem can be solved by specifying a sender's e-mail address that has the same domain name as the website from which the e-mail leaves.
Your issue is exactly as Andre posited in the very first reply to your question:
Kind regards,
Paul
Search the WebSite X5 Help Center
in Step 1 Settings > Advanced > Data Management > E-mail form script type use this script visible in the screenshot below:
Author
My provider is in Arizona and I'm on the east coast so I've not heard from him yet on your last input. However, I would like to know why when I try and update and the PHP compatibility fails every time? He has PHP 7.7 so why is it failing?
Hi, the settings I posted above you have to enter in the WEBSITE X5 software in STEP 1 as indicated by me, your service provider has nothing to do with this.
Ops! This quote is correct not the one before
Hi, the settings I posted above you have to enter in the WEBSITE X5 software in STEP 1 as indicated by me, your service provider has nothing to do with this.
Author
Sure I found that and changed it to "Standard Script." Didn't help.
Ah ok James, I'm sorry. In so many other cases that script change had worked. I hope you can solve it as soon as possible. Good luck and greetings from Italy
James, the error message you are receiving when attempting to upload to the server has nothing to do with your current email issue. Instead it refers to the file permissions which are currently set on your designated public 'writable' folder, which is used for other Objects within WebSite X5. At the moment the file permissions are too restrictive. They should be set to '777' (rwxrwxrwx) - in this instance your nominated 'writable' folder is the root folder for your WebSite X5 project on the server.
From the help file...
You can also specify the Writing Access Folder:
▪Server folder with write access: enter the path on the server for the folder with write access (where the PHP script can write to).
Providers usually give write access to all folders on the server: if this is the case, you don't need to give the pathname of the public folder. In all other cases, contact your webspace provider for the complete public folder pathname.
You can check in the WebSite Test section of the online Control Panel whether the folder with write access, and any sub-folders inside i, actually exist and, if so, if you have write access to them (so that you can save the data
Ref: https://help.websitex5.com/en/v2020.3/pro/index.html?gestione_dati.htm
Incidentally, PHP version 7.7 doesn't exist. I am not sure what version of PHP your provider currently has installed but it cannot be that. Additionally, there is a lot more to correct server configuration than just having the appropriate version of PHP installed. But in any event this particular message is not related to PHP in any way.
Please keep us updated.