I've tried a fresh install of the latest dev. version and beta2 with the same problem on both. I try to create a new feed entry and it doesn't accept the FEED URL. I fill it out, submit the node and when I go back to click edit and review it doesn't show the feed. Not surprisingly feedapi isn't pulling the feed either.

It could of course be me but I wonder if it's a bug because at the beginning of the week on an older dev version it was working for me.

Comments

ekes’s picture

I've found it will do this if it can't get the feed for any reason. Like any reason, ones I have experienced: DNS lookups on server failing, feed not responding quick enough, feed not actually being there at that moment (due to a db error their end).

To solve this I've gone to the parser where it gets the feed and just printed the error it returns to the screen.

Maybe that will help?

aron novak’s picture

Well, if it's really a bug, the bug report is very short.
I need to know: - what about the simpletest tests? Can you run it successfully? - which modules do you use (which parser esp.)?

toma’s picture

I have the same problem here! i give users the access to add feed, and its blank when i edit, i can only add feed with admin permission, i try to give full options to users, and the same issue, i have 5.x.1.1,using Common syndication parser

Thanks

MMachnik’s picture

I was getting this too, on 5.x, with FeedAPI 1.1 and Common Syndication Parser. I found that the problem seemed to be the result of a very large feed. For various reasons, I need to work with a feed that is almost 2 MB in size. Under FeedAPI 5.x-1.1, if I edit the feed and save it, I also get a blank feed url -- and also, the processors and parsers are set to "N". On a hunch, I decided to try a smaller version of the same feed, and that worked -- the url and other fields were set properly, and I was then able to refresh the feed and have it create new nodes, etc. I switched back to the large version of the feed and it broke again. So it seems to me to be related to feed size. Perhaps drupal_http_request() cannot handle feeds that are too big.

For what it is worth, when using Leech, I had to increase the curl timeout set by the module to get it to work with this large feed.

aron novak’s picture

Thanks for the detailed description. Can you paste here the feed URL?

MMachnik’s picture

Aron -- check your email, I sent the URL through your contact form.

toma’s picture

For me, with admin permission, i have no problem adding feed url, only users get this issue, you can see yourself in my website www. alltutorials . org you can login with drupal ident!

xerexes’s picture

How do I do that? I would love to see errors from the function of trying to gather the feeds.

I've been busy with other work lately - I appreciate others sharing their issues - I'll investigate whether any of it is my problem.

Aron I have been hesitant to run simpletest b/c the problem is on a live site. (Simpletest advises not to do this).

ckng’s picture

Same problem with FeedAPI 5.x-1.1
- feed url missing after submit/edit
- if not missing, it can't be refreshed giving 'There are no new items in the feed.' or 'Could not refresh feed.', under rare situation the following happened
- if not missing, only 1 new item get mapped if it got refreshed, simplepie cache has all entries, but only latest one is stored

On your playground, there are a lot of feeds seems to have 2nd and 3rd symptoms.

ckng’s picture

An additional note, simpletest failed during user account creation, so the rest of adding feed etc failed by default. FeedAPI test does not work under simpletest 5.x-1.x-dev.

aron novak’s picture

Assigned: Unassigned » aron novak
Status: Active » Fixed

I'm sure that this is fixed now (in the CVS and the next daily dev package). It was a really critical bug in parser_common_syndication caching. Please do the following before testing if it's fixed or not:
1) empty parser_common_syndication_cache directory. (under files directory)
2) Run DELETE from parser_common_syndication; SQL query.
3) Update to the 5.x-dev or to 6.x-dev
4) Try to refresh your feeds (more than once)

If the problem remains, please reopen the ticket with an exact feed url where you experience the problem. Maybe some redirected feed urls can be problematic.

@ckng:
'There are no new items in the feed.' - just to know: this is a normal informative message usually. If you really know that there is new item in the feed and feedapi replies this, please copy here the feed url (but only after you tried out the new version of feedapi and the above instructions)

@MMachnik: Yes, if the feed downloading takes too long, it may happen. Now parser_common_syndication uses drupal_http_request so i cannot see a workaround for you (no way of increasing timeout). Can you try out parser_simplepie instead?

About advanced feedapi permission problem: it should not really happen. There were modifications in this area too. Please try out the new version + the above instructions. If the problem remains, please add a new ticket like this: "Feed creation as normal user" and describe which permissions has the given user exactly .

toma’s picture

It work for me just fine, Thanks a lot

ckng’s picture

I'm using simplepie parser, but the latest dev seems to fix the problem, will do more testing and report back if problem still persist. Thanks!

MMachnik’s picture

Simplepie seems to work for me. I did have trouble changing the parser my feed was using. Even when I enabled simplepie and edited the feed node to use it, it would still use CSP. I cleared the cache, etc., no change. Perhaps because the parser is set on the type and not the node itself? It would be nice to be able to set different parsers for different feeds. I had to create a new feed node.

I did find what I think was the main source of my problem before switching. I had upgraded to the dev version of the module but was still having the issue described here. Eventually I came to _parser_common_syndication_download(), where at the end before the $downloaded_string is returned, any unusual tags are filtered out. I found that with this particular feed I need to access, the preg_replace() caused $downloaded_string to be emptied out. The ripple effect went all the way up the chain, to the point that it was interpreted as not valid XML, thus not a valid feed, etc. It turns out that the problem was the /u pattern modifier which according to the PHP manual pages (and also at least one PHP bug report I located), will cause preg_replace to return an empty string if there is bad UTF-8 code. I modified my copy of the module to check if it did get an empty string and if so, call it again without the /u modifier. That worked well. Here is the code:

  $downloaded_string_result = preg_replace(
    array(
      '@<script[^>]*?.*?</script>@siu',
      '@<object[^>]*?.*?</object>@siu',
      '@<embed[^>]*?.*?</embed>@siu',
      '@<applet[^>]*?.*?</applet>@siu',
      '@<noframes[^>]*?.*?</noframes>@siu',
      '@<noscript[^>]*?.*?</noscript>@siu',
      '@<noembed[^>]*?.*?</noembed>@siu'
    ),
    array('', '', '', '', '', '', ''),
    $downloaded_string
  );

  // If the string is empty, try again without the 'u' modifier. See PHP
  // manual: preg_replace() breaks with this modifier and bad utf-8, which
  // the feed may contain.
  if (empty($downloaded_string_result)) {
    $downloaded_string = preg_replace(
      array(
        '@<script[^>]*?.*?</script>@si',
        '@<object[^>]*?.*?</object>@si',
        '@<embed[^>]*?.*?</embed>@si',
        '@<applet[^>]*?.*?</applet>@si',
        '@<noframes[^>]*?.*?</noframes>@si',
        '@<noscript[^>]*?.*?</noscript>@si',
        '@<noembed[^>]*?.*?</noembed>@si'
      ),
      array('', '', '', '', '', '', ''),
      $downloaded_string
    );
  } else {
    $downloaded_string = $downloaded_string_result;
  }

  return $downloaded_string;

I ended up switching to simplepie anyway as mentioned and it seemed to resolve some other minor issues I had. But perhaps this will help someone who was having the same problem as me, and maybe it would also make sense to go into the code base to handle the unexpected issue of bad UTF-8 code in a feed you are accessing.

Thanks again for all your great work and I hope this is helpful...

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.