-
Notifications
You must be signed in to change notification settings - Fork 10.7k
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
[5.2] Numeric fails to validate against empty value #11452
Comments
Is this an issue on 5.1 too? |
No. I didn't have this issue until the upgrade to 5.2. Traced the issue to that line |
Thanks. |
Ping @taylorotwell. Was this intentional. I know there were some changes to validation in L5.2. |
Yeah I think it is intentional. If you send a value, it has to be numeric. So I would suggest sending 0 or something instead of an empty string. |
Brakes my project too.
fails |
Yes, that is intentional. If you provide the field, it must be numeric, as On Tue, Dec 22, 2015 at 8:32 AM, Jordan Dobrev notifications@github.com
|
Aren't we supposed to use How do we handle the validation of nullable numbers? |
You could send a 0. On Tue, Dec 22, 2015 at 8:48 AM, Jordan Dobrev notifications@github.com
|
This won't work if the validation is part of your eloquent model. I am using Jeffrey's package like validation:
Attributes is going to contain nullable values when you attempt to perform an update. Should we filter the attributes and skip null values then? |
You could. You could also extend Validator using Validator::extend to add a On Tue, Dec 22, 2015 at 9:01 AM, Jordan Dobrev notifications@github.com
|
Great! Thx |
But in the 5.2 docs, http://laravel.com/docs/5.2/validation#custom-validation-rules. "By default, when an attribute being validated is not present or contains an empty value as defined by the required rule, normal validation rules, including custom extensions, are not run. For example, the integer rule will not be run against a null value:" Does the docs need to be updated? Or not? |
In this case the docs would need to be updated. Basically, in Laravel 5.2, On Tue, Dec 22, 2015 at 9:37 AM, mtctonyhkhk2010 notifications@github.com
|
This means that the |
I'll just revert to 5.1 behavior even though I think it's kind of weird. On Tue, Dec 22, 2015 at 10:20 AM, Arthur Kirkosa notifications@github.com
|
It's not necessarily weird. If you have a Or a |
What if an additional 'nullable' rule is added to the validations. Wouldn't that make more sense?
|
+1, can reproduce on L5.2, this feels broken, empty string is not numeric, also |
@GrahamCampbell passing an empty string as a value will cause the validator to neglect the key for validation if the rules doesn't indicate the field is required and |
This was reverted in 5.2, and in 5.3 a new nullable validation rule was added and the validator became more strict when it comes to primitives. |
I really don't think this |
Guys, this is so sick.
Now no matter if my "voucher_enabled" checkbox is checked or not - the "voucher_price" is failing validation, because some empty price comes in post. Which is not illegal in this case. And if I change the rule to:
Then it won't fail validation even when it should: i.e. when price is empty, while required.
Then if my voucher_enabled is 0, voucher_price is empty (not illegal) and validation fails on "integer" rule, because null is not integer. Do you expect us to write our own "integer_if", "min_if" "numeric_unless", "email_if" custom validations? |
@jbajou I agree. To me, nullable should just be the default when a field is not required. If i send null, I don't expect laravel to be trying to validate that it matches the rule I created for when a "normal value"(anything except null) is actually sent. I understand that laravel is just trying to be strict/explicit about what is being validated, but maybe doing the reverse would make more sense for the majority of devs. IOW, a "not_nullable" rule. |
How to validate field is email or empty in default rules? |
https://github.com/laravel/framework/blob/5.2/src/Illuminate/Validation/Validator.php#L152
Having numeric (and others) in the
$implicitRules
variable implies that the particular field MUST have a value, and fails for empty values.The text was updated successfully, but these errors were encountered: