Validator/data_get on the root of an indexed array

[ALameLlama]

This works perfectly fine:

$data = [
    'items' => [
        [
            'domain' =>  'test1.com',
        ],
        [
            'domain' =>  'test2.com',
        ],
        [
            'domain' =>  'test3.com',
        ],
        [
            'domain' =>  'test4.com',
        ],
    ]
];

$data = validator::make($data, [
    'items' => [
        'array',
        new RestrictedDomain('domain'),
    ],
    'items.*.domain' => [
        'string',
    ]
]);

But there are some cases where I have something like this, I was wondering if there was a way to select the whole array just like 'items' items does.

$data = [
        [
            'domain' =>  'test1.com',
        ],
        [
            'domain' =>  'test2.com',
        ],
        [
            'domain' =>  'test3.com',
        ],
        [
            'domain' =>  'test4.com',
        ],
];

$data = validator::make($data, [
    '*' => [
        'array',
        new RestrictedDomain('domain'),
    ],
    '*.domain' => [
        'string',
    ]
]);

In this example the custom rule would only get access too.

  [
       'domain' =>  'test1.com',
  ],

[MLuc24]

There isn't an attribute name that refers to the root, and the reason is structural rather than an oversight — rules are keyed by attribute, so a rule only exists by virtue of having a name to hang off. The root has no name.

The obvious thing to reach for is '*', but it won't give you what 'items' gives you. A key containing a wildcard goes through explodeWildcardRules, which flattens the data and matches keys against a pattern:

$pattern = str_replace('\*', '[^\.]*', preg_quote($attribute, '/'));

$data = ValidationData::initializeAndGatherData($attribute, $this->data);

foreach ($data as $key => $value) {
    if (Str::startsWith($key, $attribute) || (bool) preg_match('/^'.$pattern.'\z/', $key)) {

With '*' as the key, that pattern matches your top-level indices 0, 1, 2, 3 individually, so the rule gets instantiated once per element and each invocation sees a single row. Your RestrictedDomain('domain') expects the collection — it's reaching into a domain key across the set — so per-element expansion is the opposite of what you're after.

Which leaves wrapping, and honestly it's fine:

$validator = Validator::make(['items' => $data], [
    'items' => [
        'array',
        new RestrictedDomain('domain'),
    ],
    'items.*.domain' => ['string'],
]);

Your rule's contract doesn't change at all — it still receives the same array it did in your working example, so nothing about RestrictedDomain needs touching. The only visible difference is that error keys come back prefixed with items., which you can flatten afterwards or paper over with setAttributeNames if these messages reach users.

Worth knowing data_get itself has no such limitation — '*' at the root works there and returns every element, since the wildcard branch just iterates whatever it's handed. So if the confusion came from data_get being happy with a root wildcard, that's real; it's the validator's attribute-keyed rule list that can't express it, not the accessor underneath.

[ALameLlama]

I bring up data_get since that is what it uses under the hood. https://github.com/laravel/framework/blob/13.x/src/Illuminate/Validation/Validator.php#L647

I was hoping that'd work the same way.

[MLuc24]

That's the bit that makes it click, actually — data_get is used, but never with a wildcard still in the key. Look at what it's iterating on that line:

foreach ($this->getRules() as $key => $rules) {
    $value = data_get($this->getData(), $key, $missingValue);

getRules() returns $this->rules, and those have already been through ValidationRuleParser, where any key containing a * is destroyed and replaced by the concrete keys it matched:

if (str_contains($key, '*')) {
    $rules = $this->explodeWildcardRules($rules, $key, [$rule]);

    unset($rules[$key]);
}

So items.*.domain never survives to reach data_get — by then it's items.0.domain, items.1.domain and so on, each fetched separately. data_get's own wildcard handling is real, it just isn't on this path, because the expansion happens a layer above and always wins.

Which is why '*' as a root key does something rather than nothing, and the something isn't what you want: the parser matches it against your top-level indices and hands you four separate one-row invocations instead of one invocation holding the set. There's no point where the validator asks data_get for "everything" — it asks for one resolved path at a time.

Wrapping stays the answer for that reason: it gives the rule a real key to be attached to, which is the unit the whole pipeline is built around.

[nirav-gajera]

Your read on this is correct — there's no way to target the whole array as a single unit at the root the way items.* does under a named key, and the reason is exactly what you found: wildcard keys never survive to reach data_get.

ValidationRuleParser::explodeWildcardRules() runs before validation actually starts, walks your data, and expands any rule key containing * into one concrete key per match — items.*.domain becomes items.0.domain, items.1.domain, etc., and the original wildcarded key is unset(). By the time the Validator loop calls data_get($this->getData(), $key, ...), $key is always already-concrete. data_get's own wildcard support genuinely exists, but nothing on this path ever calls it with a wildcard still in the string — it's resolved one flat path at a time, always.

So when you put '*' at the root, the parser does the same expansion against your top-level numeric indices — you get four separate single-row rule invocations (0, 1, 2, 3), not one invocation holding the whole array. Your custom rule only ever sees one row at a time, same as the nested case would if you tried items.* alone without a rule on items itself.

The reason wrapping under a named key works isn't a workaround exactly — it's that items is a concrete key that isn't touched by the wildcard expansion, so a rule attached to it runs once, against the full array, before the .* expansion happens for its children. There's no root-level equivalent of that concrete key when your data is a bare indexed array — nothing for a whole-array rule to attach to.

Practically, wrapping is genuinely the answer, not just a workaround:

$data = Validator::make(['items' => $data], [
    'items' => ['array', new RestrictedDomain('domain')],
    'items.*.domain' => ['string'],
])->validate();

then unwrap ['items'] after if you need the bare array back. It's a one-line normalize-before-validate step, and it matches how the validator is actually built to work — every rule needs a concrete key to run against once, and a bare root array just doesn't have one to offer.

[ALameLlama]

The issue with wrapping it like this is all the messages/attributes will also now be wrong since they'll be nested under items..

Without adding something to allow escaping the * replace or a new symbol like $ to signals that it's the root element. I think the "best" solution I have it just adding a rule on the 0th index

    '0' => [
        'array',
        new RestrictedDomain('domain'),
    ],
    '*.domain' => [
        'string'
    ]

and then updating my custom rule to use DataAwareRule so I can access the rest of the array. like how I wanted

[nirav-gajera]

That's a solid approach, and it holds up for the same reason wrapping does — '0' is a literal, concrete key. It doesn't contain *, so explodeWildcardRules() never touches it, and it survives to data_get() unexpanded, same as items did. DataAwareRule::setData() then gets you the full dataset regardless of which key the rule is nominally attached to, so you get the "see everything" access you originally wanted without wrapping anything.

Two things worth being aware of before you commit to it:

Empty array = rule never runs. If the array can legitimately be empty, there's no 0 key for the rule to attach to at all, so RestrictedDomain silently never fires. Worth adding an explicit 'array' (and maybe 'min:1' if empty genuinely shouldn't be allowed) on some other stable key, or just being intentional that empty input skips this check.

Failure messages will report under key '0', not something meaningful like items or domains. Since your rule calls $fail() with its own message text, you're already fully in control of the wording — that part's fine either way. But if you're pulling structured errors by key ($errors->first('0'), or building an API error response keyed by field), that's going to look odd to whoever's on the other end. Two ways to smooth that over if it matters:

• Custom attribute names: Validator::make($data, $rules, [], ['0' => 'items']) — doesn't change the error bag key, but fixes the :attribute placeholder if your message uses it.
• Implement ValidatorAwareRule alongside DataAwareRule, then in the rule call $this->validator->errors()->add('items', $message) directly instead of $fail() — that lets you write the failure under whatever key you actually want it filed under, not just 0.

Otherwise this is a clean fix — you're not fighting the wildcard-expansion behavior, you're just picking a key it won't touch.

[gitsult4n]

There's no built-in way to do this, because validation rules are keyed by field path, and there's no path that represents "the root itself" — that's exactly why your items example worked: the items key acts as the reference to the whole array. A bare root array has no such key to attach a rule to.

Practical fix: wrap the input under a synthetic key before validating:

$data = Validator::make(['root' => $data], [
    'root' => ['array', new RestrictedDomain('domain')],
    'root.*.domain' => ['string'],
]);

That gives you the same "access the whole array" behavior your items example had, just with an artificial wrapper key.