FilterBy(): Discrepancy between signature and actually required parameter types

Hi community,

upgrading to Kirby 3.5.7 from 3.5.6 gave me a nasty bug. I have been using the filterBy function in some places. According to the required signature, I hade a line of code reading

foreach ($pages->index()->filterBy(["intendedTemplate"], [$intendedTemplate]) as $relationPage) {
:
}

which worked fine until upgrading to 3.5.7. This very line (and two similar ones) threw exceptions. Finally I figured out that the two array parameters have to be scalar ones. From the logic perspective, this is not a problem, because both arrays contain just one value.

Changing the line to read

foreach ($pages->index()->filterBy("intendedTemplate", $intendedTemplate) as $relationPage) {
 : 
}

made the exceptions go away, the code now functions again as it should do. But it makes also my IDE complain that the signature of the filterBy function requires array parameters. Looking at the code of the Collection class, it turns out that my IDE is right:

    /**
     * Alias for `Kirby\Toolkit\Collection::filter`
     *
     * @param string|Closure $field
     * @param array ...$args
     * @return static
     */
    public function filterBy(...$args)
    {
        return $this->filter(...$args);
    }

Using the array parameters throws exceptions. Using scalar parameters requires me to silence the error recognition in the IDE. I wonder whether you are planning to correct this in a future release. Or am I on a wrong track?

The Collection class was not modified in Kirby 3.5.7, so I wonder why it only causes problems since the update. The array arguments were never supported by the code.

Sorry for the confusion from the wrong type hints. I think the array ...$args hint may have been caused by the migration to PHP’s splat operator a long time ago. Of course, $args becomes an array with all args, so that’s likely why the type array was added. But of course the type should refer to the individual args in the splat, not the splat itself (which would be pretty useless).

We will fix this in the very next release. :slight_smile:

1 Like

I cannot explain this behavior, but for me it emerged after the update. Anyway, I can work around it by tweaking the picky bits of my IDE. Good to know that the offending hint will be fixed.

Great work of all of your team!

The type hint was updated in today‘s 3.5.7.1 patch release. :slight_smile: