ImportExportRepository::updateMultiple() changes subscribers by running
MySQL queries directly. Now that \MailPoet\Segments\WP uses Doctrine as
well this was causing a bug caught by our integration tests.
```
MailPoet\Subscribers\ImportExport\Import\ImportTest::testItSynchronizesWpUsers
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'mary'
+'Mary'
/wp-core/wp-content/plugins/mailpoet/tests/integration/Subscribers/ImportExport/Import/ImportTest.php:719
```
https://app.circleci.com/pipelines/github/mailpoet/mailpoet/16386/workflows/c3fa0cf4-a77d-41ab-a5cc-78d4b37d9228/jobs/278066/tests#failed-test-0
This test was failing because the Doctrine entities were not updated
after the import process ran and modified the subscribers directly in
the database. Running EntityManager::clear() after importing the
subscribers, forces Doctrine to query the database again to update the
entities and prevents this bug.
[MAILPOET-5752]
In the previous commit, we removed the global count for our output. This commit removes
the logic as the only places where it was used was in recalculating the cache and since
the last commit, we do not use this value anymore
[MAILPOET-4487]
To evaluate whether a user is subscribed to a list or unsubscribed you need to take into account
the status of the current subscription and not only the global status. To be unsubscribed you are
either globally or per list unsubscribed. To be subscribed you need to be globally and per list
subscribed
[MAILPOET-4487]
This makes SubscriberStatisticsRepository the source of truth for
engagement score data instead of having separate queries.
As part of this change, we will now only be displaying the last year's
worth of data when viewing a report for an individual subscriber.
It also updates engagement score calculation to only count human opens,
not machine opens.
MAILPOET-5410
Previously there was a mismatch between parameters coming from the
dynamic segment and the parameters coming from the export
controller.
[MAILPOET-5382]
I found this method in the context of a ticket to refactor Paris code to
Doctrine. As far as I can tell, it is not used anymore and it is
safe to delete it.
It was added in 1af5802 and was used only inside
Models\Subscriber::subscribe(). Then subscribe() was moved to
Subscriber\SubscriberActions in 7528f0f. Finally, commit 7db2384
refactored SubscriberActions removing the only two calls to
Source::setSource().
The test class SourceTest is removed as well as its only purpose was to
test Source::setSource().
[MAILPOET-5345]
We want to remove/refactor the whole ModelValidator class as part of the
Doctrine refactor.
This commit moves the method ModelValidator::validateNonRoleEmail() to a
new Validator class as the method is not used by the validator system of
the Paris models. ModelValidator::validateEmail() was also moved as it
is called by ModelValidator::validateNonRoleEmail().
[MAILPOET-4343]
We want to remove/refactor the whole ModelValidator class as part of the
Doctrine refactor. As a first step, this commit removes the method
ModelValidator::validateIPAddress(). It was unused in a single place and
it was replaced with a direct call to the builtin PHP way to validate an
IP address.
[MAILPOET-4343]
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]
