[Resolved] CRED Expiration executes after post expiry is removed
This thread is resolved. Here is a description of the problem and solution.
Problem:
Posts that got their expiration disabled before CRED 1.9.2 might still get expired at their last known expiration time, or at the next time the check for expired posts is cheduled to happen according to your CRED settings.
This support ticket is created 7 years, 2 months ago. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
I have posts created with CRED with a post expiration action. On a certain date the post should change status to pending.
I have removed the expiration from multiple posts BUT they keep changing status to pending even if the post has no post expiration setting any more.
I have to check daily and bulk edit posts to change them back to publish.
What should I do to make it stop?
Please forward, that this problem still exists, to "Juan De Paco" who has been kind enough to report to me that this was fixed.
I have found the internal issue tracker and see that this should be now fixed in the current stable release.
I have to ask, if you still used the patched version (using the erratum) or if you run the latest (fresh install from FTP) version of CRED.
If so, I will immediately inform Juan to include the steps in the tests and check this again.
Meanwhile, I know CRED stores the expiration settings for each post in the related post meta table.
This means, with the correct Post ID, you can find three fields in each post that are related to the expiration time.
_cred_post_expiration_time
(A timestamp, marking the exact date of expiration)
_cred_post_expiration_notifications
(Notifications for this expiration)
_cred_post_expiration_action
(the actions to perform after the expiration)
Now, when I uncheck the "Automatic expiry date for this post" in the post and save it, the field _cred_post_expiration_time is set to 0 and _cred_post_expiration_action is removed.
This could perhaps be a problem, having a 0 in a timestamp would mean the post expired... in the past. I will ask if it is not better to remove that as well just like the actions field.
But, it should therefore not be any problem at all, at least, not on a clean local test install.
The posts do not come back as expired.
This got to me, thanks for asking Beda to involve me in this issue.
The fix we provided in CRED 1.9.2 should be enough as for posts whose expiration settings are removed after applying it. In other words, if you happen to remove expiration for a post after upgrading to 1.9.2, the post should not get expired. At last that is what my, and our, tests proved. I might be wrong, in which case I would probably need some extra information.
However, you are right and I fear that posts whose expiratio settings were removed before upgrading to 1.9.2 might still suffer from the old problem, meaning that they still might get expired.
I am working right now on this and I am confident I will have a solution in the coming hours, which will go along with an errata and that will get released as a next CRED 1.9.3 in the near future.
I thought that could be the case.
I keep deleting the meta keys manually in db, for posts that convert to pending.
So if you say that new posts will not have this problem then I will eventually get through all my old posts, created before the upgrade.