[6.x] Fix count() TypeError when entries collections config is a string

[jackmcdade]

Summary

• Opening Link to Entry in a nav (or any entries relationship selector) hit count(): Argument #1 ($value) must be of type Countable|array, string given when collections was a string
• Wrap collections in Arr::wrap() in the Collection filter and Entries::getConfiguredCollections() so string YAML configs (collections: pages) don't blow up on PHP 8
• Add regression tests for multi-collection filters and string collections config

From Discord: https://discord.com/channels/489818810157891584/1537065384119894146

[jasonvarga]

This is an AI-generated review.

Thanks for tracking this down! The Arr::wrap() fix is correct for the two spots it touches, but the same crash is still reachable elsewhere — this needs two more fixes before merge:

1. Entries::relationshipQueryBuilder() (src/Fieldtypes/Entries.php:525) reads $this->config('collections') raw and passes it to whereIn('collection', $collections). With a string config, Stache's whereIn() does array_merge($this->collections ?? [], $values), which throws the same TypeError via whereRelation/whereHas queries on relation fields. Swap it for getConfiguredCollections() (or wrap with Arr::wrap()).

2. EntryLinkType::collections() (src/Fieldtypes/Link/EntryLinkType.php:69-84) declares : array but returns $field->get('collections') unwrapped. When that's a string, it throws TypeError: ...collections(): Return value must be of type array, string returned — on every render of a Link field with the Entry type visible. Since nav items use this exact class, this is likely the actual crash behind "Link to Entry in a nav" from the report, and it happens before either of the two patched call sites are ever reached.

   Fix:

   return Arr::wrap($collections);

   (plus use Statamic\Support\Arr;)

   Regression test (verified it fails on this branch with the TypeError above, and passes once the fix is applied) — add to tests/Fieldtypes/LinkTest.php:

   use Statamic\Fieldtypes\Link\EntryLinkType;
   
   #[Test]
   public function it_wraps_a_string_collections_config_into_an_array_for_the_entry_link_type()
   {
       // A hand-authored blueprint may set `collections: pages` (a string) rather than
       // `collections: [pages]`. Building the nested entries fieldtype config used to
       // return that string as-is, which broke the `array` return type on collections()
       // and crashed as soon as the link field's "entry" type was rendered (e.g. opening
       // "Link to Entry" in a nav item).
       $field = new Field('test', ['type' => 'link', 'collections' => 'pages']);
   
       $config = (new EntryLinkType)->fieldtype($field);
   
       $this->assertEquals(['pages'], $config['collections']);
   }

[jackmcdade]

Addressed the review:

1. relationshipQueryBuilder() now uses getConfiguredCollections()
2. EntryLinkType::collections() wraps with Arr::wrap()
3. Added the LinkTest regression case

[jasonvarga]

This is an AI-generated review.

Both follow-up fixes look correct — relationshipQueryBuilder() now goes through getConfiguredCollections(), and EntryLinkType::collections() wraps with Arr::wrap(). I checked out the branch and re-ran LinkTest, RelationshipFieldtypeTest, and EntryQueryBuilderTest (166 tests, all green), and re-ran the whereRelation scratch repro from my earlier comment against the new code — no longer throws. Thanks for the quick turnaround.