What does autoblog_process_all_feeds_for_cron do (in my list of cron jobs) and why does it run every

I have a large multisite install (1500+ sites) that is set to pull in feeds to every child site every hour. Using a plugin (cron-gui) I can see what cron jobs are running on any site. On each site, autoblog_process_all_feeds_for_cron is set to run every 5 minutes.

Why is this running every 5 minutes when my feeds are set to 1 hour? I would not like to be running a process every 5 minutes on all sites on the same server so if it wouldn't hurt to make this check every hour instead, I'd like to do so.

  • Timothy Bowers

    Why is this running every 5 minutes when my feeds are set to 1 hour?

    Sorry just to be clear.

    It's running every 5 minutes to see what needs processing. If items you've added need to be processed then they will get done, if not they won't.

    So lets say at 15:20 you have a feed called A scheduled to update, but you changed the checklimit as mentioned above to 60 minutes and that gets called at 1515, no feeds will then be checked for processing until 1615 which is when A the 15:20 one will be processed.

    Take care.

  • jasonjulien

    That makes sense, thank you. For some reason I was thinking each feed had it's own cron job, but I would have seen that if it was the case.

    A developer on my team noticed a potential bug in Autoblog just recently. In the process_feed (and test_feed) functions in autoblogprocess.php there is a for loop to go through all the found posts in a feed. Within the loop is a call for switch_to_blog but the restore_current_blog is outside of the loop. This means that the blog restored will be whatever the ID was before the last switch_to_blog was called, and not necessarily what the ID was before running the loop. If you're hopping blogs this way you should have a restore_current_blog for every switch_to_blog. Easy fix though, just move the small block that contains switch_to_blog up and outside of the for loop. I don't see a reason why it would be wanted within the loop in the first place. I wanted to see if this was indeed a bug and should be corrected. It could cause processes to be run on the wrong sites.

    Please let me know if I'm mistaken and this has already been taken into consideration somehow.

  • Timothy Bowers

    Hey again.

    The restore_current_blog restores the previous blog ID and not the actual current blog. see:

    http://codex.wordpress.org/WPMU_Functions/restore_current_blog

    Restores previous blog after a switch_to_blog call.

    Contrary to the function's name, this does NOT restore the original blog but the previous blog. Calling switch_to_blog() twice in a row and then calling this function will result in being on the blog set by the first switch_to_blog() call.

    Take care.

  • jasonjulien

    That's right, and that's exactly the problem. If I am on blog 1 and then I switch_to_blog 2 and after that switch_to_blog 3,when I call restore_current_blog I will be at blog 2 instead of at 1 like I should. switch_to_blog is being called in every iteration of the for loop, so multiple uses of it and then one final restore_current_blog will not necessarily land you at the correct blog.

    I don't know if there's a case where a blog ID will change in the middle of processing a feed, but if it did there could be problems. If the blog ID will never change, it's a waste to call switch_to_blog on every iteration as it's an expensive function to run. At minimum moving it outside the loop would be a performance enhancement.

    I'm open to being wrong though so if there's something I'm missing please let me know.

  • Timothy Bowers

    switch_to_blog is being called in every iteration of the for loop, so multiple uses of it and then one final restore_current_blog will not necessarily land you at the correct blog.

    I see what you mean now and will of course run it by our developer.

    I'm not sure there is a case for the ID changing mid processing but Barry is the developer on this and will surely know all of his code more intimately than I so I'll ping him here to see if he can provide any feedback.

    Thanks.

  • Barry

    Hi, I know it's the holidays right now and you'll likely have to get in contact with the developer of this plugin about this problem, but can I get any sort of status update? A confirmation or even an "I don't know, we'll look into it" would be great. Thank you.

    There is already an updated version of the plugin with this fixed and ready to go when I get back to my dev machine next week.

    If I am on blog 1 and then I switch_to_blog 2 and after that switch_to_blog 3,when I call restore_current_blog I will be at blog 2 instead of at 1 like I should. switch_to_blog is being called in every iteration of the for loop , so multiple uses of it and then one final restore_current_blog will not necessarily land you at the correct blog.

    No, those functions are only called for a single feed at a time, so whilst the call was run in the loop (for processing items in the feed), it was always only switching to the same blog_id. The switch_to_blog function realises it is on the same blog as we were switching to after the first iteration and so didn't do anything, and so the restore only had the one restore to go back to. So whilst it was a bug in that it shouldn't have been within the loop, it actually didn't do anything other than be repeatedly called.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.