I'm unsure whether this is a bug in "libphonenumber-for-php" or if we're
misusing the library. This commit will ensure that only phone numbers
from a specific region will be considered valid. I've reported the issue
to "libphonenumber-for-php" anyways [1].
[1]: https://github.com/giggsey/libphonenumber-for-php/issues/621
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
In version 2.3, the Phone rule started to require
"giggly/libphonenumber-for-php" as a dependency. That was a backward
compatibility break, but the validation also became stricter, and phone
numbers without country codes would not be considered valid.
This commit will revert the backward compatibility break. That way, when
validating a phone number without a country code (the behaviour from
version 2.2), the Phone will not use an external library.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
The idea of the "ParameterStringifier" is to convert any value to a
string. However, we use the "stringify" function directly when
converting the input into a string. That defies the purpose of the
ParameterStringifier, as it gives the "Formatter" two ways of converting
a value into a string.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Country codes in ISO 3166-1 should be in uppercase, and the
`AbstractSearcher` should not change the input to search for a value.
While working on this fix, I also discovered that the
"PublicDomainSuffix" rule would throw an exception if it got a
non-scalar value as an input.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
The documentation states that we should use Validator::keySet() in
combination with Validator::key() but the return type of key() does not
match the expected parameter type of keyset().
Co-authored-by: Henrique Moody <henriquemoody@gmail.com>
For now, I'm ignoring many rules because they'll make the changes that
would bring backward compatibility breaks, and I'm aiming to release a
minor version next.
However, upgrading "respect/coding-standard" is necessary because
version 4.0 no longer works.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
Most exception messages in Validation use "must" and "must not" in their
templates, but a few rules don't.
I fixed most of them, but AlwaysValid and AlwaysInvalid remain because I
wonder if they will be better if I update them.
Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
- For this particular updater, a list of exceptions to the rules
downloaded by geonames is included in POSTAL_CODES_EXTRA, for
cases in which we seem to do better than geonames itself based
on previous user reports.
- Added an option to also validate formatting of the postal codes.
- Combined multiple PR bots into a single one.
Previously, we were loading country info from a JSON file. This
changes it to use PHP files instead. It also caches these resources
across calls avoiding these files to be loaded more than once
per process.
Doing regex on phone numbers is not a great idea. This is a breaking
change, but a good one. Phone validation is now much stricter, and
allows choosing the country.
The use case for negating a keyset is very confusing, and can
lead to validators that don't do what they expect.
This commit introduces NonNegatable rules, which will throw
a Component exception if you try to wrap them in `Not`.
This change was necessary to ensure proper message reporting
when extra keys exist on the keyset.
This fixes#1349
We currently use a GitHub action to automate updating this file.
That action has the ability to ignore making the PR if the file
didn't changed.
Having the version number, which changed a line, was causing
several useless PR.
Users can still check if Tld.php changed by seeing the git log,
and a manual note should be issued by the maintainer on the
CHANGELOG.md file when a release containing such changes is
made.
The `filter_var` function is more of a sanitizer, but we as
a validation library do not care for that use case.
We should treat its sanitizings as a signal for checking if
the type after sanitization matches the option provided.
This fixes#1387
[`json_validate` function](https://wiki.php.net/rfc/json_validate)
[added in PHP 8.3](https://php.watch/versions/8.3/json_validate) validates a
given string input to contain valid JSON without decoding it in memory.
This adds a function availability check to `Rules\Json`, and uses the new
function instead of decoding the given input, followed by a last-error check.
