I use the filters to limit what users put on the site...
The exact rules should apply on the aggregator...
Therfore I changed the code so it uses check_markup() to clean all data when you outputting function does a return $output;

You could make it even more flexible by letting us choose in the admin what filter type to use, so we can even make a seperate Filter type for aggretgated content...

Also please include xml filtering for "picture" based feeds like image galleries...
What I did now is something like this

 case 'PHOTO:THUMBNAIL':
      $element = 'THUMB';
      $items[$item]['DESCRIPTION'] .= '<img src="'.trim($items[$item][$tag]).'" border="0">';
      break;
CommentFileSizeAuthor
#4 aggregator.module.by_.ednique.txt57.45 KBednique

Comments

killes@www.drop.org’s picture

killes@www.drop.org commented
Version: 4.7.3 » x.y.z

new features go into devel version.

coreb’s picture

coreb commented
Version: x.y.z » 6.x-dev

(Moving x.y.z version to a real version number) Feature Request => 6.x-dev

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Aggregator in Drupal 5 already has a filter. It's aggregator_filter_xss() and it is configurable at admin/content/aggregator/settings.

The image parsing issue aside, why is the above not a sufficient solution?

ednique’s picture

ednique commented
StatusFileSize
new aggregator.module.by_.ednique.txt57.45 KB

first, I still use 4.7.6...

I have an input format (Filtered HTML) that is applied to nodes that users submit.
If I automatically grab content from a feed I think it's very logic to apply the same rules.
In essence you receive only teasers, but those teasers can contain HTML markup, images, links etc...
Instead of setting up the allowed tags again in the aggregator admin, I use the same input format as the one for the nodes.
By doing so, more then filtering HTML can happen as other filters like "outgoing link filter", "spamspan", etc. can be applied as well.

The aggregator_filter_xss I have changed as follows:

return check_markup($value,FILTER_FORMAT_DEFAULT);

I even go further and instead of using aggregator_filter_xss on only the item description:

if ($item->description) {
    $output .= '<div class="feed-item-body">'. aggregator_filter_xss($item->description) ."</div>\n";
  }

I use the aggregator_filter_xss on the whole returned output, so that the html that the aggregator produces also gets filtered:

if ($item->description) {
    $output .= '<div class="feed-item-body">'. $item->description ."</div>\n";
  }
  return aggregator_filter_xss($output);

In attach you'll find the whole file of my version and what is changed is still in the file but commented out.

Ideally I must say that in the aggregator admin setup page you would get a list of input formats that are defined with the site at /admin/filters
This could allow you even to define a seperate input type for aggregated content.
Because after all the aggregator is doing a type of input filtering.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Your use of 4.7.6 is not relevant to this issue. aggregator_filter_xss() is in 4.7.x, so this is not a security issue. It is a feature request (and I see the value).

Ideally I must say that in the aggregator admin setup page you would get a list of input formats that are defined with the site at /admin/filters. This could allow you even to define a seperate input type for aggregated content.

So the proposed change would be twofold, I think.

1) On activation of Aggregator.module, add an "RSS filter" to the list of active Filters. (This filter would replication the current aggregator_filter_xss() function settings.

2) At the Aggregator settings page, list all the active filters as radio buttons, and select the 'RSS filter' by default.

This seems simple enough. We would either have to refactor a fair amount of code to replace aggregator_filter_xss(), or rewrite that function to use the filter defined by the administrators selected filter.

Pro and con debate to merging the Aggregator filter with all other Drupal filters?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

CON: The reason for the current separation is that items from the Filter module are meant to be viewed under 'Input Format' options during node editing.

The aggregator_filter_xss() is meant to be invisible to the end-user, and "filter RSS" should not appear in the 'Input Format' options.

ednique’s picture

ednique commented

I see your point, but I want the end-user filter to be applied to the aggregator.

Actually I see that the sites delivering the aggregated content are end-users themselves (they supply content) even they are not physical persons but rather systems (websites).

A step further:
I have 3 filters by default (filtered, php and full HTML) only "filtered" is visible to the members of the site, php and full is available for members with a special role... as such a fourth filter could be appointed to the aggregator and kept hidden from normal members and special role members.

PRO: Keeping the filtering in one location avoids duplication of filtering code and eases up the maintenance of the code.
PRO: Using the content filters gives you more options apposed to only HTML filtering that is done now. (extra features like spanspam, OLF, url filter...)

boris mann’s picture

boris mann commented

I'm in favour of using the input format subsystem for filtering, and also would like to see per-feed filtering (which technically is a separate feature).

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Version: 6.x-dev » 8.x-dev

Moving. Though this might just die.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Issue summary: View changes
Status: Active » Closed (works as designed)