Forum Replies Created
-
Posts
-
I installed the WP Crontrol plugin on Dev and Prod and reviewed the scheduled cron events. It was hard at first to tell if hitting “Run” on either the “tribe_events_pro_process_recurring_events” or “tribe-recurrence-cron” actually did anything.
One difference between Dev and Prod is that we have the “Create recurring events in advance for” option set to 3 months on Dev and 6 months on Prod. I started thinking that maybe 6 months is too much for Prod to handle, so I switched it to 2 months. Still didn’t seem to finish so I dropped it to 1 month with no success.
Then I went back to WP Crontrol and tried running both cron events again. I noticed that running “tribe-recurrence-cron” seemed to trigger changes for about 15 minutes at a time. The total number of events would decrease by about 100 events each time I ran it, then it would stop. I think the decrease in events makes sense since this process should be clearing out old events, while possibly also deleting future events more than 2 months out.
Dev currently has 17,161 total events, while Prod has 23,691. We know that Dev looks better than Prod at this point, so I was hoping that continually running the “tribe-recurrence-cron” would get Prod to look more like Dev. In any case, it seems that something causes it to stop running after about 15 minutes – even though it appears to have a lot more work to do.After the cron jobs complete, I do not see additional errors in the error log that would indicate what might be going on. Memory errors, database errors, nothing like that.
The hosting company (synthesis) shared the following with me:
We use the following cron job form the server side to perform the wp-cron process:
*/5 * * * * www-data wget -O /dev/null -o /dev/null http://domain.com/wp-cron.php
Could you please share these details with the plugin author? We can also implement any custom cron job that you or your site may need for getting everything working as expected.
The batches that you mention never seem to complete and that appears to be the issue that has been going on with our events. As you noted, we do have a very large amount of events and we were told that the pro version would be tolerant of any number of events. These batches should eventually get caught up but we have been experiencing this issue since September and they never seem to add new events unless we manually edit/save a recurrence.
Are there batch processing logs that we can review to find out why this is failing? I will share your questions with our web host and let you know the answers that they provide.
Niko,
We did some testing on 4.0 and updated in both our dev and prod environments.
Some notes from my web developer:
I installed the WP Crontrol plugin on Dev and Prod and reviewed the scheduled cron events. It was hard at first to tell if hitting “Run” on either the “tribe_events_pro_process_recurring_events” or “tribe-recurrence-cron” actually did anything.
One difference between Dev and Prod is that we have the “Create recurring events in advance for” option set to 3 months on Dev and 6 months on Prod. I started thinking that maybe 6 months is too much for Prod to handle, so I switched it to 2 months.
Then I went back to WP Crontrol and tried running both cron events again. I noticed that running “tribe-recurrence-cron” seemed to trigger changes for about 15 minutes at a time. The total number of events would decrease by about 100 events each time I ran it, then it would stop. I think the decrease in events makes sense since this process should be clearing out old events, while possibly also deleting future events more than 2 months out.
Dev currently has 17,161 total events, while Prod has 23,691. We know that Dev looks better than Prod at this point, so I was hoping that continually running the “tribe-recurrence-cron” would get Prod to look more like Dev. In any case, it seems that something causes it to stop running after about 15 minutes – even though it appears to have a lot more work to do.Maybe some of that would be good to share with the calendar support. They might know more about the crons and why it would stop running early.
Please let me know if you have any insight on this. As you can imagine, refreshing this many events manually is an extremely daunting task.
Hi Josh,
Yes, I have already tested for conflicts.
I am hesitant to increase the memory limit because we’ve never had to do that before. It wasn’t until the latest update that this became an issue. The other support threads I found with similar issues were reported recently — is it possible that there is an issue with the latest update that causes too much memory to be used when loading the month view?
Hello, just wanted to check in to see if the server details were any help.
Is there something we can run to re-save all recurring events at once so the future events will be generated again?
Thanks!
New recurring events work fine, updating existing events will recreate the future events for the recurrence window (3 months). Unfortunately, the volume of events that would need to be updated is too great for it to be feasible as a manual process.
Is there a command that we can run that might re-save each recurring event without having to do this manually? I realize the cron is supposed to do this but in its absence, is there an alternative?
Server details to follow in a private post.
