When I change the state in the billing section the focus moves to the city field in the shipping address section and the value of the billing state field changes to value from shipping state. I cannot change billing state. I don’t know what can cause this ater 4.16.1 upgrade
3 Likes
2 Likes
I am having similar behavior. When checking out and clicking the My billing address is different from shipping address, when trying to change the state to the correct state for shipping address, it will not change and reverts to the state for the billing address.
If I click on the shipping option to try to move forward, then it unchecks the My billing address is different from shipping address and then there is only the one address.
The State fields are interconnected somehow where the shipping address takes the State from the Billing address and does not let you enter a shipping address State if you have a billing address entered.
Orders have significantly dropped because of this, and I have had one customer email and say that this is happening.
It will not allow a checkout with a different billing and shipping. Customers do not place an order since the checkout is messed up.
Please help as this needs to be fixed right away.
1 Like
Both of my fields are showing correct. The billing state has the b_state name and shipping state has the s_state one.
1 Like
I did have to edit the names in MyPHPAdmin after upgrading to v4.16.1 as recommended in this thread,
Email Address Issue in Orders - #3 by ecomlabs - (Thanks, Ecomlabs)
I only changed what was recommended and nothing else and it fixed that particular issue. I’ve probably had this billing address State issue since then but did not know about it, only the decrease in orders I chalked up to Google changes.
- I’ve submitted a Help Desk Ticket.
This will be fixed in next version, meanwhile this diff file will fix it.
checkout_focus.diff (1.1 KB)
You can implement a diff file per these instructions
I got a reply from the Helpdesk. It is a bug and they are working on it. It will be fixed in the next version.
I came back here to see if there was anything else posted and seen this diff file. Thanks!
But… I implemented the file by placing in my root and using the command line, I followed the instructions from the 4.16.X documentation.
This did not fix the issue. I manually checked the file and seen that the parts of the file that were supposed to be changed, were changed like they were supposed to. So, the diff file did do the changes.
However, on my shopping cart, you can not enter a state for a different shipping (deliver to) address. The deliver to state changes to whatever you have in the billing state field. If you change the billing state, it automatically changes the deliver to state.
www.tbotech.com is the store to try out the check out after the .diff file was applied.
Another thing happened after I patched the file. Since the year 2000, I have used the page extension .htm. not .html I always have to change the /app/addons/seo/init.php file to update the store to show my correct URLs to end in the .htm extension.
Not a big deal to do that, but I had to go back to that separate file after the patch to change my extension back to .htm from the default of .html
I wasn’t expecting to have to change that since I thought only the /js/tygh/checkout/lite_checkout.js file would be changed.
So bottom line is this file didn’t work for me. Any ideas?
I don’t know if it’s just specific installations of CSC, but with this being confirmed as a bug and will be fixed in the future, this leaves everyone on 4.16.1 in the same boat as not being able to take orders when a customer wants to ship to a different shipping address than their billing address. I could be wrong, but that’s how it sounds to me.
I’d really like to get this fixed and if there are any other ideas or what could have gone wrong with the diff file, I’d appreciate it.
Thanks chickentwisty for the file! Could it be something else also?
I did clear cache, deleted the folder from the server.
I’ve deactivated the Billing Address Block within the Design/Layout under the Checkout Tab. Now there is only one address that can be entered. This is my “fix” for now and I’ll see how it goes with customers.
This is the diff file gave me about two weeks ago to the bug you described, i hadnt implemented it as i don’t actually have any customers, i will feed your feedback to the helpdesk.
Now changing billing state doesn’t change focus to shipping city ,as expected, but when it gets focus first time shipping methods are reset and there is a scroll to “Enter city and state and click here to update shipping rates” message. A default state in settings fix this.
In my opinion, lite_checkout.js needs refactoring. There is a need to separate country/state/city handling based on shipping/billing section fields. Maybe more code but easy to test/fix.
For me as a quick fix until the release of the new version worked to override the file
views/checkout/components/profile_fields/field.tpl
and comment all the lines
#before
data-ca-lite-checkout-element="{$element_name_helper}"
#after
{*data-ca-lite-checkout-element="{$element_name_helper}"*}
I hope the above is useful to you.
I replaced the field.tpl file with the one from free version and now works as expected.
I downloaded the free version and replaced the field.tpl file and it did not work for me. So I downloaded the paid version from the helpdesk and replaced the field.tpl file again so it is the latest version, and it still did not work either. (I wasn’t expecting it to, but thought I’d try)
@hungryweb, I’m just confused about what you’re recommending. I found that one occurrence of the line you posted. It’s on line 11 in my file.
Could you elaborate on what it is you did? Just comment out that one line? What should it look like? Like the below, as you have it?
{data-ca-lite-checkout-element=“{$element_name_helper}”}
Is it just editing this one line?
Edit: when I pasted the one line in this post, it took out the asterisks that you have there.
Go to Administration → Storage → Clear cache or delete files from /var/cache/templates/responsive/ then try again.
I cleared cache and tried again. No luck.
Right Click selectbox State → Inspect. If you see data-ca-lite-checkout-element=“state” it is not ok.
Maybe the tpl from your theme needs to be edited.
Lines with data-ca-lite-checkout-element=“{$element_name_helper}” must be deleted/commented
1 Like
I do have that line in there when I Inspect. I’ll go and edit that line out in the tpl.
Thanks for continuing to assist!
I deleted that line and still the same. When I go back to check that the line was deleted, it is deleted.
However, I still have data-ca-lite-checkout-element=“state” there when I right click and inspect during checkout.
I have deleted the cache folder.
- I went through and found 3 instances of that line. I’ve deleted all three. Still shows same.
This line:
data-ca-lite-checkout-element=“state”
is located inside the s_state.tpl That is a different file than we were talking about and is not the same as data-ca-lite-checkout-element=“{$element_name_helper}” . I just went and looked at the state file and seen the words that aren’t supposed to be there when I inspect during checkout.
Don’t edit s_state.tpl.
Maybe you need to search for occurence of data-ca-lite-checkout-element= in files from /design/themes/ …
There are 10 instances of:
data-ca-lite-checkout-element=“{$element_name_helper}”
in the
views/checkout/components/profile_fields/field.tpl file.
Ten of them. At first, I used my browser’s find function when searching within the file using cPanel. It did not find 10.
When you said to go through and search for them in the design/themes folder, I did that with my cPanel search function. It found zero more instances of that line anywhere.
But I went back to the field.tpl file again and used the cPanel search function to search for instances, and using that, it found 10 instances, not 3 as I had said previously.
So I deleted all 10 instances of the line, cleared the cache, and it worked!
The state field is not overwritten and can be selected separately and it stays. 
Thank you, dorinvas! Thank you.