FeedAPI developer's guide

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Introduction to developing add-on modules for FeedAPI.


Configuration and usage for site admins, etc.: http://drupal.org/node/326601


The FeedAPI provides a simple user interface for managing feeds and handles add-on modules.
There are two types of add on modules:

  • Parsers
  • Processors

Parsers transform feeds into normalized PHP arrays. Two examples for parsers are common-syndication parser and simplepie parser, both shipping with the FeedAPI project. Processors then decide how to store and present that data. An example for a processor is the node processor (ships with the FeedAPI project) that creates nodes from feed items.

Life of a feed in FeedAPI:


1) Incoming URL from the user
2) Auto-detect a compatible parser ( feedapi_feed('compatible') ), the user has ability to adjust this auto-detection: per content-type there are presets to do this - this value is the order of probing: if all of the parsers is compatible with the feed, the lightest parser will be assigned as the primary parser, the others will be secondary parsers. The parser (if compatible) have to tell what is the type of the feed.
3) Auto-detect a compatible processor. The weight-system is the same for parsers.
4) Store the feed as a node. The nodeapi here offers various ways to involve for external modules.
Via cron or via direct user command for 1 feed
FeedAPI handles refreshing, the modules only have to implement the standard hooks (see below)
Same for refreshing, standard hooks are used.

Writing a parser

Required hook: feedapi_feed. Examples: example1, example2
Required operations ($op) parameter within the hook:

  • 'type'
  • 'parse'
  • 'compatible'

The parser is: able to detect if the URL has such a data that can be parsed, able to parse the data into the standard data structure (see above). For the parser, you can leverage PHP's simpleXML functions to convert the xml file into a feed object.
Be prepared: the primary parser (lightest parser of the content-type) is responsible to fill all the basic information of the feeds and the items. The secondary parser is only for adding more properties to the $feed->options. [needs details on how to do this]

Writing a processor

Required hook: feedapi_item. Examples: example1, Example 2
At this example the operations are in private "_foo" functions because of the complexity of each operation. To see what to do in the operations, check out these functions.
Function signature:

function hook_feedapi_item($op, $feed, $param);

Required operations ($op) parameter within the hook:

  • 'type'
  • 'save'
  • 'update'
  • 'delete'
  • 'load'
  • 'unique'
  • 'fetch'
  • 'expire'
  • 'purge' - new hook operation added with FeedAPI 1.5

The item processor should handle basic feed item operations, store, show the items.


Your module can interact with the feed mechanism fully via the nodeapi.

Storing add on module specific presets and settings

FeedAPI provides a settings_form hook that expects a FormsAPI-style associative array that describes the add on modules settings. The storage of per content type presets and per feed settings is handled entirely by FeedAPI.

See how this is implemented in the feedapi_node module (function feedapi_node_feedapi_settings_form($type) ).

Other possibilities of extension

There are important milestones in the feed's life, where any of the external modules can involve:

  • feedapi_after_refresh - it is called after the feed is refreshed. Use case: promote the node items.
  • feedapi_after_parse - it is called immediately after the parsers. Use case: http://drupal.org/node/160692
  • feedapi_after_settings - it is called after the FeedAPI internal settings handler finished its job. Use case: feedapi_aggregator fill category_feed table

With the help of these hooks, your module is able to react to these operations.