This list is an outline of what needs to happen for a feedapi release version 1.0 . It is not final and open for discussion. We should agree on the main issues before we move on them though.

Aron and I wrote up most of these items at the DrupalCon in Barcelona. I ordered and edited them. Please give your feedback/additions/objections.

STRUCTURE

There is going to be
* feedapi.module - the core module
* a standard installation that's living as a project on drupal.org that contains
** one parser
** feedapi.module core module
** feedapi_ui.module - the core feedapi UI with feedmanagement page, settings page and views integration
** feedapi_node.module - a processor module that creates nodes from feeds.
* add-on modules living on their own project pages
** feedapi_inherit (is it a good idea to throw og inheritance and taxonomy inheritance into one module?)
** feedapi_feather (this name is a suggestion for the existing feedapi_aggregator module)

Turning on feedapi is going to be easy - you download feedapi and the simplepie parser and simply turn on all the feedapi modules from the standard download on the modules page. A feed content type will appear and you can already start to create feeds. For any other fancy feature there will be add on modules. The feedapi project page will point to those add on modules. Making feedapi as tight as possible should also address the fears that feedapi is getting too big.

Simple feed module should be a good example to follow here: nodes as items is a common use case as Ted pointed out and the simplicity of the module helps the user feel comfortable with it.

IMPROVEMENTS

*Usability*

* Feed management page
** Consistent values at all stages - now there are strange numbers in circumstances like a feed hasn't been downloaded yet.

* Revise settings and structure of settings page
** Drop "simplified node form" setting

* Help - update basic help sections

* UI language
** Improve english: proof read settings pages, menu and labels.
** Find better terminology on some points.
** Rename "Feed" to "Feeds", following the terminology "Categories"

* Offer a simple node creation block instead of hijacking the node form with the "simplified node form" setting
** One block per feedapi-enabled content type
** Has a textfield for a URL and an "Add" button

* Preconfigured views (feedapi_views.module)
** (We had some discussion here. I thought about it: I think we should go views, basic views support will go into core at some point. It doesn't make any sense to have some intermediary solution until then - let's just require views for feedapi).

*API and internal works*

* Terminology
** Revisit module names. feedapi_aggregator, feedapi_inherit, feedapi_item need a better name.
** I would even love to call feedapi "feeds" - shorter, addresses the fact that the module is more than an API and follows the names of "views", "actions", "panels"... the downside is : confusing community, loosing built up buzz; what does it mean on the technical level?
** Make meaning and function of "primary parser" "secondary parser" "parsers" "processors" crystal clear
** We need a good name for the "processing line" of feedapi - the process of downloading, parsing, processing a feed

* Module structure
** Break out feedapi ui in feedapi_ui.module
** Only core functionality plus API implementation in feedapi.module
** FeedAPI project only comprises the basic configuration

* Review API
** Look for room for improvement: make live easy-easier-easiest for add-on developers
** See how and wether we can decrease number of hooks
** Hook into actions module - can we remove some hooks by building on actions module? what does this mean for 5? what for 6?
** Currently we store settings of modules in a serialized array - isn't this bad?
** Review invoke() function

* Tests
** write tests for some of the most critical cases
*** testing presets/settings
*** testing cron downloading

* Code review
** Get more people review code once we are done with a good restructuring.

Comments

aron novak’s picture

I mostly agree (not surpisingly :) )
Just one quick note:
The simplified feed creation form is NOT a hijacked node form. It has the own form handling functions, it's totally independent. Maybe FeedAPI should contain the simplified form and a block for the feed creation.

aron novak’s picture

Assigned: Unassigned » aron novak

* Offer a simple node creation block instead of hijacking the node form with the "simplified node form" setting
** One block per feedapi-enabled content type
** Has a textfield for a URL and an "Add" button

This is done.
Actually I haven't changed the Submit / Submit and Edit way, it provides bigger freedom of the user. Maybe the block should provide a setting about this behavior.

alex_b’s picture

There is some opposition on going views here. Ted said that it was important for his performance critical application to be able to run without views turned on. Fair enough. Why don't we roll out with some basic non-views pages and provide a feedapi_views module for more complex issues? The feedapi_views module could wait until after the first beta roll out.

ahneill’s picture

Title: Release outline for feedapi » tag importing?

Hi I just wanted to say a nice feature of leech was the idea that you could use leech_feed_taxonomy to import tags from a feed. Though I had difficulty making it work with del.icio.us feeds, I think some kind of importing of tags would be among important add-on modules.
not sure if that discussion about leech and del.icio.us, flickr, etc helps, but here it is... http://drupal.org/node/171938

alex_b’s picture

Title: tag importing? » Release outline for feedapi

Please don't rename issue - I guess this was an accident.

Importing tags of feeds is a very important issue indeed. In feedapi this can be implemented by creating a custom module with a secondary parser component that pulls the tags from the feed and a processor component that sticks it e. g. on the node that is being created from the feed item.

The name of this module could be feedapi_taxonomy.

Somebody wants to step up?

ahneill’s picture

Unfortunately I'm not a coder but this is definitely a key add-on module to feedapi... I can't do the coding... HOWEVER, I CAN commit $100 to its' development. If I get a firm commitment from a developer, I can very likely double that commitment. If it will cost a little more just message me... my work can probably sponsor the module.

Anyone else who wants to import tags from rss feeds interested in offering some resources (money or coding skills?)

thanks

art

cacciaresi’s picture

Hello, in my site (http://www.sharingblogs.com) I've done something similar.

I've created a custom content type called Feed Item, and when feeds items are retrieved from a feed a Feed Item node is created.

When the Feed Item node is created, the tags are extracted and assigned to a fixed vocabulary.

One of the methods that i've changed was this:

/**
 * Create a node from the feed item
 * Store the relationship between the node and the feed item
 * Implementation of hook_feedapi_item_save().
 * @todo User shouldn't be the user of the time when item is saved. 
 * User should be the owner of the feed.
 */
function feedapi_item_feedapi_item_save($feed_item, $feed_nid, $settings = array()) {  
  // Construct the node object
  $node = new stdClass();
  $node->type = !empty($settings['content_type']) ? $settings['content_type'] : variable_get('feedapi_item_type', 'feeditem');
  // Get the default options from the cont
  $options = variable_get('node_options_'. $node->type, FALSE);
  if (is_array($options)) {
    $node->status = in_array('status', $options) ? 1 : 0;
    $node->promote = in_array('promote', $options) ? 1 : 0;
    $node->sticky = in_array('sticky', $options) ? 1 : 0;
  }
  else {
    $node->status = 1;
  }
  $node->title = $feed_item->title;
  global $user;
  $node->uid = isset($settings['uid']) ? $settings['uid'] : $user->uid;
  $node->created = (isset($feed_item->options->timestamp)) ? $feed_item->options->timestamp : time();
  $node->body = $feed_item->description;
  $node->field_feed_nid['0'] = array('value' => $feed_nid);
      
  if (isset($feed_item->options->teaser)) {
    $node->teaser = $feed_item->options->teaser;
  }
   
    // If the feed item has tags, then we continue.
  if (isset($feed_item->options->tags)) {
    
    if (sizeof($feed_item->options->tags) > 0) {
      
      $feed_item_terms = $feed_item->options->tags;
      
      foreach ($feed_item_terms as $feed_item_term){
        // check if terms are not loaded in the site.
        $possibilities = taxonomy_get_term_by_name($feed_item_term);
         // If it was not loaded, then we add it.
         if (sizeof($possibilities) == 0) {
           $vid = 2;
           $new_term = array();
           $new_term['name'] = $feed_item_term;
           $new_term['vid'] = $vid;
           taxonomy_save_term($new_term);
           $node->taxonomy[] = $new_term['tid'];
           //taxonomy_node_save($node->nid, $node->taxonomy, false);
         } else {
           // if the term exists, then we relate this term with the feed item.
           $typed_term_tid = NULL; // tid match, if any.
           foreach ($possibilities as $possibility) {
              $typed_term_tid = $possibility->tid;
              $node->taxonomy[] = $typed_term_tid;
           }
         }
      }
    }
  }
  
  if (!isset($feed_item->nid)) {
    node_save($node);
    $feed_item->nid = $node->nid;
    db_query("INSERT INTO {feedapi_node_item} (feed_nid, nid, url, timestamp, arrived, guid) VALUES (%d, %d, '%s', %d, %d, '%s')", $feed_nid, $feed_item->nid, $feed_item->options->original_url, $feed_item->options->timestamp, time(), $feed_item->options->guid);
  }
  else {
    $node->nid = $feed_item->nid;
    node_save($node);
    db_query("UPDATE {feedapi_node_item} SET url = '%s', timestamp = %d, guid = '%s' WHERE fiid = %d", $feed_item->options->original_url, $feed_item->options->timestamp, $feed_item->options->guid, $feed_item->fiid);
  }
  return $feed_item;
}

Obviously that this is a extremely basic idea.

I hope it helps.
Claudio.

alex_b’s picture

The current version of the processor that creates nodes from feeditems: feedapi_node calls node_prepare($node) before saving the node. this triggers the nodeapi("prepare", $node) hooks. on the $node object you will find the original feed item like it comes from the parser. you can use a custom module to hook into "prepare" to populate the node item with the taxonomy you need.

You can alternatively check out the feed element mapper. a module which is built for aggregating all sorts of feed item elements in all kinds of node fields. it is still experimental, but works fine for mapping anything in a feed item to a taxonomy. it is available in my sandbox. http://drupal.org/node/165388#comment-590209

telex4’s picture

Hi, I'm just wondering if feedapi now includes any of this functionality to grab tags from RSS feeds, or if there is a recommended way to do it without significant hacking?