Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Feggel opened this issue Feb 4, 2016 · 13 comments
Open

Comments

@Feggel
Copy link

Feggel commented Feb 4, 2016

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

@JohndeWaal
Copy link

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
Copy link

tramov commented Feb 23, 2016

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
Copy link

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
Copy link

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
Copy link

@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
Copy link

Mic2005 commented Feb 24, 2016 via email

@speedupmate
Copy link

@Mic2005 yes it is safe to upgrade

@MaartenScholder
Copy link
Contributor

Nice work on finding a quickfix. :)

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

@MaartenScholder MaartenScholder changed the title Onestepcheckout.com 4.5 "Adress Validation" error. Onestepcheckout.com 4.5 "Adress Validation" error. [4.5.4 hotfix inside] Mar 3, 2016
@speedupmate
Copy link

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
Copy link
Contributor

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

@speedupmate
Copy link

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

  • Fix: changing address field id-s back to start from 1, this caused issues to lot of .nl region clients who use autocomplete scripts that depend on those field id -s

to fix :

  • download 4.5.5 from download area
  • do a full upgrade upgrade
  • if not full upgrade is not possible and you are already on 4.5.* version then update following files only
  • app/design/frontend/base/default/template/onestepcheckout/billing_fields.phtml
  • app/design/frontend/base/default/template/onestepcheckout/shipping_fields.phtml
  • skin/frontend/base/default/onestepcheckout/js/oscgp.js

@Mic2005
Copy link

Mic2005 commented Mar 3, 2016

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
Copy link

Mic2005 commented Jul 23, 2016

No problems here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants