[Resolved] Posts not trashed on CRED post-expiry time
This support ticket is created 7 years 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 found the same with the EWWW plugin conflict and am reporting that now. I don't know how you ended up with monthly in wp_options, and it is what is recorded there which is key. If you change the setting to hourly and wp_options is updated accordingly, you may be able to leave the EWWW plugin active as long as wp_options isn't modified.
Your latest question, I'm not sure what you mean, but it sets up a WordPress cron job which will run as long as your server is up and running, it is not dependent on any traffic to the website.
Let me know when enough time has elapsed in your tests for your posts to expire and if that works.
First test:
I updated form "ny bokning", 30 minutes expiry
Post Published on: May 4, 2017 @ 10:47
Post expiry says: May 4, 2017 @ 12:00 (1 hour)
Post db says: Thu, 04 May 2017 09:17 (time has already passed)
Second test
I updated form "ny bokning", 1 hour expiry
Post Published on: May 4, 2017 @ 10:50
Post expiry says: May 4, 2017 @ 12:00 (1 hour)
Post db says: Thu, 04 May 2017 09:50:14 (time has already passed)
Third test (to avoid time-zone conflict)
I updated form "ny bokning", 5 hours expiry
Post Published on: May 4, 2017 @ 10:53
Post expiry says: May 4, 2017 @ 16:00 (5 hours)
Post db says: Thu, 04 May 2017 13:53:43 (3 hours)
For all tests I'll wait to see what happens @ 12:00 and @16:00
Regarding cron.
There are different kind of crons. Either initiated by site traffic or run by itself, no matter if the site has visitors or not.
If you have the kind that needs traffic to the site to run, post expiry will not trash any posts on the set time if the site doesn't have visitors.
If this is the case I need to know if the cron will look "backwards" in time to remove those posts which time has passed. If so, I would have to create a custom function to account for that.
Can you ask developer which kind CRED cron uses.
Regarding EWWW, that is what I did. Disabled it, updated Cred setting and commenced testing. (see previous post)
@ 12:07
post no 1 - not deleted (this was set to 30 minute expiry)
post no 2 - was deleted - hurray (this was set to 1 hour expiry)
post no 3 - I'll get back at 16:00
The minutes settings are not valid options, the only valid options are hourly, daily and twice daily.
The EWWW plugin conflict has been reported already, I was waiting to hear back from you about your tests to see if I could go ahead and escalate this thread with that issue, which I am doing now.
The time zone confusions is separately reported and, according to the internal tickets, has been fixed and that fix will be included in the plugin updates expected next week.
Thanks for your own efforts in tracking this down.
Just one last thing.
I think you should report a "change-request", because we can't really call it a bug?
Either the settings in CRED forms need to remove the minute options or the main cron setting needs an additional option for minutes - or, it needs to be clearly stated next to the minute setting in a CRED form that minutes - less than an hour - does not work.
Personally I will never forget ? but your users needs to know. What if someone builds a system that relies on the minute setting ...
And yes,
The other ticket - have you heard anything?
Did you get an answer on what kind of cron CRED is using? (site traffic dependent or not)
We released updated plugins yesterday, and if you go ahead and update (after taking a backup) you should find changes in the CRED post expiration settings.
We simply added a nothing-selected option to the list of CRON intervals. In your site there was no interval selected, which made it look like the first option in the list—a custom interval added by the EWWW plugin—was selected, and meant that no CRON jobs ran at all.
It should now be clear if an interval is selected or not (though we don't have control over the intervals added by 3rd party plugins, such as the multiple 5-minute intervals added by EWWW).
I'm not sure that I ever answered your question about the type of CRON job: they require server activity. If there is no activity on the site, the CRON job will run the next time there is a site visit.
