- Rename validator to newsletterValidator for clarity
- Add validation for ALC content
- Refactor tests to use data factory for consistency and to avoid
validation issues
- Add separate tests for NewsletterValidator service
- Add test helper for retrieving service with private properties
overridden by name
[MAILPOET-4236]
Having separate objects for validation results is unnecessary and overly
complicated at this point, and we should wait to introduce that kind of
complexity only when/if it's clearly needed.
[MAILPOET-4191]
Segment and Subscriber subjects can be stateful, with specific segments
and subscribers loaded into them, so we should probably get separate
instances of them instead of sharing that state and potentially getting
unexpected behavior.
[MAILPOET-4191]
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]
In this commit I copied and slightly modified functionality used
for creating Mailer instance based on config from the Mailer to an extra class.
The functionality still remains also in Mailer and will be removed later.
I also created test based on the original test for Mailer and added test case
testing it creates specific MailerMethods.
[MAILPOET-4115]
For now trigger keys are stored in the workflow as a JSON array.
This is not optimal in case someone has many workflows but as
workflows are user-created it's unlinkely someone will have thousands
of them. We can consider adding a workflow_triggers table as well.
[MAILPOET-4136]
This is a simple service used only for prototyping that will allow us
to simply change and recreate database schemas. Eventually, we'll need
to replace it with database migration logic.
[MAILPOET-4135]
Each endpoint will be a class that can implement get/post/put/delete methods.
The routes are registered to WP REST API automatically based on the existence
of implemented methods. The endpoint classes are handled standard services and
therefore can leverage full powers of the DI container.
[MAILPOET-4135]
