A client has requested that I have a field in a form that asks the user to repeat the email address already entered, and then compare the two, only allowing the form to be submitted once the two match.
I have mulled over whether to explain that having a telephone number field would be enough without the check if an incorrect email address were entered, or that having a non-checking repeat field is better, as one of the addresses is likely to be correct, as opposed to both potentially being wrong if they have to conform to each other.
Is there an easy – stress on easy – way to do this using the standard ‘PHP Feedback Form’ (version 2.4.7 on FW 7.1.1? I’m capable of adding snippets of code to things given clear directions, and any help would really be very much appreciated.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
Hi Ian,
Version 2.4.6 and above of the Action contains a function that looks for a text field called ‘emailconfirm’ and checks this against another field called ‘email’. If the values fail to match then the user will be redirected to the error page.
Simply add a copy of your ‘email’ field to the form and call it ‘emailconfirm’ and you should be set.
That should be easy enough!
Regards,
Tim.
On 2 Dec 2015, at 12:38, Ian Halstead email@hidden wrote:
Is there an easy – stress on easy – way to do this using the standard ‘PHP Feedback Form’ (version 2.4.7 on FW 7.1.1? I’m capable of adding snippets of code to things given clear directions, and any help would really be very much appreciated.
Version 2.4.6 and above of the Action contains a function that looks for a text field called ‘emailconfirm’ and checks this against another field called ‘email’.
Tim - how is it we are just hearing about this ‘hidden’ feature now?
As an avid user of the PHPFF action I had no idea that function was available to me.
I think ‘hidden’ is a strong term to use as it implies intent to deceive. This was just one of the many features that I’ve been asked to add to the Action over the years. Some get added and documented, a lot don’t get added, but this one did and I chose not to document it simply because the current documentation doesn’t get read as it is and I didn’t want the Action to become a task in itself to understand and use. I also felt that it wasn’t a core feature. This is only the second time I’ve heard someone asking for it.
Also everyone loves surprises - especially at Christmas!
I’ve been keeping development notes on this Action since version 2.3.2 which are in the source code of the file itself. You’ll see from the list below that a lot of the development happens to code that you never get exposed to and that just runs behind the scenes.
Removed the standalone action - it wasn't doing anything useful!
2.3.3 - Fixed a case issue with special field names (name, email and subject). The action was using Name, Email etc which was throwing some servers. Names are all now all lowercase.
2.3.4 - Fixed an issue with the ini_smtp_server setting not getting set correctly
2.3.5 - Added support for targeting the form submission when defining the success or error links
2.3.6 - Fixed an issue where using the GoDaddy option didn’t correctly set the form action
2.3.7 - Added support for adding recipients via a drop down menu using the “PHP Feedback Form Recipients List” action
Moved the other actions to fwAfterEndBody so they run after the “PHP Feedback Form Recipients List” action
2.3.8 - Added support for https checking in not in domain checks
2.3.9 - Changed the encoding type of the resulting email from ISO-8859-1 to UTF-8 to allow for accented characters
Removed slashed out quotes (o'clock for example) that were appearing in the resulting email
2.4.0 - Added IP address blocking
2.4.1 - Added a fallback method to get the remote IP address if register globals is turned off
2.4.2 - Corrected a mistike where the IP address was incorrectly displayed in the resulting email
2.4.3 - Replaced eregi for preg_match in the header injection checking code as eregi is deprecated from PHP 5.3.0
2.4.4 - Added a check to see if the item action is applied to an inflow item. There appears to be a bug that causes the action applied to inflow items to create multiple copies of the -go.php file
2.4.5 - Option to ignore empty data and not echo it to the resulting email
2.4.6 - Added support for two ‘email’ fields to verify the email address is correct. Redirect if not.
2.4.7 - PHP now checks for entity encoded comments and redirects the user to the spam trap
The Action now ignores the ‘Navigation Popup’ field added by the Softpress Action of the same name
2.4.8 - The Action now checks if a valid MX record exists for the given email address and redirects to the error page if it fails to find one
The code checks for any HTML code in the comments and redirects the user to the spam trap if found
Regards,
Tim.
On 2 Dec 2015, at 20:58, DeltaDave email@hidden wrote:
Tim - how is it we are just hearing about this ‘hidden’ feature now?
As an avid user of the PHPFF action I had no idea that function was available to me.
