OpenCart Community

Hi
Does not accept any email that contains Dash (-)
For example:
abc-123@abc.com
E-Mail Address does not appear to be valid!
opencart_V_1.4.9.1
Thank you

Please help
Emails many visitors are not able to register

Confirmed.

1. EDIT the following files:
catalog/controller/account/create.php
catalog/controller/account/edit.php
catalog/controller/checkout/guest_step_1.php
catalog/controller/information/contact.php
catalog/model/checkout/order.php
admin/controller/sale/customer.php
admin/controller/sale/order.php
admin/controller/setting/setting.php
install/controller/step_3.php

2. FIND: 3. REPLACE WITH:

Thank you very much Mr.Qphoria

Part of the problem has been resolved
but Still the problem with some Emails like :
abc123@w.cn

Thank you very much

While this pattern is not 100% working and this bug shows that important functions (which email validation is) should be stored at one place (and not several), Q forgot one (a very important):

../catalog/controller/information/contact.php

OSWorX wrote:While this pattern is not 100% working and this bug shows that important functions (which email validation is) should be stored at one place (and not several), Q forgot one (a very important):

../catalog/controller/information/contact.php

I've searched around for the holy grail of email regex.. still not found one.
But I was a step ahead with the one place pattern. The day I made this fix I checked in a change to define the pattern once and use that constant. That will be in effect for 1.5.0

Makes me wonder why bother with the email regex validation. People can obviously still come up with fake addresses, and what do we really care if they put non valid information in there as long as you properly escape it before inserting it into the database. for that matter seems like you could just check to make sure it contains @ and be done with it.

Believe me, using only one pattern will never work as expected - as can be found at many places where users are crying for help because of missing emails.
This check should be done via a function where I can check many things in different ways.

I for myself did this - in the controller, and it shows me that all wanted emails are passing through as they should.
Imagine, you want to refuse emails from a specific host once.
Adding this to a definition will never work (because it is defined fix), adding this to the function is just one line.

But that goes now beyond the topic.

Xsecrets wrote:Makes me wonder why bother with the email regex validation. People can obviously still come up with fake addresses, and what do we really care if they put non valid information in there as long as you properly escape it before inserting it into the database. for that matter seems like you could just check to make sure it contains @ and be done with it.

Right.. well i think it is more for error correction in the case where a customer mistyped their email, more than checking for fakes. But yea as long as its x@x.yy that should suffice, where x can be any character, dash, and y can be any character or period

Qphoria wrote:

Xsecrets wrote:Makes me wonder why bother with the email regex validation. People can obviously still come up with fake addresses, and what do we really care if they put non valid information in there as long as you properly escape it before inserting it into the database. for that matter seems like you could just check to make sure it contains @ and be done with it.

Right.. well i think it is more for error correction in the case where a customer mistyped their email, more than checking for fakes. But yea as long as its x@x.yy that should suffice, where x can be any character, dash, and y can be any character or period

if you are really worried about typos in the email just make them type it twice and compare them. otherwise you are stuck trying to come up with crazy regex patterns. even in what you said above you would have to amend x to any character, dash, period, plus, and who knows what else.then y would also have to allow for dash since some domain names use them. and in the end it really doesn't accomplish much. Not too many typos will be caught by it anyways. I mean I can see why people have it, but it just seems like alot of work with little to no reward to me.

Xsecrets wrote:if you are really worried about typos in the email just make them type it twice and compare them.

This is something that should be implemented in 1.5.x!

Hi,
I am patching 1.4.9.1 and on admin/controller/sale/order.php. I can't find the old line of code so I don't know where to place the new code $pattern = '/^[A-Z0-9._%\-+]+@[A-Z0-9][A-Z0-9.-]{0,61}[A-Z0-9]\.[A-Z]{2,6}$/i'; I looked the file over several times.
In install/controller/step_3.php I went back to install folder for 1.4.9 is that where I add the code? I'm kinda confused on this point
Thanks

Look for just $pattern and follow there

i did on admin/controller/sale/order.php, and also scrolling from the top to the bottom but i'm not get lucky, its seem hiding in other place or perhaps do i have different? 1.4.9.1

I'm in agreement with the above gentleman; there's no $pattern = '/^[A-Z0-9._%-+]+@[A-Z0-9][A-Z0-9.-]{0,61}[A-Z0-9]\.[A-Z]{2,6}$/i'; at admin/controller/sale/order.php on my end.

i agree with Xenn above.
can't find any "pattern" inside the order page.

and my "install" directory seems to be missing

aaron-commerce wrote:i agree with Xenn above.
can't find any "pattern" inside the order page.

and my "install" directory seems to be missing

Hi guys, there is the same '$pattern' variable in this file that may be the one you need to change also in:- catalog\model\checkout\order.php

Also you're install dir is best to be missing if you are talking about a live shop as not needed once installed to a server!

Cheers.

ah.. that' right

dmin/controller/sale/order.php does not exist on 1.4.9.1

jefrey1983 wrote:dmin/controller/sale/order.php does not exist on 1.4.9.1

Right, it must be:

admin/controller/sale/order.php