Wildcard rules behavioural differences in 5.4

[alexgarrettsmith]

• Laravel Version: 5.4.6
• PHP Version: 7.0.8
• Database Driver & Version: n/a

Description:

I previously enjoyed (5.3) doing the following with multiple, predefined array inputs. In this example, there are x emails[] fields but only the first email should be required.

return [
    'emails.*' => 'distinct|email', // all fields should be distinct and a valid email
    'emails.0' => 'required', // but only the first one is required
];

I'd then collect($request->emails), filter out the nulls and do something. However, in 5.4 this results in:

ErrorException in ValidationRuleParser.php line 154:
array_merge(): Argument #1 is not an array

Steps To Reproduce:

As a full example:

1. Generate x array inputs.

<form action="/share" method="post">
    @foreach (range(1, 3) as $n)
        <div class="form-group">
            <label for="email.{{ $n }}">
                Email #{{ $n }}
            </label>
            <input type="text" name="emails[]" id="email.{{ $n }}" class="form-control">
        </div>
    @endforeach

    <button type="submit" class="btn btn-primary">Send</button>
    {{ csrf_field() }}
</form>

2. Create form request, use controller validate method or manually validate with:

return [
    'emails.*' => 'distinct|email',
    'emails.0' => 'required',
];

In 5.3.*, this worked perfectly. My main question is whether this is an intended change. I know the ValidationRuleParser was added in 5.4, so not sure if this very niche requirement was ignored due to it feeling a bit hacky anyway.

[themsaid]

Thank you, a PR was created that should handle the issue.

[alexgarrettsmith]

Much appreciated, thanks!

[bytestream]

@themsaid in Laravel 5.2 I was doing:

'x.0.y' => 'in:0',
'x.*.y' => 'exists:table,id',

{"x":{"0":{"y":"0"},"1":{"y":"1"}}}

Where the first should be a value of 0 and all subsequent should be a valid ID in the database. In Laravel 5.5 this is no longer working because ValidationRuleParser is combining the rules:

'x.0.y' => [ 'in:0', 'exists:table,id', ],
'x.*.y' => [ ''exists:table,id', ]

Is this expected functionality?

[simonhamp]

@bytestream I'd say that is 'expected' functionality given that * applies to all indexes in the array.

I can see it's not the functionality you're after though.

If all of the items in x are the same enough to have identical rules for the majority case, why is the first item in x different? Should it even be a part of that array?