Because of the recursion in these functions, processing very large
arrays would take a very long time. I rewrote the functions to
eliminate any unnecessary recursion and function calls. Large arrays
are now processed much faster.
Since both metadata and word ending in metadata have caused issues in
the past, uninflecting them seems like the best option. This will also
cover cases like ProfileData not being inflected to ProfileDatum which
seems like an improvement to me.
Fixes#4419
Instead of turning on/off strict mode based on the user supplied input,
cast everything to strings and always use a strict check. This avoids
the potential issue of a bad user using hexadecimal when they should not
be allowed to do so. Thanks to 'Kurita Takashi' for pointing this out.
Historically [prop=1] has matched prop=true as well. This restores that
and also fixes [prop=0] not finding falsey values.
This makes the typing less strict in Hash::extract() but I don't think
it is unreasonable given PHP's type juggling.
Refs #3288
Both `2a` and `2x` are valid types of blowfish hashes, that while being
older should be accepted.
Backport 00c94bd582b83f8b92228b750aea0e8816a4ea89 from 3.x to 2.5.x,
I see this as a bug fix as it fixes incompatibilities with hashes
created by hash_password().
Refs #3575
When using comparison with a boolean, as the filter is a string, we have to convert the data boolean to "boolean string" to avoid type-casting troubles.
## Example
```php
$users = [
[
'id' => 2,
'username' => 'johndoe',
'active' => true
],
[ 'id' => 5,
'username' => 'kevin',
'active' => true
],
[
'id' => 9,
'username' => 'samantha',
'active' => false
],
];
$unactiveUsers = Hash::extract($users, '{n}[active=false]');
print_r($unactiveUsers);
```
This example returns the two unwanted active users because `"false"` is `true` but not `false` :)
I think this pull request will fix this issue by converting true/false boolean to string (to match with our filter).
