This ensures that all methods imported from @wordpress/hooks write to the same
instance and thus "addFilter" used in one part of the code works with "applyFilters"
called in another place.
In the future, we should use DependencyExtractionWebpackPlugin to always access
the window.wp.hooks object rather than bundling @wordpress/hooks with our code.
[MAILPOET-5653]
This is only tangentially related to this ticket. I noticed during
testing that the filter segment tag was not showing up in listings for
standard newsletters that were drafts or scheduled. This is because
options weren't included in the response for standard newsletters.
MAILPOET-5512
If the user creates a segment specifically as a filter segment for an
email, we should redirect them to that email's send step after a
successful save.
MAILPOET-5512
A note on using context: we need to be able to save the draft of the
newsletter before redirecting users to the segment creation page,
otherwise they might unexpectedly lose their work. The link exists in
a field, so the alternative to using a context seemed to be passing this
function down as a prop, first to the Form and then to all of the
fields, whether they needed it or not. This seemed clunky at best, and
require changes to Form and Fields that get used many other places in
the plugin.
Using a context was the cleanest solution I could come up with for
avoiding those changes.
MAILPOET-5512
It's not a critical error if we aren't able to save this lookup data,
and we wouldn't want it to interfere with the sending of a newsletter,
but we should log it as an error for debugging purposes.
MAILPOET-5625
For ease of lookup, I changed the helper to return an array with keys
corresponding to the instanceId of the shipping methods. I couldn't see
anywhere else in the codebase where the keys would have mattered.
MAILPOET-5625
This method is intended to store the actual names of things that might
change or be deleted in the future, so we can include accurate
information when showing what the snapshot of the filter was at the time
.
MAILPOET-5625
Whenever the user goes to add a new segment, MP displays `WordPress user
role` as the default condition. But there was a
bug that was preventing the default condition from being displayed, if
the user left the page by clicking in the back button, and then returned
clicking again on the `Create custom segment` button.
This bug was introduced in dba4ba4dfc.
It added code to unset the segment when the user left the segment
editing page. This was necessary as, in that PR, we started using the
same store for all the dynamic segment pages. The problem is that the
added code sets the segment to an empty array and actually we need to
restore the initial state which is a segment with the `WordPress user
role` selected as its single filter. This is what is done in this commit.
[MAILPOET-5614]
