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

Using validation rules in a sub-array makes the field required #271

Closed
jormaechea opened this issue Dec 11, 2018 · 3 comments
Closed

Using validation rules in a sub-array makes the field required #271

jormaechea opened this issue Dec 11, 2018 · 3 comments

Comments

@jormaechea
Copy link

Use case
Validate an optional field within a numeric array of associative arrays.

Example

Normally, the dateFormat rule allows null value (which is correct, because it's not required).
This is valid:

$validator = new Valitron\Validator(["dateCreated" => "2018-12-11T13:52:20-03:00"]);
$validator->rule("dateFormat", "dateCreated", "Y-m-d\TH:i:sP");

But when the date field is within an array, it automatically makes it required.
This is invalid:

$validator = new Valitron\Validator([
  [ "dateCreated" => null ]
]);
$validator->rule("optional", "*.dateCreated"); // This line doesn't affect Valitron's behaviour
$validator->rule("dateFormat", "*.dateCreated", "Y-m-d\TH:i:sP");

Expected behaviour
Valitron should check the dateFormat rule in the same way whether or not it's in an array, which means, to treat the dateCreated field as optional.

Notes
This also happens, for example with numeric, integer, lengthMin and other rules.

@willemwollebrants
Copy link
Collaborator

I think (and testing seems to confirm it) this is already fixed in the dev-master branch. Can you please try it with composer require vlucas/valitron:dev-master

If it's fixed there I'll make a new release. If it's not, I'll try and fix it first :)

@jormaechea
Copy link
Author

Yes, it's working on dev-master!! I'll wait till the new release. 😄

@willemwollebrants
Copy link
Collaborator

The new release is here, v1.4.4 fixes this.

Turns out, I fixed this exact same bug for #262 🙂

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

2 participants