cfd4b7635f
* 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. usesbc881b9c11to 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 See6814f32755as 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>
OPNsense GUI and system management
The OPNsense project invites developers to start contributing to the code base. For your own purposes or – even better – to join us in creating the best open source firewall available.
The build process has been designed to make it easy for anyone to build and write code. The main outline of the new codebase is available at:
https://docs.opnsense.org/development/architecture.html
Our aim is to gradually evolve to a new codebase instead of using a big bang approach into something new.
Build tools
To create working software like OPNsense you need the sources and the tools to build it. The build tools for OPNsense are freely available.
Notes on how to build OPNsense can be found in the tools repository:
https://github.com/opnsense/tools
Contribute
You can contribute to the project in many ways, e.g. testing functionality, sending in bug reports or creating pull requests directly via GitHub. Any help is always very welcome!
License
OPNsense is and will always be available under the 2-Clause BSD license:
https://opensource.org/licenses/BSD-2-Clause
Every contribution made to the project must be licensed under the same conditions in order to keep OPNsense truly free and accessible for everybody.
Makefile targets
The repository offers a couple of targets that either tie into tools.git build processes or are aimed at fast development.
make package
A package of the current state of the repository can be created using this target. It may require several packages to be installed. The target will try to assist in case of failure, e.g. when a missing file needs to be fetched from an external location.
Several OPTIONS exist to customise the package, e.g.:
- CORE_DEPENDS: a list of required dependencies for the package
- CORE_DEPENDS_ARCH: a list of special -required packages
- CORE_ORIGIN: sets a FreeBSD compatible package/ports origin
- CORE_FLAVOUR: can be set to "OpenSSL" or "LibreSSL"
- CORE_COMMENT: a short description of the package
- CORE_MAINTAINER: email of the package maintainer
- CORE_WWW: web url of the package
- CORE_NAME: sets a package name
Options are passed in the following form:
# make package CORE_NAME=my_new_name
In general, options are either set to sane defaults or automatically detected at runtime.
make update
Update will pull the latest commits from the current branch from the upstream repository.
make upgrade
Upgrade will run the package build and replace the currently installed package in the system.
make collect
Fetch changes from the running system for all known files.
make lint
Run serveral syntax checks on the repository. This is recommended before issuing a pull request on GitHub.
make style
Run the PSR2 and PEP8 style checks on MVC PHP code and Python, respectively.
make sweep
Run Linux Kernel cleanfile whitespace sanitiser on all files.