PHP 8.4 removes the IMAP extension (moved to PECL).
With this in mind, I've reviewed how the tests are being run versus the extension requirements and recommendations.
As things are, the tests are currently run in the "ideal" environment, i.e. with all required and optional extensions available.
However, the codebase also contains fall-backs for when certain extensions are **_not_** available and for at least some of those fallbacks, there are dedicated tests available, but in an ideal environment those tests will not run and the fall-backs are not tested, which is the case with the current CI setup.
To improve this situation, I'm proposing to keep running the tests against all PHP versions with the "ideal" extension set, but to also have additional test runs with a far more limited set of PHP extensions.
To determine which extensions should be in each set, I've looked at the following:
* `@requires` tags found in the test suite and the conditions for calls to `markTestSkipped()`.
This brought to light that the `openssl` extension was currently not listed in the "ideal" extension set. This has now been fixed.
* The required extensions of PHPUnit - `dom, json, libxml, mbstring, tokenizer, xml, xmlwriter`.
* The required extensions of PHPMailer itself - `ctype, filter, hash`.
* Not strictly required, but more for convenience/workflow speed: `curl` for Composer.
* And `xdebug` will still be enabled/disabled based on the `coverage` setting.
Note: while some tests would benefit from being run _without_ the `mbstring` extension, that's unfortunately not an option as `mbstring` is a requirement of PHPUnit 🤷
Also note, the tests with the "minimal" extension setup needs to run `composer install` with an `--ignore-platform-req` flag to prevent running into the following issue:
```
Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.
```
As this extension "requirement" is for a dependency which is not used in the test run, the extension requirement can be safely ignored.
As per the discussion in 3092, this commit removes the `fakefunctions.php` file and adds explicit requirements for the `PHPMailerTest::testGivenIdnAddress_addAddress_returns_true()` test method.
Closes 3092
As things were, the `DKIMTest::testDKIMSignOpenSSLNotAvailable()` could not pass as the `DKIMTest` class sets the `USE_EXCEPTIONS` class constant to `true`, which means the method would fail on an exception.
As this test is specifically about testing the behaviour when exceptions are _disabled_, the test needs to be in its own test class, which sets `USE_EXCEPTIONS` to `false`.
That should allow the test to run properly and to pass.
As things were, the `DKIMTest::testDKIMSignOpenSSLNotAvailableException()` test _could_ potentially pass even when another `Exception` than the `PHPMailer\PHPMailer\Exception` was being thrown, as _all_ exceptions extend the PHP native `Exception` class.
Now this risk is not that high, as there is also a check on the exception message, but still.
Making the exception expectation more specific (by changing the import `use` statement), should still make the test more stable.
Composer 1.10.0 introduced a `lock` config option, which, when set to `false` will prevent a `composer.lock` file from being created and will ignore it when one exists.
This is a useful option for packages like PHPMailer where the `lock` file has no meaning.
It also makes life more straight-forward for contributors as they don't have to remember that for this repo they should use `composer update` instead of `composer install`. Both will now work the same.
Refs:
https://getcomposer.org/doc/06-config.md#lock
V4.1.0 of the SendOauth2 wrapper introduces two new optional operands for the invocation of both the standard PHPMailer email application and for the complete replacement of a PHPMailer application by the wrapper SendOauth2A front-end. These operands allow the developer to specify a name for the .json credentials file and/or whether the wrapper should dynamically build this .json file or use an already-built one, created either by Google (its standard download) or by the developer.
V4.1.0 of the SendOauth2 wrapper introduces two new optional operands for the invocation of both the standard PHPMailer email application and for the complete replacement of a PHPMailer application by the wrapper SendOauth2A front-end. These operands allow the developer to specify a name for the .json credentials file and/or whether the wrapper should dynamically build this .json file or use an already-built one, created either by Google (its standard download) or by the developer.
Marcus Bointon
jrfnl
Emmanuel Ferdman
murongshaozong
dependabot[bot]
ProjectSoft
decomplexity
Alexis Urien