👉 Important: this is for **version** updates only, not for security updates, which are handled separately and don't depend on this configuration.
---
PR 3229 updated the GitHub Actions workflows used in this repo to use "pinned" versions for external action runners to improve workflow security.
The current "frequency" is weekly. As these updates are rarely time-sensitive, it should be fine to receive them less frequently.
This commit tries to make it so by changing the Dependabot schedule for GitHub Actions to once every two weeks and late in the day when the queue should be mostly empty (as long as it's not a Monday), so the update PR will come in on a more predictable schedule.
The `htmlspecialchars()` function is used to escape arbitrary text strings for display.
Original the default for the `$flags` parameter of that function in PHP was `ENT_COMPAT`, which translates to "convert double quotes to `"` and leave single quotes alone".
As of PHP 8.1, the default value for the `$flags` parameter has been made more robust and was changed to `ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML401`, which translates to "convert both double and single quotes, replace invalid code unit sequences with a Unicode Replacement Character and treat code as HTML 4.01".
For code to provide the same/predictable output cross-version PHP, the `$flags` parameter should be explicitly set and what with the new default value being the more robust one, this commit adds that value for `$flags` in all instances of function calls to `htmlspecialchars()`.
Once the application minimum PHP version is PHP 8.1 or higher, the parameter can be removed again (as the value will then be the same as the default parameter value).
Ref: https://www.php.net/manual/en/function.htmlspecialchars.php
Best practice tweak regarding the use of PHPCompatibility.
It is strongly recommended to use inline ignore annotations when a reported issue is not a problem (because it is accompanied by a `function_exists()`, `defined()` or other check), instead of excluding a rule completely via the ruleset.
Blanket code-base wide ignores mean that:
* ... if a PR introduces new code (or changes existing code) which uses a non-cross-version compatible PHP feature...
* ... and the code doesn't have the right safeguards in place for cross-version compatibility...
* ... PHPCompatibility would not flag it because of the codebase wide ignore...
* ... which could cause problems for the end-users.
Selective, inline ignores ensure that only the annotated error is ignored and only for that specific bit of code, preventing the above described problem.
It also means that when something changes in PHP - like a deprecated method being removed -, you will be notified about the issue again so you can review if the current cross-version compatibility tweak is still the most optimal one.
Long anticipated, finally here: PHPCompatibility 10.0.0-alpha1 🎉
PHPCompatibility 10.0.0 brings huge improvements in both what is being detected (> 50 new sniffs), as well as the detection accuracy for pre-existing sniffs.
Even though still "unstable", it is stable enough for our purposes and the advantages of using it outweigh the disadvantage of it being an unstable version. By setting the `minimum-stability` and `prefer-stable` settings in the `composer.json`, we can ensure that we don't get the `dev-develop` branch, but rather get a `10.0.0` tag, unstable or not.
Includes updating the PHPCS version constraints to match.
Includes updating the exclusions in the ruleset for changes in the error codes due to further changes in PHP having been made (and now being detected).
Ref:
* https://github.com/PHPCompatibility/PHPCompatibility/wiki/Upgrading-to-PHPCompatibility-10.0
* https://github.com/PHPCompatibility/PHPCompatibility/releases/tag/10.0.0-alpha1
... which is expected to be released this Thursday.
* Builds against PHP 8.5 are no longer allowed to fail.
* Update PHP version on which code coverage is run (high should now be 8.5).
* Add _allowed to fail_ build against PHP 8.6.
* Update the README.
Note: for some jobs I use "nightly" for the "next" PHP version, for some `8.6`. While it may appear there is no difference and this is true for the better part of the year, there is a difference for about two months.
To illustrate, consider PHP 8.5:
* PHP "nightly" refers to the PHP `master` branch, so was PHP 8.5 until the PHP 8.5 was branched off when the first RC was cut in September.
* As of that moment, "nightly" basically became PHP 8.6, so to test against PHP 8.5, one would need to explicitly request `8.5`.
* As of the release of PHP 8.5, it is expected for "nightly" to be PHP 8.6, so the difference is moot again.
For that reason, the unit test workflow uses the explicit `8.6` version for PHP "next".
As things were, test runs on forks would always fail on the "upload code coverage reports" step, as forks (justifiably) don't have access to the `CODECOV_TOKEN`.
Fixed now by updating the conditions to run that step.
The `roave/security-advisories` package was an inventive method to block installation of known insecure versions of other dependencies (via a `conflict` annotation).
As of Composer 2.9, using the `roave/security-advisories` package for this purpose is no longer needed as Composer will now natively block installation of known insecure versions of dependencies.
And while not all contributors to this repo may be using Composer 2.9+ (yet), Composer 2.9+ **_will_** be used in CI and CI failing on Composer blocking an insecure dependency offers the same level of protection as the package previously offered.
Refs:
* https://blog.packagist.com/composer-2-9/
* https://github.com/composer/composer/releases/tag/2.9.0
If generating an OAuth2 token fails in the provider and an exception is thrown, we never catch that exception, but just let exception propagate up to whatever.
I suggest this change, such that we can handle errors when generating oauth tokens. It is based on the fact that ^League\OAuth2\Client\Provider\AbstractProvider` can throw exceptions during getting the oauth token, but we are nowhere near to knowing why.
I have decided on catching all exception (`\Exception`) because if someone uses another OAuthTokenProvider (it's just an interface, so it's possible), we won't know specifically which exceptions can be thrown here, so we need to catch them all.
By throwing a PHPMailer exception and adding the existing exception as the `$previous` variable, we can show a generic error message to regular users and advice how developers can get actually meaningful error messages from the previous exception.
Marcus Bointon
Robin van der Vliet
dependabot[bot]
jrfnl
Jesper Skytte
Adrian Thomassen