While working on IndexNow in Laravel, I needed to clean a list of URLs before submitting it: remove empty values, deduplicate the list, and restore sequential numeric keys.

It was a small, ordinary transformation pipeline, but it became the first place where I used PHP 8.5's Pipe Operator |> as part of real production code rather than as a demo of new syntax.

The result reads in the same direction as the data changes: filter → unique → values.

In my IndexNow implementation for automatically submitting URLs to Bing, the HTTP client receives an array of public URLs and builds the urlList sent to the external service.

Before making that request, I need to guarantee that the list contains no empty values or duplicates and that its indexes are sequential.

This was not a utility invented to demonstrate the Pipe Operator. The cleanup was already part of the IndexNow contract.

• array_filter() removes everything that is not a non-empty string

• array_unique() removes duplicate URLs

• array_values() restores sequential numeric keys

• The result is a clean list ready for the urlList JSON payload

The Pipe Operator takes the result of the expression on its left and passes it to the callable on its right.

I can read the right-hand side as a function that PHP invokes with the previous result.

A simple pipe therefore does not create a new collection type or a special pipeline object. It is an expression provided by the language itself.

There is nothing technically wrong with this version. The difference is the reading order.

I first have to find array_filter(), then move outward to array_unique(), and finally reach the outer array_values() call.

As the number of transformations grows, nesting starts to hide the actual sequence of operations.

I do not consider this version worse either.

If I need to place a breakpoint between stages, log an intermediate value, or give each state a meaningful name, temporary variables may be clearer than a pipe.

For me, the question is not whether code can be rewritten with |>. The question is whether doing so makes the intent easier to read.

• Each step is small and easy to understand

• The result of one step naturally becomes the input of the next

• The steps do not have separate business meanings that need their own names

• I do not need the intermediate values after the pipeline finishes

• The filter → unique → values sequence matters more than function-call nesting

• The final result remains an ordinary PHP array

There is another detail in this example that makes the order of transformations important.

array_filter() preserves keys. array_unique() can also leave gaps after duplicate values are removed.

After filtering and deduplication, the array indexes are therefore not guaranteed to be 0, 1, 2, ...

For IndexNow, this is not just about making an array dump look nicer.

The array is later passed to Laravel's HTTP client as urlList in a JSON payload. In PHP, an array with non-sequential numeric keys can be encoded as a JSON object with explicit keys instead of a JSON list.

The final array_values() therefore guarantees the data shape I want to send to the external API.

At first glance, it may seem cleaner to start the entire chain with $urls |> ....

But my array_filter() call needs both the input array and a callback containing the validation rule.

The simplest version was to keep that first call as a normal expression and pipe its result into the one-argument callable stages.

Here, the pipeline reads almost literally as a transformation path.

First I remove the trailing slash, then take the basename, and finally decode the resulting slug.

Short, pure transformations like this are where the new syntax feels most natural to me.

• When each step has important domain meaning and deserves a separate name

• When I need to inspect or log intermediate values

• When most stages require wrapper closures just to adapt their signatures

• When the chain becomes so long that several assignments would be easier to scan

• When transformations have side effects and it is not obvious what value continues through the chain

• When |> is being added only because it is a new PHP 8.5 feature

The Pipe Operator is PHP 8.5 syntax, so upgrading only my local PHP installation would not be enough.

CLI, PHP-FPM, CI runners, Docker workspaces, Composer platform requirements, and the production runtime all need to agree before |> enters the codebase.

Otherwise, readability is no longer the problem - the older interpreter simply cannot parse the new syntax.

I covered the runtime migration itself separately in my article about the PHP 8.5, Laravel, Laradock, and Composer package upgrade.

The names are similar, but I use these approaches at very different levels.

PHP's Pipe Operator is a small language-level expression for passing one value through callables.

Laravel Pipeline is useful for a more structured application flow where stages can be separate classes with their own responsibilities. I have already used that approach in a real commission calculation flow built with Laravel Pipeline.

Creating a Laravel Pipeline for three array functions would be excessive. At the other extreme, one long |> chain does not replace architecture for a complex domain flow.

1. Non-string values never reach the final URL list.

2. Empty strings are removed.

3. Duplicate URLs are removed.

4. Keys are sequential again after filtering and deduplication.

5. An empty result does not trigger an HTTP request.

6. The final urlList remains a JSON array.

7. The IndexNow HTTP payload keeps the same functional behavior after the syntax refactor.

• |> works best for small sequential transformations

• Not every nested call needs to be rewritten

• Temporary variables remain a good solution, especially for debugging

• A wrapper closure is not worth adding just to make everything look like one pipe chain

• I need to think about data shape as well as data value between stages—as the final array_values() in the JSON payload demonstrates

• New PHP syntax should enter the codebase only after the entire runtime is aligned, not just the local environment

I like PHP 8.5's Pipe Operator not because it lets me write the same code with newer syntax.

In the right place, |> changes the direction in which I read the code. Instead of unpacking nested functions from the inside out, I see the data flow in the same order in which it actually executes.

My IndexNow URL cleanup is exactly that kind of case: filter → unique → values. The second rtrim → basename → rawurldecode example confirmed the same pattern.

I do not plan to turn every PHP function chain into a pipe. But for short transformation pipelines without unnecessary side effects, |> has already become a normal tool for me rather than just a PHP 8.5 novelty.