addNumber breaks liveValidation in some cases

Developers
1

Hi folks,

I did a little hacking the other day and I came across the following strange behavior.

I like phone numbers to be restricted to numbers. Therefore I tested the following code:

    $row = $form->addRow();
    $row->addNumber('phone1');

The code above breaks liveValidation.

Instead, the following code works just fine:

    $row = $form->addRow();
    $row->addNumber('fone1');

Can you reproduce this? Any ideas?

Kind regards,
Roman

2

I just found out that liveValidation still works somehow, because the page submit is blocked if the field is no number with the usual alert message showing.

The thing that is not working as expected is that the red fonted liveValidation message “Must be a number!” is not showing.

Weird stuff… :slight_smile:

3

Hi Roman,

Hmm. Are you testing this on a form that already has a phone1 value? This would cause LV to break, because each field must have a unique name. There’s also a PhoneNumber input type, which has nested inputs. Perhaps updating this instead would do the trick?

4

Hi Sandra,

I prepared the following code for you. This should help to easily reproduce the strange behavior.

Things work find with variable name ‘fone’ and doesn’t with ‘phone’.

<?php use Gibbon\\Forms\\Form; $form = Form::create('applicationForm', ''); //$row = $form->addRow()->addNumber('phone'); $row = $form->addRow()->addNumber('fone'); echo $form->getOutput(); ?>

Again, weird stuff…:slight_smile:

Good luck!

Kind regards,
Roman

5

Hi Roman,

I tested out your code and discovered the error luckily isn’t with LiveValidation, which as you noted seems to be working and prevents submission, but happens to be a css rule that was added to help fix an issue with overlapping validation messages inside a phone number:
input[name*=“phone”] ~ .LV_invalid`

Incidentally, the Form class does have specialized phone number inputs for this case, rather than using addNumber(‘phone’)`. As it so happens, we’ve made some pretty major changes to the form rendering in v18, and this issue appears to no longer exist for the upcoming version.

Thanks!