Open Feggel opened 8 years ago
I am testing the onestepcheckout with version 4.5.4. It seems that postcodenl fills the second address field and leeves the first line empty. Even when I select separate house number, the complete streetaddress is put in the second line. And when I change number of address lines in customer setup to 1, the postcodenl fields disappear from the checkout page, so that doesn't solve it.
What I don't understand: Our production website is on onestepcheckout version 4.5.3. That seems to have the same problem (postcodenl fills second address line), but here the address filled by postcodenl is accepted without error.
I am using postcodeNL plugin 1.2.4.0
Been trying to determine the cause of this error as well. It looks like my OneStepCheckout starts at billing[street][0]. Which is what happens in the PHTML code (the counter starts at 0)
Strangely enough, the demonstration of OneStepCheckout at demo.onestepcheckout.com itself starts at billing[street][1] . Magento itself also starts at billing:[street][1]
I have been trying to find a way to get this to change. (short of hiding the first row using CSS)
Hi
This fails right now and this has been reported to OneStepCheckout support a lot . This extensions has a conflict since OneStepCheckout 4.5.*.
OneStepCheckout has renamed the address field id-s and results are applied to wrong fields. This leaves address 1 to be empty and causing a hidden validation error (user does not see error messages cause it hides dom elements)
As a result it seems to user that they can't click place order button or if address fields are not mandatory then address is saved to wrong line all together.
I've only peeked at postcodenl/api/lookup.js file and added a temporary fix to updatePostcodeLookup method first line:
//OneStepCheckout support change to remap the fields, address element id -s have been changed var street1 = 'street0'; var street2 = 'street1';
care to patch or just detect and verify the address fields on the fly
Hi,
I've tested with the change mentioned by Speedmate and on our development server (with onestepcheckout 4.5.4) the address is filled in at the first address line, as it should be. And creating an order with postcodeNL enabled is possible again.
I guess it's easy for most users here, but I had to try 5 times before I had it on the right place, here is the edited part:
` /* * Update the address fields, given the validated data. / updatePostcodeLookup: function(data, housenumber_addition, housenumber_addition_select, prefix, postcodeFieldId, countryFieldId, street1, street2, street3, street4, event) {
//OneStepCheckout support change to remap the fields, address element id -s have been changed var street1 = 'street0'; var street2 = 'street1'; if (PCNLAPI_CONFIG.showcase && data.showcaseResponse)`
On our production server we use onestepcheckout 4.5.3, I haven't implemented the change there yet. At the checkout the address created with PostcodeNL is put in the "street address 2" line, but in admin, in the order address information in the order, the address is put in the first address line. Just like it does with the implemented solution on our development server.
I still don't understand why in version 4.5.3 the address is accepted in the second street address line, but with version 4.5.4 it isn't. It seems to me a more generic solution would be to accept the address when it is put only in line 2, instead of changing the code in postcodenl js. Isn't that possible?
@JohndeWaal In 4.5.3 it works cause OneStepCheckout has a bug with address field id's that is fixed in 4.5.4 . When 4.5 was made the feature changed and introduced a bug on its own feature. So worth to upgrade http://wiki.onestepcheckout.com/index.php?title=Changelogs#OneStepCheckout_4.5.4_changes
Is it save now to update OSC to last version or not? Next week we want to upgrade OSC also to the last version.
Thanks 4 your reply
@Mic2005 yes it is safe to upgrade
Nice work on finding a quickfix. :)
We will include it a next version, but I don't know the date yet.
Don't make any edits to your extension yes OneStepCheckout is considering a workaround on their side instead as this hits the support line rather hard right now . It is easier for us to change the id back in templates and find a workaround for preserving the right order in submissions
Ok. I guess it probably is a good idea to wait what next versions of OneStepCheckout might bring.
OneStepCheckout 4.5.5 is out and released a fix for this issue:
to fix :
Thanks, we are going to test this version tonight. Today we switched off postcode api extension and switched back to Magento 1 address field to make orders work. After patch yesterday we still encounter problems today for some customers. Hope that the new 4.5.5 works better. Let you know.
No problems here!
As of Onestepcheckout.com version 4.5.x, an error persists: "please fill in your streetname and housenumber" with PostcodeNL enabled.