Before the phalcon5 compatibility layer, the unit tests were broken due to __isset()
being triggered by an isset call on an __items attribute in getConstraintValidators().
Since __items is only used in BaseField itself, we choose to remove it for further use. Instead,
we rely on __isset() to verify if elements exist in internalChildNodes when a subnode is accessed directly.
The second regression lived in validate() in the custom Validation implementation. Instead
of relying on the incoming data as a key, we iterate through all validators active during the objects' lifetime since
these are set prior to validation. This regression affected all constraints.
* phalcon5: update namespaces
* phalcon5 Autoload: rename registerDirs() to setDirectories()
* phalcon5: remove trailing slash
* phalcon5: default to php74-phalcon
* phalcon5: provide 4/5 compatibility layer except for AbstractValidator
* MVC - Phalcon 5 migration and options to lose dependency of phalcon validation classes.
Since Validation() in 5 moves to Filter\Validation (https://docs.phalcon.io/5.0/en/upgrade#general-notes) and the class is used in strict parameter passing,
it will be difficult to import a situation which works both on 4 and 5.
To prevent future issues, but keep the current situation functional with minimal changes, we wrapped Validation() into a class of our own. When validators inherit from BaseValidator, these are assumed to
be less strict and bound to our own handling. Phalcon validations will follow the old path for now.
Migrating existing validations on our end, should be as simple as changing the following lines:
-use Phalcon\Validation\AbstractValidator;
-use Phalcon\Validation\ValidatorInterface;
-use Phalcon\Validation;
+use OPNsense\Base\BaseValidator;
-class CallbackValidator extends AbstractValidator implements ValidatorInterface
+class CallbackValidator extends BaseValidator
- public function validate(Validation $validator, $attribute): bool
+ public function validate($validator, $attribute): bool
Todo: choose the "correct" Validation() based on phalcon version.
* phalcon5: complete migration to compatibility layer.
uses bc881b9c11 to remove the need
for AbstractValidator and Validator(Interface).
This commit changes the relevant includes and provides some changes to make the unit tests
run correctly.
* MVC - Phalcon 5 migration and options to lose dependency of phalcon validation classes. part duex
Although our previous strategy should work according to how bind() and validation() are being implemented (https://github.com/phalcon/cphalcon/blob/4.2.x/phalcon/Validation.zep),
in reality it seems they aren't the same. Our previous attempt failed some validations (such as booleans) for no valid reasons.
Long term we should remove the phalcon dependency as these effects are highly unpredictable.
phalcon5: update Validation class to now pick the right Phalcon Validation based on version
* MVC - Phalcon 5 migration and options to lose dependency of phalcon validation classes.
Minor regression in previous commit, performValidation()'s return type didn't match. Ideally we would rather switch to plain array's, but since performValidation()
is used in multiple areas (including plugins) we better opt for compatiblity now.
ref https://github.com/opnsense/core/pull/5711
* phalcon5: switch back to using count() on Messages object, adjust unit tests as needed
See 6814f32755 as to why
this is the case.
* phalcon5: remove PhalconGenerator and references, use checked-in files instead
* Update Makefile
Co-authored-by: Franco Fichtner <franco@opnsense.org>
Co-authored-by: Ad Schellevis <ad@opnsense.org>
Co-authored-by: Franco Fichtner <franco@opnsense.org>
Minor regression in previous commit, performValidation()'s return type didn't match. Ideally we would rather switch to plain array's, but since performValidation()
is used in multiple areas (including plugins) we better opt for compatiblity now.
ref https://github.com/opnsense/core/pull/5711
Although our previous strategy should work according to how bind() and validation() are being implemented (https://github.com/phalcon/cphalcon/blob/4.2.x/phalcon/Validation.zep),
in reality it seems they aren't the same. Our previous attempt failed some validations (such as booleans) for no valid reasons.
Long term we should remove the phalcon dependency as these effects are highly unpredictable.
Since Validation() in 5 moves to Filter\Validation (https://docs.phalcon.io/5.0/en/upgrade#general-notes) and the class is used in strict parameter passing,
it will be difficult to import a situation which works both on 4 and 5.
To prevent future issues, but keep the current situation functional with minimal changes, we wrapped Validation() into a class of our own. When validators inherit from BaseValidator, these are assumed to
be less strict and bound to our own handling. Phalcon validations will follow the old path for now.
Migrating existing validations on our end, should be as simple as changing the following lines:
-use Phalcon\Validation\AbstractValidator;
-use Phalcon\Validation\ValidatorInterface;
-use Phalcon\Validation;
+use OPNsense\Base\BaseValidator;
-class CallbackValidator extends AbstractValidator implements ValidatorInterface
+class CallbackValidator extends BaseValidator
- public function validate(Validation $validator, $attribute): bool
+ public function validate($validator, $attribute): bool
Todo: choose the "correct" Validation() based on phalcon version.
Unbound host and domain sort order.
Host and domain names are case insensitive. Should be handled case insensitively. myHost comes before YourHost. Always.
Sort order should be:
myHost
YourHost
Not:
YourHost
myHost
When migration failed into 22.1.5, this patch in combination with `/usr/local/opnsense/mvc/script/run_migrations.php` should fix migration issues. No new model version is needed as
the previous version wasn't able to migrate in this case. closes https://github.com/opnsense/core/issues/5693
