Open bernattorras opened 5 years ago
Thanks for the suggestion @menakas.
Yes, I also thought about this approach, but I thought that it would be a bit redundant to call the same function twice. In any case, if you think that there are cases that will be affected, I agree that it will be safer to call it twice! :)
@bernattorras I tested the calling twice method on our magazine subs import and it worked perfectly setting the End Date to the imported value rather than the current time at import. Thanks for your help with ironing this out, it saved us a lot of time and now allows us to accurately target win-back campaigns for expired subscribers.
Hi same issue here - did you fix this ? my end_date gets the current value. I am trying to use _schedule_end from wp_postmeta now because it is basically not working for me. If you know why, I am interested.
Description
When you're importing expired subscriptions with their "End date", this date is automatically replaced by the current date (the importation time).
Steps to replicate
_schedule_end
] from the database to have an old date)Expected results
After importing the subscription, its "End date" should be the same date that was specified in the CSV.
Result
The "End date" of the imported subscription is replaced with the current date.
Origin of the issue
I see that the plugin updates the dates of the subscription before updating its status. In this case, when the status of a subscription is updated to "Expired", it overwrites the "End date" with the current date.
Note
I suggest to move the update_dates() call after the update_status() to make sure that the imported dates are preserved. I'm not sure though if removing this call from the previous location affects any specific cases (at first glance, this change doesn't seem problematic, as both methods will be called anyway, and the doesn't seem to be any specific reason to update the subscription dates before).
Fixes #201