Is it fair to say that aggregator is retained in d7 core for legacy support, and that Feeds is the likely successor? Feeds covers more scenarios than aggregator, and appears to be better situated for adaptions, although the generalization makes it more difficult to understand how to go about implementing. Are there projects that you can recommend that build on themes to implement particular use cases?

--- Looking through the Feeds documentation, we find the statement

"Feed: aggregation importer. Aggregates RSS/Atom feeds to nodes. Provides a node type Feed and a node type Feed item. Create one or more "Feed" nodes to add RSS/Atom feeds to your site. On cron, these feeds will continuously produce "Feed item" nodes. Requires the Aggregator core module to be enabled.

So project/feeds depends on core aggregator, although it seems to overlap and extend functionality as well.

3 Answers 3


Even though the module's name is 'Feeds' , it can import CSV, XML and other types of data too. Also, you can attach them to a stand alone form or a node type form.

The basic difference between aggregator and Feeds module is, how it stores data.

Aggregator module stores categories, feed URLs and imported data in its own tables. You will have Views support but it cannot be extended like nodes or such entity.

Also, you will not be able to map data. It's almost a fixed structure, like title to title, body to body, etc.

But in case of Feeds, you can decide what you need. You can build a standard feed importer that maps feed item's title to node title and contents to a body field. But you can also be radical by mapping to other fields.

You also can use different entities as the target. It also has 'pubsubhubbub' support which Aggregator doesn't support.

Both modules uses cron to fetch data.

Use aggregator if you want to show contents from few RSS/atom feeds in a simple block. For all other cases, I'd recommend Feeds module.


I would suggest "Feed import" module. I have a great experience at creating node with images and files attached to their fields. Hope it helps.

  • Feed Import only has a few hundred installs and no documentation on the project page. The Feeds module has over 30k installs and a fair amount of documentation; in addition, it is used by some of the largest organizations using Drupal and thus extremely likely to receive updates and fixes for years to come. While there are probably cases where the Feed Import module is useful, I highly doubt that it allows for "more complex actions" than what one can do with the Feeds module. Apr 30, 2012 at 23:31
  • I know there are big distance between docs, instals, and evens bugs. But Feed import let's you create nodes from, for example, any urls and let you download files and store them in any directory you specify. I'm not an expert, but i think Feeds it's just for the most common use cases, while Feed import it's more specific when importing complex data. May 1, 2012 at 0:16
  • The Feeds module can handle extremely complex use cases, as the first page of the documentation suggests (drupal.org/node/622696). Feeds is definitely not just for the most common use cases; it gives developers the power to set up extremely specific workflows for site(s) as necessary. If anything, it offers too much control. May 1, 2012 at 0:23
  • 1
    For the record, project/feeds contains a module called feeds_import, which is a features example illustrating Feeds' import capabilities; on the other hand, project/feed_import installs a single module, feed_import, which looks to be a proposed alternative to feeds.
    – August1914
    May 1, 2012 at 15:08

For Drupal 8, Aggregator is stable as of April 2016 (part of core) and works with views out of the box.

Aggregator is bare-bones next to the Feeds module but useful nonetheless. Especially since the Feeds modules appears to be ways off from a D8 port.

Not the answer you're looking for? Browse other questions tagged or ask your own question.