feeds_source return empty values when using views

Does appending the base_url actually make sense to do here?

The last major change to this file happened to be on Feeds 6.x-1.0-alpha1 (!), back in October 2009. I wonder why the source is get from the config array and not from the "source" database column. I think this was probably logical to do for Drupal 6 as I think the file fetcher url didn't start with "public://" or "private://" back then?

And no, it doesn't look like appending the base url makes any sense here, since the source for the file fetcher is usually something like this:

public://feeds/content.csv

So that would result into

http://www.example.com/public://feeds/content.csv

This needs work. The source should probably be taken from the source column. I think the handler should check if the source value looks like an url. If so, it should format it as such or else just return the value as is (but still sanitize it, of course).

I just ran into this issue. The fix is actually fairly simple, since the importer requires that files be in either the public:// or private:// wrapper. We just need to run it through file_create_url() .

+++ b/views/feeds_views_handler_field_source.inc
@@ -16,8 +16,8 @@ class feeds_views_handler_field_source extends views_handler_field {
     elseif (isset($value['FeedsFileFetcher']['feeds_source'])) {
...
+      $source = check_plain($value['FeedsFileFetcher']['source']);

Are you sure that the code needs to check for 'feeds_source' here? Can this feature be backed up with an automated test?

Ah, whoops. feeds_source doesn't exist. It should be checking for source instead. Updated patch attached.

I've tested the patch in #9 and I found out that check_plain() isn't needed. file_create_url() already sanitizes the data. Tested with the following sources:

• public://feeds/content.csv becomes http://www.example.com/sites/default/files/feeds/content.csv
• public://feeds/content>.csv becomes http://www.example.com/sites/default/files/feeds/content%3E.csv
• public://feeds/content<script>alert("hello")</script>.csv becomes http://www.example.com/sites/default/files/feeds/content%3Cscript%3Ealert%28%22hello%22%29%3C/script%3E.csv

Ideally though, it would take the source value from the source column instead of from config. Now it only works for two specific fetchers. But I guess this is second best.

The patch in #10 works for me.

Thanks for testing, @jesss. I have committed the patch from #10.

I'll leave this issue open for these two reasons:

1. The source value should come from the 'source' column instead of from the config column.
2. This feature should be backed up with an automated test.

Drupal 7 reached end of life and the D7 version of Feeds is no longer being developed. To keep the issue queue focused on supported versions, we’re closing older D7 issues.

If you still have questions about using Feeds on Drupal 7, feel free to ask. While we won’t fix D7 bugs anymore, we’re happy to offer guidance to help you move forward. You can do so by opening (or reopening) a D7 issue, or by reaching out in the #feeds channel on Drupal Slack.

If this issue is still relevant for Drupal 10+, please open a follow-up issue or merge request with proposed changes. Contributions are always welcome!