Experimental project

This is a sandbox project, which contains experimental code for developer use only.

This module is for Drupal 7.x.


The Advanced Aggregator module is designed to make Drupal's core Aggregator module (in version 7 and beyond) more useful, flexible, and scalable. In short, it makes Aggregator feeds "fieldable," adds additional Views integration for Aggregator feeds and items, checks and logs errors (bad HTTP status codes and parse errors) encountered when importing, adds helpful UI components to promote scalability, and provides an "upgrade path" for users who formerly depended on the Feeds module.

Usage Instructions

Just enable the module as you would normally and visit admin/config/services/aggregator. This module takes over that page and adds additional links and UI elements. If you have Views enabled, you'll also be able to access the feed URL log at admin/reports/aggregator_feed_log (although you can change this path via the Views UI).


In Drupal 6.x, the core Aggregator module was not very flexible. Many users turned to the Feeds module, which was able to treat both RSS feeds and their imported items as nodes, for flexibility. The Feeds module introduced the concept of pluggable fetchers, parsers, and processors, introduced flexibility, and allowed CCK fields to be attached to Feed nodes and imported items. The many options provided flexibility, but created confusion for some users.

Changes made to the Aggregator module and Drupal core in version 7.x have made some Feeds module features unnecessary for many users. The concept of "fieldable entities" allows Aggregator feeds themselves to have attached fields, and keeping imported feed items out of the node table will lead to a performance gain for users with many feeds. Additionally, the simpler UI and smaller set of options makes Aggregator easier to configure for many users.

Aggregator lacks flexibility and scalability in a few key areas, though, so this project seeks to add on to the Aggregator module to make it more suitable for a wider variety of users.

Detailed list of features

  1. Exposes core Aggregator feeds as fieldable entities. Users can now add fields to Aggregator feeds via a tab at the admin/config/services/aggregator page.
  2. Adds a Views relationship that allows users to access properties of parent Aggregator feeds for views built on child Aggregator items. This means that each imported feed item can now access fields added to its parent feed.
  3. For users with lots of feeds, makes the Aggregator feed administration page (admin/config/services/ aggregator) scalable by adding pagination and only showing 50 feeds at a time. Additionally, checkboxes are provided that will allow users to delete multiple feeds at a time, and a search box is provided to search through feeds by title.
  4. A table is provided that will store broken and/or redirected Feed URLs. Users can choose to run a mass check of feed URLs on the site, using Batch API, which will ping the URL of each stored feed and store any problems in the log table. Users can view a report based on this table via a view provided by this module, and a form is also provided through which users can bulk-update redirected URLs.
  5. A utility is provided for users who (like myself) had formerly relied on the Feeds module and had lots of Feed nodes. The utility converts the feed nodes to core Aggregator feeds and attempts to preserve any Field API data associated (if you're upgrading from Drupal 6, be sure to upgrade all CCK data to Field API first). Once you've done this, you can safely uninstall Feeds and drop its tables.
  6. An alternative fetcher and parser are provided via the Aggregator module's hooks. The parser is designed to avoid a problem that can arise with importing feeds: title and author fields can contain too much data and result in database errors when insertion is attempted. The parser provided by this module (Advanced parser) lets the default parser act, then truncates the title and author fields, on word boundaries, to the maximum allowable size in the database.

    The fetcher is designed to log errors to the provided error log. The default fetcher simply calls drupal_set_message(), which is not useful for sites with lots of feeds importing on cron runs. This fetcher (Advanced fetcher) logs all bad (non-200-level) HTTP status codes to the error log, along with redirected URLs (if a 300-level status code is encountered).

    Additionally, the parser sometimes encounters errors when trying to parse a document as RSS XML. If the parser encounters an error, it also stores the error in the log, where administrators can view it later.

Project information