When loading an email post in the editor we need to attach MailPoet
specific data like associated newsletter entity id, email type etc.
This is done using register_rest_field function.
So far we only send the associated entity ID but there is also a method `saveEmailData` that will
be used to save MailPoet specific email data.
[MAILPOET-5365]
This commit adds a simple implementation of ensuring the mailpoet_email post type
has associated NewsletterEntity.
In the future we will need to add support also for saving additional data for
newsletters (subject, sending settings).
[MAILPOET-5365]
The email body will be stored as a wp_post, but for mailpoet specific attributes
we will use the current DB structure so that we can easy integrate emails edited in the new editor.
[MAILPOET-5365]
The idea is that there is a core class
Mailpoet\MailPoet\EmailEditor\Core\EmailEditor which will contain common email editor related stuff
that can be used and shared between projects.
Mailpoet\MailPoet\EmailEditor\Integration\EmailEditor which contains MailPoet specific settings and and extra modifications
specific for MailPoet.
[MAILPOET-5365]
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]
Selected shipping methods were not appearing when after saving and
reloading a segment because the instanceIds were actually coming through
as integers, while the values are getting saved as strings.
MAILPOET-5496
