[DanielDarrenJones]

When a replicator or grid column is shown in a listing (entries, terms, users, assets or form submissions), every row carries that field's whole value, nested sets and all. The listing cell only shows how many there are (:count sets / :count rows), and it gets that by counting the array.

This adds preProcessIndex() to both fieldtypes:

• Replicator keeps each set's id, type and enabled.
• Grid keeps each row's id.

The array still has one item per set or row, so the cell reads exactly the same. Bard has its own preProcessIndex() and isn't affected.

Benchmark

A generated site on 6.40.0 with an 85 KB page builder blueprint. Each request runs in its own PHP process, as PHP-FPM serves it (boot not timed, opcache on), median of 5, on an M1 Pro with PHP 8.5.

A 50-entry listing with the page builder column visible goes from 1.06 MB to 27 KB and from 80 ms to 66 ms.

I also checked the CP in a browser on stock 6.40.0 and with this change: the listing table renders identically, including a grid column with 3 to 8 rows per entry and a Bard column next to it.

Compatibility

An addon fieldtype that extends Replicator or Grid and has its own index component showing the set or row contents would now only get those keys. It can override preProcessIndex() to keep the old behaviour. I couldn't find a public addon that does this.

Tests

• ViewEntryListingTest::it_only_lists_the_ids_and_types_of_replicator_sets_and_grid_rows (fails without the change).
• ReplicatorTest and GridTest cover what's kept, and that non-arrays and null pass through.

The full suite passes.