This issue is about dealing with feeds that for whatever reason should not be updated - temporary.
There are multiple ways this scenario can come about. A feed might be down, have DNS problems, be misconfigured, etc. Right now the only way to stop updating is to change update frequency to "Never" or "Manual". The downside is loss of 'regular' update interval setting.
To remedy the problem, we should add an extra setting (On/Off) to indicate if cron should run update process or skip the feed. This would require a boolean column in simplefeed_feed table and a checkbox on feed node form.
I am facing this as real issue the course of upgrading from aggregator2. Quite a few of my (semi)dead feeds have agg2 "freeze" setting on, while I do not want to lose the regular update interval setting.
Comments
Comment #1
dkruglyak commentedA little clarification to the problem this patch is trying to solve. Freezing feeds is nice but not enough. It would be really helpful to detect when feeds become inaccessible to be frozen automatically.
Cathing bad feeds is important to avoid constant refreshing them that always hogs cron till timeout.
Bad feed detection could be implemented by keeping a counter of failed refreshes in a row (in simplefeed_feed table) and use a global setting to automatically freeze feeds that hit a threshold (e.g. 10 failed refreshes in a row).
Comment #2
m3avrck commentedThis sounds like a worthwhile feature.
I would support a new "flag" field in the feed table called "status" that would be 1 or 0. Users could then turn off feeds if they need to (set status = 0), or as you said, keep track of "failures" (need field as well). If it hits X configurable failures, set status = 0.
If that happens then, how should a feed get turned back to 1? Automatic? Or have an admin area highlighting failed feeds for individual look over?
This would improve performance of the module and help users catch bad feeds in their system more easy, still keeping things simple :)
I would commit a patch but don't have time to write my own at this time...
Comment #3
m3avrck commentedThis is now fixed in 5.x and 6.x