Error: State can not be blank.

cheesypoofcheesypoof Member
in Bugs & Feature Requests edited May 2014
Over the last 2 days I have seen 40 "State can not be blank." errors reported in my admin. This store just recently launched, so I can't reference any history to know if this is a regression. From what I can see, in the vast majority of these cases, all of the other information has been filled out. It is literally only customer_state and customer_state_name that are empty (besides the optional shipping_* fields). I refuse to believe that these customers are inept enough to leave the 'State' field blank. This must be a client-side JavaScript issue... Are you certain there is no issue on your end? Any ideas?
Comments
  • fc_adamfc_adam FoxyCart Team
    @cheesypoof,

    There is a small bug in our validation when the checkout is submitted - which relates to how we validate a state field being left blank when it's required. Particularly, while it's marking the field as being in an error state, it's not preventing the checkout from submitting - so our server-side validation is throwing the customer back to the checkout with the 'state can not be blank' error.

    Why you're seeing your customers returning that error though - I believe you're right in that they're not just skipping over the state field. What I think might be the cause here is those particular customers have used some sort of auto-fill plugin which isn't auto-filling the state field. The customers aren't picking up that the state didn't autofill and as such they're running into this issue.

    Looking through your error log, I'm not seeing any customers that haven't completed their order after seeing this particular error, so that's some good news. I'll see if there is some quick code you could add to your checkout to work around this issue until we're able to patch it on our side completely.
  • Thanks for looking into this. I do hope this will be addressed by FoxyCart relatively soon... I imagine this bug produces a significant percentage of the error logs across all of your stores, contributing to a general decline in usefulness of said logs.

    I'll look at your JS validation overrides, but I'm a bit reluctant to utilize it. I can't risk any type of disruption in checkout functionality over the next two weeks. Thanks again.
  • I agree. Out of 57 items in my message log, 35 of them are "State can not be blank."

    Even though many customers are going back and fixing it, it's not a good customer experience.

    Steve
  • I am still seeing these errors appear daily in the error log. Any ETA for a fix?
  • fc_adamfc_adam FoxyCart Team
    @cheesypoof,

    Sorry - our focus has primarily been on finalising 2.0 recently. Thanks for bumping this thread. I'll push it up my todo list to get a fix sorted so we can hopefully get something up onto production soon. Unfortunately I can't give you an ETA on this.
  • eded Member
    We lost about a dozen sales due to "State can not be blank" error. We need a resolution ASAP.
  • fc_adamfc_adam FoxyCart Team
    @ed,

    Thanks for bumping the thread. I've just taken a quick look at your stores error logs, and for what it's worth, I'm seeing all customers that have bumped into this issue still completed their transactions. Not to belittle this issue though, it's still something we're looking to get fixed as soon as we can.
  • I am still seeing these errors; it would be great if this issue could be addressed in 1.1...
  • fc_adamfc_adam FoxyCart Team
    @cheesypoof,

    Is there any chance you could upgrade the store to 2.0? This issue is resolved in that version.
  • I do plan to migrate this store and a few others to 2.0, but it probably won't happen for another 6 months...
  • brettbrett FoxyCart Team
    @cheesypoof, is this issue actually impacting sales, or is the issue more that it's filling up the error log? Last we looked it seemed like it wasn't causing any problem with the sales, but I want to make sure we're prioritizing it appropriately if it is.
  • If I were to estimate, 25% of my error log entries are caused by this issue. I find that aspect of it to be merely an annoyance and inconvenience. I don't want to spend time sifting through irrelevant errors such as those caused by a user's innocent mistake.

    This is slightly off topic, but there really should be some type of categorization of errors. For example, is "The passwords you entered do not match" really a noteworthy event - even remotely comparable to a DataFeed failure or a minFraud rejection?

    In fairness, I do think it is minimally impacting sales. Some (~10+) of the checkout sessions did not end up producing transactions where this was the only error encountered. It would not be a deal breaker for me if you decide not to fix this in a reasonable time period. I suppose I would just be somewhat disappointed because your stance would boil down to "Upgrade to the latest release; we don't patch legacy version bugs."
  • brettbrett FoxyCart Team
    @cheesypoof, agreed wrt categorizing errors. We've talked about different alerts for errors like "your gateway credentials are wrong", since that in particular indicates a major problem, but we haven't been able to prioritize that yet.

    We'll see what we can do on this particular error, especially if it looks to be impacting sales. We do eventually stop patching older versions, but we're still patching things on v1.0 and 1.1 when it's doable.
  • fc_adamfc_adam FoxyCart Team
    @cheesypoof, @spidercreations, @ed,

    A quick follow up for this thread - we recently pushed out a fix for this issue for 1.1 to correctly capture validation errors for the state field to prevent this error being triggered. I'm sorry it took us so long to be able to correct this for you all - thanks for bringing it to our attention and reminding us that it was a persisting issue as well.
Sign In or Register to comment.