In the previous commit, I removed all calls to the deprecated
utf8_encode() that seemed safe to remove. In this commit, I'm replacing
the calls to this function that I'm not sure if are same to remove or
not with mb_convert_encoding().
mb_convert_encoding() requires the extension mbstring to be enabled. It
should be enabled on most PHP install but not all. We are already using
mbstring functions in our code base and we provide a polyfill for PHP
installs where the extension is not enabled
(62bb75ed91/mailpoet/prefixer/composer.json (L25)).
So it should be safe to use it.
[MAILPOET-4865]
A previous test must have sent a confirmation email to a subscriber with
the same ID.
This didn't seem worth adding to the cleanup extension since it was
only causing a single failure.
MAILPOET-5145
When sending is paused due to some MSS configuration error the confirmation
email error may cause that the important error from MSS gets overwritten
event reset in case the mail is accidentally sent.
[MAILPOET-4940]
Setup confirmation email customizer in ConfirmationEmailMailer and trigger confirmation email template creation when visual subscription confirmation emails is enabled from settings
MAILPOET-4649
The current Captcha class has a lot of responsibilities. It renders the captcha
image, can check if a certain captcha type is a Google captcha, if a captcha is
required for a certain email. The SubscriberSubscribeController is not only in
charge of "controlling" the subscription process but also validates, whether a
captcha is correct or not. This architecture made it difficult to extend the
functionality and introduce the audio captcha feature.
Therefore this commit refactors the captcha architecture and tries to seperate
the different concerns into several classes and objects. Validation is now done
by validators.
The CaptchaPhrase now is in charge of keeping the captcha phrase consistent
between the image and the new audio, so that you can renew the captcha and both
captchas are in sync.
[MAILPOET-4514]
We can't create mailer directly in DI container using the factory because it may fail in case
the plugin is not configured properly and prevent plugin from start.
The Mailer was previously injected because it contains lazy initialization.
The lazy initialization in the singleton Mailer service was dangerous,
because when used with some custom parameters it could cause that all services
that inject the Mailer from DI would use the custom config instead the default.
[MAILPOET-4115]
