* A feed->error doesn't necessarily mean that it was unreachable - could have been unparseable too.
* Either way, the node should STILL be saved, and a drupal_set_message should explain as much. There's nothing worse than knowing that your URL is correct, but being flummoxed by a currently-bad feed or a temporarily-down website. Assume the silly human knows what he wants, and just inform him of transient errors, not shut him down.
* "should be in the format of" message string needs to use %properly - don't hardcode the EM yourself.
* I'd really like to see the SimplePIE loading made stronger - I need to add my own tweaks to the load (on a per feed setting).
Comments
Comment #1
csevb10 commented- The feed error one is one I've been meaning to change for awhile. It currently captures too many errors with a misleading error message.
- I can see the logic in this as well. Technically, I think we should probably slide that particular bit of handling into simplefeed_item which would be a more logic resting place for the simplepie invocation/validation since this constrains you to 1 particular parsing engine, really.
- %placeholder -- fixed
- I'm not opposed to SimplePIE additions in general (exposing the power of SimplePIE via the interface would be nice). If you want to submit some additions to the handling for simplefeed_item so that it is able to use more of the SimplePIE functionality, we can look at incorporating those things back in.
Comment #2
m3avrck commentedYes the error handling should be moved to simplefeed_item in this case.
However, I'm against removing it as it prevents lots of problems, however, the error message could be cleaned up to be more specific.
If you want to get rid of it entirely use hook_form_alter()
Comment #3
m3avrck commentedSince the hook_validate() in simplefeed.module relies on SimplePie this *should* be moved to simplefeed_item module so if that engine is not used it doesn't prevent problems.
Comment #4
csevb10 commentedThe simplepie elements have been moved into simplefeed item, so that portion of things should now be resolved, and I agree with making the error handling more specific so I'll see if I can clean that up in the near future.
Comment #5
m3avrck commented