Validation of checkout form fields? (2.0 Foxycart)

carlos123carlos123 Member
in Help edited October 2014
Hi there,

I've been looking around at the various documentation pages on your site and Googling to try and figure out whether forum field validation under 2.0 is my responsibility or FoxyCart's and how to do it if it is mine.

It seems that validation is up to me. Is that right?

With respect to how to do it (at least with respect to how to do it under FoxyCart) it it's a bit confusing. There is a PHP script that can apparently be used under certain cases (https://github.com/FoxyCart/FoxyCart-Cart-Validation--PHP). https://wiki.foxycart.com/v/2.0/checkout talks of custom fields validation but says nothing about validating the fields that come by default on the checkout. I've read about an fc_PreProcess() Javascript function in older documentation and how to use that but I think, if I am not mistaken, that such is under older versions of FoxyCart and doesn't apply to 2.0.

Anyway...lots of different things said in various places which leads me to wonder how it's supposed to be done under 2.0.

Today I discovered that I can input whatever number I want into the phone number field on the checkout page. Even numbers that are longer than a phone number would normally be. So I can put in 10 digits, 15, or even 30 (perhaps even more) and FoxyCart will seemingly accept such phone numbers just fine.

I can even enter letters instead of digits into the phone number field.

Obviously there is next to no phone number validation.

If validation is completely up to me...that's fine. I can work with that and will use whatever validation technique is to my liking (probably the JQuery validation plugin) but I am just wondering if there is a suggested way to accomplish validation through FoxyCart 2.0 is all or if it has built in validation that can be used and relied on for fields like the phone field.

Thanks.

Carlos
Comments
  • fc_adamfc_adam FoxyCart Team
    @carlos123,

    Good question.

    We do have validations on the checkout fields that appear out of the box to varying degrees. At the most basic, we validate for the presence of some sort of value for required fields. For the postcode field, if the postcode lookup option is enabled, we validate the entry in that field for the postcode structure of the selected country if we know it. We also have some validations on the email field to ensure it's a correctly written email - although we have some improvements coming to that too in the future. We also apply validations to the credit card field to ensure that it matches a valid credit card numbering format.

    Apart from that, we generally allow whatever information is needed to be entered into those fields.

    If you wanted to apply custom validations to default fields - you can approach that a couple ways. The information detailed on the wiki is definitely one way to approach it: https://wiki.foxycart.com/v/2.0/checkout#adding_custom_validation_to_your_checkout - and although it does talk about custom fields - the process would be exactly the same for a field that is there by default.

    You could also add a custom jQuery handler to the phone field directly, triggering off any changes to the field to validate it. One thing to note, with how our re-rendering of the templates function, you want to ensure that your handlers are dynamically applied to the element rather than directly applied. So rather than doing something like "jQuery("#someInput").on("change", function() {})" you would do something like "jQuery("body").on("change", "#someInput", function() {})". The difference there is the first handler would be lost when the element is re-rendered on the page, but the second would allow the change event to bubble up to the body and be captured there.
  • Thanks very much Adam. Excellent input once more.

    I will carefully review the two approaches you mention and settle on one.

    I am a bit surprised that the phone field is not at least minimally validated by default within FoxyCart. I mean in one sense I can understand why it might not be stringently validated since phone numbers are definitely not the same in format throughout the world.

    But to have no apparent validation to making sure that letters and other characters which are found nowhere in any kind of phone number (that I am aware) enters the field, seems a bit lax to me.

    Anyway...thanks again for the input Adam.

    Carlos
  • fc_adamfc_adam FoxyCart Team
    @carlos123,

    As you mentioned - there is a large variety of different formats that a phone number can take, so we've erred on the side of caution. As a quick example, some people may need to specify an extension, which can take a format like "123456789 x123".
  • Hmm...I didn't think about the extension abbreviation being a letter like 'x'. I'll have to see what I can do about coming up with a robust validation that is broad enough to encompass the characters that could be included.

    Out of curiosity do you know what kind of validation other reputable shopping carts use for phone number fields?

    DBase III+ (a old RDBMS database) used to use a format that allowed entry of digits in the appropriate places separated by '-' and '(', ')' but that was only useful for U.S. (possibly Canadian) phone numbers.

    But that old format would also be disqualified I think in that many countries don't use these characters in the same place within a valid phone number as the U.S. does.

    Carlos
  • fc_adamfc_adam FoxyCart Team
    @carlos123,

    Off hand I'm not familiar with how other shopping carts approach it sorry.
  • No problem Adam. Thanks.

    Carlos
  • @carlos123 - I know this post is a few years old but I think I found a solution... kinda.

    via http://stackoverflow.com/a/43750670

    (Make sure to substitute "input[type='tel']" for "#shipping_phone, #billing_phone" in the code from SO.)

    The only issue I'm running into now is that it only works on form fields that are visible on the page load. So typically that's just the shipping phone number, unless checking the 'Use a different billing address' box and reloading then both will work. Without the reload, billing phone will not format correctly.

    --

    FoxyCart Team (or anyone jquery experts): Any thoughts as to why it only works on input fields that are initially loaded?
  • foxyusercartfoxyusercart Member
    edited May 22
    The validations of the form controls are doing using jQuery. I found this via this jQuery Validation resource on the net. @davehenning for the controls that are not initially loaded that is they are built dynamically.

    In that case you have to use the .on keyword for dynamically built controls via http://stackoverflow.com/questions/203198/event-binding-on-dynamically-created-elements
  • fc_adamfc_adam FoxyCart Team
    @davehenning,

    As mentioned in the previous post there, the billing field is being dynamically rendered on the page - so any click events that are bound directly to elements on page load won't apply to the new elements. You can get it to be register dynamically though using the on() function and binding to a parent element that can capture the click events when they bubble up. Using the code from the solution you found, it could look like this:
    $("body").on("change keyup paste", "#shipping_phone, #billing_phone", function (e) {
    var output,
    $this = $(this),
    input = $this.val();

    if (e.keyCode != 8) {
    input = input.replace(/[^0-9]/g, '');
    var area = input.substr(0, 3);
    var pre = input.substr(3, 3);
    var tel = input.substr(6, 4);
    if (area.length < 3) {
    output = "(" + area;
    } else if (area.length == 3 && pre.length < 3) {
    output = "(" + area + ")" + " " + pre;
    } else if (area.length == 3 && pre.length == 3) {
    output = "(" + area + ")" + " " + pre + "-" + tel;
    }
    $this.val(output);
    }
    });
    Worth noting - that solution doesn't seem to work with pasting for me
  • @fc_adam thanks for that.

    That works just fine.

    You guys are great.
Sign In or Register to comment.