postcode-nl / PostcodeNl_Api_MagentoPlugin

A Magento plugin 1.9 that implements the Postcode.nl API for Dutch addresses
BSD 2-Clause "Simplified" License
21 stars 12 forks source link

Onestepcheckout.com 4.5 "Adress Validation" error. [4.5.4 hotfix inside] #28

Open Feggel opened 8 years ago

Feggel commented 8 years ago

As of Onestepcheckout.com version 4.5.x, an error persists: "please fill in your streetname and housenumber" with PostcodeNL enabled.

JohndeWaal commented 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

tramov commented 8 years ago

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)

speedupmate commented 8 years ago

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

JohndeWaal commented 8 years ago

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?

speedupmate commented 8 years ago

@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

Mic2005 commented 8 years ago

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

speedupmate commented 8 years ago

@Mic2005 yes it is safe to upgrade

MaartenScholder commented 8 years ago

Nice work on finding a quickfix. :)

We will include it a next version, but I don't know the date yet.

speedupmate commented 8 years ago

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

MaartenScholder commented 8 years ago

Ok. I guess it probably is a good idea to wait what next versions of OneStepCheckout might bring.

speedupmate commented 8 years ago

OneStepCheckout 4.5.5 is out and released a fix for this issue:

to fix :

Mic2005 commented 8 years ago

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.

Mic2005 commented 8 years ago

No problems here!