The `extension_loaded()` PHP function is sometimes disabled by shared hosts as a form of "security by obscurity".
This would lead to a fatal "Function not available" error.
With that in mind, replacing the `extension_loaded()` checks in the `PHPMailer::parseAddresses()` function with a check for the `MB_CASE_UPPER` constant being defined. This _should_ be reliable enough to determine whether the Mbstring extension is available, though has its own drawbacks as when the extension is not available, the constant _could_ be polyfilled by userland code (and sometimes is).
The `MB_CASE_UPPER` constant was chosen as it is one of the few Mbstring constants which is actually available cross-version in PHP 5.5-current.
Refs:
* https://www.php.net/manual/en/mbstring.constants.php
* https://php-legacy-docs.zend.com/manual/php5/en/mbstring.constants
... to test that passing an invalid email address in combination with an instance of the `PHPMailer` class which was instantiated with `$exceptions = true` results in an exception.
Includes reworking the `testSetFromFail()` method to a data provider and letting both the `testSetFromFail()` and the new `testInvalidAddressException()` method use the same data provider.
Make the failure test more comprehensive by verifying that when the method fails, the values for the `From`, `FromName` and `Sender` properties, _really_ haven't changed.
Based on the code in the method, any existing, previously set `Sender` should not be overruled, even when the `$auto` parameter is set to `true`.
This method tests that specific situation.
* Merges the two "success" tests from the `testAddressing()` and the `testAddressing2()` methods into one `testSetFromSuccess()` method.
* Adds additional assertions to more comprehensively verify that the method did what was expected, i.e. set the `From`, `FromName` and `Sender` properties.
* Maintains the same test cases.
* Makes it easier to add additional test cases in the future.
So far, these methods were only tested in the most perfunctory manner.
The additional tests this commit introduces, test all aspects of the methods as well as documents the current behaviour of the methods.
Take note of the "text merging"/readability issues for the SMTP error messages. There may be room for improvement there.
... by a much simpler test which effectively tests the same thing, i.e.:
* No errors to start with.
* Trigger an error.
* Verify that `PHPMailer::isError()` returns `true`.
* Verify that the error message is as expected.
What with the previous commit adding a requirement for the `Mbstring` extension to the existing tests, it becomes clear that the "Mbstring extension not available" code path was not covered by the tests.
This commit fixes that by:
* Adding two new test methods which explicitly expect the Mbstring extension to **not** be available.
* Changing the data provider "expected(Imap)" keys.
The `expected` key in the array will now be an array of arrays.
A `default` key can be used for when the output across configurations will be the same.
Any differences across configurations can be provided in separate sub-keys of the `expected` array, using the `native+mbstring`, `imap+mbstring`, `native--mbstring` and/or `imap--mbstring` keys, which match the four test methods which are now in place.
Additionally, an `native` and/or `imap` key can be used for setting the output expectations for the two native implementation or the two IMAP implementation tests, if the Mbstring extension makes no difference.
Follow up to #2266
Bug fix
In both "arms" (imap vs native implementation) of the `PHPMailer::parseAddresses()` method, the `mb_decode_mimeheader()` function is used to decoded a (utf-8) encoded name.
In the IMAP "arm", a check was in place for the Mbstring extension being available before using it. This check was missing from the "native implementation" "arm".
Existing Tests
This also means that both currently existing tests have a requirement for the MbString extension being available. This was previously not made explicit in the tests.
Fixed now.
... which should be handled correctly based on the code in the method under test.
With these additional test cases, the method now has 100% code coverage and is fully tested.
Using a regex assertion with arbitrary input data which is not regex escaped, makes this test suspect.
From the looks of it, the test _should_ be testing that the output is the _same_, so let's use that assertion.
This commit:
* Adds a new `testFailToAttach()` test method to test the behaviour of the `PHPMailer::AddStringEmbeddedImageTest()` method when the `PHPMailer` class has been instantiated with `$exceptions` disabled.
* This new test method uses the same data provider - introduced in the previous commit - as the `testFailToAttachException()` method.
This commit:
* Renames the `testStringEmbeddedImageEncodingException()` test to `testFailToAttachException()`.
* Reworks the test to use a data provider.
* Adds testing of the exception message to the `testFailToAttachException()` method.
This commit:
* Improves the test name and the description in the docblock.
* Replace a redundant condition and "forced" failure assertion with an assertion actually testing the result of the method call.
* Removes the redundant `return` - if an assertion fails, the rest of the code within the test method will not be executed anyway.
* Minor inline comment tweaks.
The actual "attaching" of the string attachment happens within `createBody()` which is called from `preSend()`, so this test doesn't actually need to call `send()`.
In a number of places in the code base I came across hard-code error messages, which were not set up to be translatable.
For those I found, I've now fixed this.
Note: I've not added the labels used for logging errors via the `PHPMailer:edebug()` method. If so desired, that could be added in a future iteration.
Existing translation files have not been updated. Translators may need to be pinged before the next release to update the translation(s) they maintain.
Includes a minor tweak to the PHPCS configuration to allow lines in language files to exceed the "120 chars line max" as using concatenation for text strings in translation files will not work with the current way of loading these files and the new "buggy PHP" message is a long text which would result in nearly all translation files throwing the warning.
jrfnl
Marcus Bointon