[Done 1.3.9b] Minimum value of zero gets validated incorrectly in JS formcheck

Hi, I've touched on this elsewhere previously on the end of a thread that seems to be dead so I've posted here in case someone can help.

I'm trying to disable validation on the Post Code field. The method suggested around the forums does not work: Setting the minimum value to zero still causes validation on the field by alerting that it requires "zero" characters.

If I leave the field completely blank, it works (doesn't validate) but then the browser reports a syntax error on the page, because it expects a character where there is none.

I've now also checked the bug-fix lists for ZC 1.35 and 1.36 but can't see anything resembling this. I'm running 1.302.

Any help is much appreciated!
Rob

in the jscript_form_check.php file for the create-account and login pages, you can make one small adjustment (insert the line indicated) to work around this.

function check_input(field_name, field_size, message) {
  if (form.elements[field_name] && (form.elements[field_name].type != "hidden")) {
    var field_value = form.elements[field_name].value;

    if (field_value == '' || field_value.length < field_size) {
      error_message = error_message + "* " + message + "\n";
      error = true;
    }
  }
}
```becomes```
function check_input(field_name, field_size, message) {
  if (form.elements[field_name] && (form.elements[field_name].type != "hidden")) {
    if (field_size == 0) return;
    var field_value = form.elements[field_name].value;

    if (field_value == '' || field_value.length < field_size) {
      error_message = error_message + "* " + message + "\n";
      error = true;
    }
  }
}

This may or may not be the final solution, but will at least function as a workaround.

That's the stuff, thanks DrByte
I'll detail what I've done now so that others looking for the same thing can find it here.

To disable Post Code validation in cases where this field is not essential or required, one normally sets Admin, Configuration, Minimum Values, Post Code = 0.

This is a common requirement in New Zealand where people usually have no idea what their post code is and to top it off the postal service recently changed them all around in order to improve their own internal processes at the cost of everyone else'.

Because this doesn't work properly in 1.302 and presumably also in 1.35 and 1.36, apply the fix DrByte has given. There may be other files that need this, but I've so far only found these ones:

In these files

• includes/modules/pages/account_edit/jscript_form_check.php (line 31)
• includes/modules/pages/create_account/jscript_form_check.php (line 31)
• includes/modules/pages/login/jscript_form_check.php (line 31)
• includes/modules/pages/address_book_process/jscript_main.php (line 31)
• includes/modules/pages/checkout_shipping_address/jscript_main.php (line 38)
• includes/modules/pages/checkout_payment_address/jscript_main.php (line 38)

Add the red bit below to the check_input function at the line indicated:

function check_input(field_name, field_size, message) {
if (form.elements[field_name] && (form.elements[field_name].type != "hidden")) {
if (field_size == 0) return;
var field_value = form.elements[field_name].value;

Now if the Minimum value is set to zero, the form will validate correctly for the pages listed.

An additional interface fix is to remove the red asterisk next to the field so that the customer knows it is not required.

In file includes/languages/english.php
Remove the asterisk in line 219:
Remove asterisk from: define('ENTRY_POST_CODE_TEXT', '*');

These changes are not safe from a cart upgrade, but if you check after upgrading, they may no longer even be needed.

Regards,
Rob

This helped tons! ...even a year later...thanks.

Great to hear... has it been a year already!? ouch!

In the republic of Ireland we dont have postcodes which can put customers off registering so this thread was a great help,

but I've noticed that when you update a customer from admin such as approving a customer it still requires the postcode.

I tried to work my way round this and so I edited the following files by adding in the code

if (field_size == 0) return;

into

includes\form_check.js.php (line 21) and
admin\customers.php (line 380)

It seems to work but I'm just wondering if anyone can see any way this would cause any problems or pose any risks? :wacko:

If both files are in the admin area, that should be fine.

no, the includes\form_check.js.php is in the normal includes folder not the admin, would this cause any problems?

I'm always so nervous about messing up my shop or causing some security issue!!

I recommend only editing the admin file, and not the other one.
While making the edit to the non-admin file isn't fatal, it just means that the on-screen validation of some things may not happen until after someone actually submits an invalid form and it has to come back and ask for the information instead of warning them in popup help.
If your admin edit doesn't work properly if you don't also edit your non-admin file, then I guess just go ahead with what you've done. There's no security problem, just less usability for your customers.

Hi guys,

I'm in a spot of trouble with this. Am using 1.3.8a and now need postcodes to be left blank - I believe I have followed all of the above but my main login page still throws up an error message for 0 characters in the post code. The other pages like account edit etc are not doing this at all.

Have also commented out from my templates create account page.

// if (strlen($postcode) < ENTRY_POSTCODE_MIN_LENGTH) {
// $error = true;
// $messageStack->add_session('login', ENTRY_POST_CODE_ERROR);
// }

as suggested in another thread.

I see this is flagged as being fixed in 1.3.9 - I really don't want to go through the entire upgrade process just yet. Is it safe to replace th entire includes/modules/pages folder with one from 1.3.9 or is there other changes referenced within this that would cause issues.

Would really appreciate any help on this.

Just an update - turning off the split login page which means customers have to sign up on the create account pgae rather than the login page works fine - this isolates it to the login page itself.

See post #2 earlier in this thread.

I had already done this and robaxs list as well. The only page that is still causing the error is the combined login/create account page which I understand is based off includes/modules/pages/login/jscript_form_check.php

Can't understand it tbh it's the same piece of code that worked on all the other pages. Will have a winmerge at a fresh install and see if anything else is causing issues.

:frusty:

Hey guys, just thought I would jump in here.

There is a very simple solution to this and its leave the box blank in Admin > Configuration > Minimum Values > Post Code

Then you can go to /includes/languages/english.php and remove the Astrix from define('ENTRY_POST_CODE_TEXT', '*'); around line 225

This should solve any problems with the login/create account page by stopping it from looking for any value in the post code field.

Hope it helps, it works for me on 1.3.8a and 1.3.9

You might also review this discussion: http://www.zen-cart.com/forum/showthread.php?t=75585