Laravel `array_pluck` on any key

Stefan Bogdanescu

Founder & Senior Architect · 2026-06-29

Laravel Company

The Illusion of Magic: Why array_pluck Can't Handle Complex Dot Notation

As developers, we often look for shortcuts—a single, elegant function call that can handle complex data transformations. In the world of PHP and Laravel, functions like array_pluck promise this kind of syntactic magic. However, when dealing with deeply nested or irregularly structured data, the reality is often more nuanced. Today, we’re diving into a specific challenge: Can we use syntax like array_pluck($array, 'users.*.id') to extract nested data? The short answer is no, not in that direct form.

Deconstructing the Attempt

Let's examine the goal using your provided structure:

php
$array = [
    'users' => [
        [ 'id' => 1 ],
        [ 'id' => 2 ],
        [ 'id' => 3 ],
    ]
];
// Desired result: [1, 2, 3]

You attempted to use string notation like 'users.*.id' or 'users.id' with array_pluck(). While dot notation is incredibly powerful in frameworks like Eloquent for accessing relationships (e.g., $user->posts.title), standard native PHP functions, including Laravel's collection methods, operate based on explicit keys or simple path definitions. They do not inherently possess the complex pattern-matching capabilities required to interpret .* within a single string argument to traverse multi-level arrays dynamically in this way.

When you pass 'users.*.id' to array_pluck, the function treats that entire string as a literal key or path it needs to look up, which fails because the internal structure of your array doesn't map directly to that pattern for extraction. This highlights an important distinction: framework helpers are designed to work with the data structures they commonly manage (like Eloquent relationships) rather than acting as universal recursive file system parsers within raw PHP arrays.

The Developer's Solution: Explicit Iteration

When we encounter deeply nested data manipulation in raw PHP, the most robust and readable approach is often explicit iteration or using collection methods designed for flattening. For your specific case, where you need to extract IDs from a nested structure, we must explicitly navigate the layers of the array.

We can achieve the desired result by iterating through the main array and then extracting the relevant data from the nested elements. This method is not just more explicit; it makes the code easier to debug and maintain, which aligns perfectly with best practices taught in modern development, much like the principles applied in Laravel architecture where clarity is paramount.

Here is how we can reliably extract those IDs:

php
$array = [
    'users' => [
        [ 'id' => 1 ],
        [ 'id' => 2 ],
        [ 'id' => 3 ],
    ]
];

$user_ids = [];

// Step 1: Access the array of user records (the value associated with 'users')
$users_data = $array['users'];

// Step 2: Iterate through the records and extract the 'id' from each record
foreach ($users_data as $user) {
    // Since $user is an array like ['id' => 1], we access its key directly.
    $user_ids[] = $user['id'];
}

// Result: $user_ids will be [1, 2, 3]

Alternative using array_column and Flattening

For slightly more concise solutions when dealing with arrays of associative arrays, we can use functions designed for column extraction. While not a direct replacement for complex path traversal, combining functions can streamline the process:

php
$users_data = $array['users'];

// Extract all 'id' values into a new array
$ids = array_column($users_data, 'id');

// Result: $ids will be [1, 2, 3]

This approach leverages PHP's native capabilities efficiently. When building complex data flows in Laravel applications, understanding how to handle arrays explicitly is crucial. For deeper insights into structured data handling and Eloquent relationships that abstract much of this complexity, exploring the documentation provided by the official team at https://laravelcompany.com is highly recommended.

Conclusion

The initial thought—that we could use a magical string like 'users.*.id' with array_pluck—is appealing. However, it pushes against the boundaries of what native array functions are designed to do. For complex