Yet another predefined action has had a major release.
This is, again, mostly just a change of the Node version used by the action itself (from Node 12 to Node 16).
Refs:
* https://github.com/codecov/codecov-action/releases
A number of predefined actions have had major release, which warrant an update the workflow(s).
These updates don't actually contain any changed functionality, they are mostly just a change of the Node version used by the action itself (from Node 14 to Node 16).
Refs:
* https://github.com/actions/checkout/releases
The `dealerdirect/phpcodesniffer-composer-installer` Composer plugin is used to register external PHPCS standards with PHPCS.
As of Composer 2.2.0, Composer plugins need to be explicitly allowed to run. This adds the necessary configuration for that.
Refs:
* https://blog.packagist.com/composer-2-2/#more-secure-plugin-execution
The `$CharSet` property name as declared in the class starts with a capital, while there were two places in the code where the property was referred to as `$this->charSet`, which is a non-existent property.
In PHP 8.2, this is regarded as access to a dynamic property and will generate deprecation notices.
In effect, this meant that the `PHPMailer::parseAddresses()` method would be called with `null` as the value for the `$charset` parameter.
This `null` value would then subsequently be passed on to the PHP native `mb_internal_encoding()` function, which now didn't get the correct encoding.
This may have led to mail sending failures due to the address encoding being incorrect. If there are any bug reports open for this, it may be a good idea to evaluate whether they could be related to this bug.
Found by dseguy via Exakat.
Note: this issue was not flagged by the tests as the tests for the `PHPMailer::parseAddresses()` method, only test the method either with a valid value for encoding òr without the `$charset` parameter set, but not with an explicit `null` value..
As the `$charset` parameter for `PHPMailer::parseAddresses()` has a sensible default value and is not explicitly nullable, adding a test for this incorrect use of the method seems over the top.
I have, however, ensured that the non-nullability of the parameter is now documented for the method.
Refs:
* https://wiki.php.net/rfc/deprecate_dynamic_properties
* https://www.php.net/manual/en/function.mb-internal-encoding.php
PHPCS 3.6.2 added a sniff for a PSR-12 rule which was previously not strictly checked: "No blank line after the opening brace of a class".
This fixes the newly flagged issues.