I must be missing something in the beta, since I don't see anyone else having this issue... I've been using dev versions on one site with some success - I've created a new site and installed beta1 of feedapi, and I'm not getting nodes.
I have enabled FeedAPI, FeedAPI Node, FeedAPI Inherit, FeedAPI Node Views, and Common syndication parser. I use the feedapi_node content type for my feed nodes, and a custom type "feeditem" for the items. The feedapi_node type is set up with parser_common_syndication, feedapi_inherit, and feedapi_node enabled. Promoted items is 0.
I've added two feeds, http://groups.drupal.org/node/2/feed and http://groups.drupal.org/node/485/feed. Both are set up to never delete news items, update already existing news items is off, content type of items is feeditem, date is retrieved from feed, promoted items is 0, author is mikeryan, taxonomy inheritence is enabled.
When I refresh the RSS & Aggregation feed, I get "30 new item(s) were saved. 0 existing item(s) were updated." (I've done it three times now on that feed). No nodes are created (I've checked the node table, there are 13 nodes in there, all otherwise accounted for).
So, where are those items going?
Thanks.
Comments
Comment #1
jimsmith commentedI have reported the same problem here. I still have not resolved it.
Comment #2
mikeryanOne big difference - I haven't had any errors (SQL or otherwise). FWIW, I am on MySQL 5.0.27, PHP 5.2.1.
Comment #3
alex_b commentedMike,
I just ran a test of beta1 on my PHP Version 5.2.2 test system with the configuration you specified above. Works fine, nodes are being created.
Can you describe the user roles involved? What are the author role's feedapi, feed node, feed item node permissions, what are the feed item author role's feeditem permissions?
@jns: issue #190228 and this one are most probably not related...
Alex
Comment #4
mikeryanI was using the original admin account (user id 1) - I just created a new role (no feedapi admin permissions, create/edit permission on the feedapi_node and feeditem types) and user in that role, same deal. Another point, which may or may not be relevant - I created the feed under the new user with delete older than 4 weeks and update existing items off, when I edit it the delete setting is Never and update is checked on (I did notice the update behavior under the admin account). When I edit the settings they do take.
Comment #5
toddc commentedI had a similar problem. Disabling the setting for feed nodes to inherit organic group settings from the parent feed, solved this problem for me.
Comment #6
mikeryanI don't have og on the site where I'm having the problem, and disabling taxonomy inheritance doesn't help...
Hmmm, interesting... Given that hint, I disabled the feedapi_inherit module, and tried refreshing the Drupal Boston feed. I got "No processors specified for URL http://groups.drupal.org/node/2/feed. Could not refresh." Editing the feed node, the FeedAPI Node section is present with feeditem selected as the content-type. In the feedapi table, the processors field is a:1:{i:0;s:15:"feedapi_inherit";}.
OK, so back to square one... I deleted my feed nodes, disabled all the feedapi modules, deleted the feedapi_node content type, and dropped the feedapi tables. And, I dropped all vestiges of the feedapi files from the system table (otherwise, it won't recreate its tables when re-enabling). Then, I went back and re-enabled the modules (one-by-one) in the order:
FeedAPI
Common syndication parser
FeedAPI Node
FeedAPI Inherit
FeedAPI Node Views
And, this time, I paid attention to the FeedAPI Inherit readme and set its weight to 15... Bingo! It works...
OK, so ultimately it was the fact that I was missing setting the weights appropriately. I think the module could help out, though, by:
1. Defaulting the feedapi_inherit weight to a higher number.
2. Warning when, as a result of a new processor being enabled or a feed content type being updated, more than one processor has the same weight.
So, changing this to a feature request.
Thanks.
Comment #7
alex_b commentedHi mike,
Thanks for the digging. I assume that what caused this bug was that you created the boston feed and then reconfigured the feed's node type.
I am surprised that feedapi didn't fall back to the activated processors from the node type settings. I thought revision 1.23.2.67 (pre beta 1) had addressed this. But let's look at where feedapi refreshes the feed, in particular at line ~347 in feedapi.module:
I think that's where the problem sits: $feed->settings['processors'][$processor] doesn't exist if it couldn't be loaded from the feedapi table's settings field. It doesn't fall back to the per node type settings (in variable table).
Settings are a moving target at the moment. Currently, (1.x version) feedapi copies settings from node type to a node if a user with 'advanced feedapi options' permissions creates a feed (only such a user can change presets on a node).
This patch: http://drupal.org/node/182938 brought us very close to the desired behaviour: only copy settings from node type to node if they are different from node type. Advantage: if you never change the per node type presets on a node, you can always control the node's behaviour on a per content type basis!
On top of this, the bug you reported shows us that we need a save way for propagating on/off and weight changes to feed node types to feed nodes. This should be done on _feedapi_get_settings(). If settings for a node are retrieved, the node type settings should also be loaded, added and removed parsers and processors should be added/removed and weights should be changed accordingly.
Other related issues:
"Create way of defining a standard weight" http://drupal.org/node/184343
For the record:
Doing an uninstall of feedapi on admin/build/modules should have done the job.
Cheers,
Alex
Comment #8
alex_b commentedThis issue isn't resolved in 1.x
Comment #9
alex_b commentedWe didn't get to actionable items on this thread, some of these issues are 5 specific. Closing after 18 months inactivity.