where() is case-insensitive but whereIn() is case-sensitive

[theRealPadster]

Bug description

where('column', $value) and whereIn('column', [$value]) return different results for the same value, because they compare differently:

• where() goes through filterTestEquals(), which lowercases both sides:
  https://github.com/statamic/cms/blob/v6.32.0/src/Query/Builder.php#L775-L778

  protected function filterTestEquals($item, $value)
  {
      return strtolower($item ?? '') === strtolower($value ?? '');
  }

• whereIn() goes through filterWhereIn(), which uses an array_flip + isset() lookup — case-sensitive, since PHP array keys are:
  https://github.com/statamic/cms/blob/v6.32.0/src/Stache/Query/Builder.php#L158-L165

  protected function filterWhereIn($values, $where)
  {
      $lookup = array_flip(array_map($this->normalizeLookupValue(...), $where['values']));
  
      return $values->filter(
          fn ($value) => ! is_array($value) && isset($lookup[$this->normalizeLookupValue($value)])
      );
  }

IteratorBuilder::filterWhereIn() has the same case-sensitive behaviour via in_array(), so this isn't specific to the Stache driver.

I don't have a view on which is correct, but the two should presumably agree. whereNotIn / filterTestNotEquals have the same split.

How to reproduce

On any Statamic site, with an entry whose slug is my-page:

use Statamic\Facades\Entry;

Entry::query()->where('slug', 'MY-PAGE')->count();      // 1
Entry::query()->whereIn('slug', ['MY-PAGE'])->count();  // 0

Entry::query()->where('slug', 'my-page')->count();      // 1
Entry::query()->whereIn('slug', ['my-page'])->count();  // 1

Logging

• Statamic 6.24.2 (verified unchanged in v6.32.0)
• Laravel 12.64.0, PHP 8.4
• Stache (flat file) and Iterator builders both affected

Why it bit us

SEO Pro's redirects sit on both methods: creating a redirect validates uniqueness with where('source', …) while serving one matches with whereIn('source', …). The result is that a redirect for /TimberWalk 404s when the stored source is /Timberwalk/, and the CP simultaneously refuses to let an editor create the missing redirect because its uniqueness check thinks one already exists. Filed separately against seo-pro, but the underlying disagreement is here.

[duncanmcclean]

Can you provide the full output of php please support:details?

[theRealPadster]

Sorry — I filed this without the template fields. Here they are.

Environment

Environment
Laravel Version: 12.64.0
PHP Version: 8.4.23
Composer Version: 2.10.2
Environment: local
Debug Mode: ENABLED
Maintenance Mode: OFF
Timezone: UTC
Locale: en

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: log
Cache: file
Database: mysql
Logs: stack / single
Mail: sendgrid
Queue: sync
Session: file

Storage
public/storage: NOT LINKED

Statamic
Addons: 5
License Key: Set
Sites: 1
Stache Watcher: Enabled (auto)
Static Caching: Disabled
Version: 6.24.2 PRO

Statamic Addons
el-schneider/statamic-simple-address: 2.1.2
himher/salesforce-refresh-connector: 1.0.0
statamic/seo-pro: 7.12.3
stokoe/forms-to-salesforce-connector: 0.1.0
stokoe/forms-to-wherever: 0.0.9

Installation: Fresh statamic/statamic site via CLI

That's the local environment I reproduced on; production runs the same Statamic and PHP versions. No log output — nothing is thrown, the query just returns a different result set.

I also checked the code at v6.32.0 before filing and both methods are unchanged there, so this isn't something 6.24.2 is behind on.