1) Install feedapi: activate feedapi, feedapi_item, feedapi_parser_simplepie
2) Create feed
3) Activate feedapi_inherit
4) Go to content type configuration of feed I created before and add feedapi_inherit as processor
5) Configure taxonomy
6) Test feedapi_inherit by downloading some new items
7) feedapi_inherit doesn't seem to work.

The reason is that content type presets are being copied to node settings on node creation. Once there are nodes out there, we don't have a mean to propagate new presets to existing nodes.

Worse, there is no means of "turning on" a processor for an existing node, as users can't decide on wether to use a processor on a feed node or not, they can only configure it.

Solution: Don't copy enabled/disabled settings from content type to node, keep them only by content type.

Comments

alex_b’s picture

alex_b commented

This bug does not only affect parser/processor on/off settings, but also parser/processor weights.

Ian Ward’s picture

Ian Ward commented

I think I came across this issue and noticed if I go back and save the node, it remembers the settings that second time. Is this related?

alex_b’s picture

alex_b commented
Assigned: Unassigned » alex_b

Aron just reported that disabled processors are visible on node form. This is most likely related. I will look at this issue asap.

djsdjs’s picture

djsdjs commented

I originally posted the above work flow and am having trouble understanding the explanation and whether a change to the code is planned.

"The reason is that content type presets are being copied to node settings on node creation.." - I have been confused on this because we are talking about the "creation time inheritance" of settings for a feature that is itself meant to create inheritance in feed item nodes.

I think this is what is being said is this:

I need to delete nodes based on the "feed definition" content type in order for changes to the presets of the "feed definition" content type to be propagated to instances of a "feed definition" node.

In this case, that happens to be the appropriate presets to have the "feed item" nodes inherit the taxonomy of the "feed definition" node ?

Is this the case?

If so, I have an observation that it makes mistakes in these presets very costly if a lot of feeds are already setup.

alex_b’s picture

alex_b commented
Priority: Critical » Normal

I just committed a patch that mitigates the problem: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/feedapi/fee...

After changing a feed configuration (parser or processor on/off, change weight) and opening and submitting a previously created feed node, the feed node takes over new configuration setting (e. g. a new processor turned on).

This is only a partial fix. Ideally at least the configuration of a feed node type is a site-wide per content type setting.

djsdjs: mistakes in the presets can always be reversed as they DO NOT propagate to existing nodes.

In an ideal world

* changes to configuration (on/off, weight) have a direct effect on all nodes out there,
* changes to presets (e. g. "Content-type of the items" for feedapi_item) have only an effect on new nodes
* all nodes of a type can be reset to the content-type preset on the content type form :)

alex_b’s picture

alex_b commented
Status: Active » Fixed

This issue is fixed now: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/feedapi/fee...

I still need to add a clear label on content type settings on what is content type setting and what is default setting for nodes.

alex_b’s picture

alex_b commented

If you look at the previously posted commit, I might need to add that this fix didn't need 201 lines, but is rather a result of some more basic refactoring it triggered.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.