Notice: Trying to get property of non-object in FeedsNodeProcessor->getMappingTargets() (line 221 of /var/www/drupaltest/sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc).
Notice: Undefined index: node in field_info_instances() (line 685 of /var/www/drupaltest/modules/field/field.info.inc).
Warning: Invalid argument supplied for foreach() in field_feeds_processor_targets_alter() (line 32 of /var/www/drupaltest/sites/all/modules/feeds/mappers/field.inc).
Notice: Undefined index: node in field_info_instances() (line 685 of /var/www/drupaltest/modules/field/field.info.inc).
Warning: Invalid argument supplied for foreach() in file_feeds_processor_targets_alter() (line 20 of /var/www/drupaltest/sites/all/modules/feeds/mappers/file.inc).
This is because $bundle_name isn't checked to be not NULL. Maybe, if I have some time, I'll create a patch.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 1166100-12-notices_on_mapping_page.patch | 1.45 KB | twistor |
| #3 | 1166100-3-notices_on_mapping_page.patch | 1.4 KB | twistor |
| #2 | 1166100-2-notices_on_mapping_page.patch | 1.39 KB | twistor |
| #1 | 1166100-1-notices_on_mapping_page.patch | 796 bytes | twistor |
Comments
Comment #1
twistor commentedHere's a patch. The reason for returning $targets here is that new warnings are thrown if $targets is an empty array or NULL.
The warning message can probably use some work. I'm terrible at them.
Comment #2
twistor commentedThat didn't quite do it. This patch shows the message as soon as the Node Processor is selected. It shows a different message if a content type exists, but there isn't one in the config.
Comment #3
twistor commentedAlways forget my t()'s in my l()'s.
Comment #4
Niklas Fiekas commentedThank you. The patch looks good.
One point is that there are more entity types. We'll always have a problem with entity types that have no bundles. (However since Feeds doesn't support generic entities yet, there is only taxonomy.)
I am not sure if this (as of the current state) can be solved for all entity types at once, or if it must be a solution per entity type.
Edit:
Also a generic problem might not be that user friendly. At least I don't know a way to get the last two columns in a generic way:
Comment #5
twistor commentedFeedsTermProcessor doesn't have the same issue with warnings. It will happily set everything up without a vocabulary existing. The reason is the difference between the configDefaults() implementations. FeedsNodeProcessor attempts to auto-select a content_type (and assumes it's successful) whereas FeedsTermProcessor doesn't have a default value. On import it will spit out "No vocabulary defined for Taxonomy Term processor." For each feed item and fail to import anything. It might be more user friendly to warn them before they get to importing. I don't see a generic solution without api changes that would affect contrib.
One route that I kind of like would be to change FeedsNodeProcessor::configDefaults()'s implementation to be more in line with FeedsTermProcessor's.
Comment #6
Niklas Fiekas commentedOh, thank you for the explanation, I just assumed (without checking) it would have the same problems.
I am moving the status to RTBTC because the patch looks clean, applies and solves the problem for me.
Comment #7
febbraro commentedIs this only a problem if your site has no content types defined? Otherwise there is always a content type elected on the NodeProcessor settings for me.
Can you include detailed steps to reproduce?
Comment #8
Niklas Fiekas commentedExactly. So only in rare cases.
Comment #9
twistor commented@febbraro
Steps to reproduce:
Comment #10
elliotttf commentedThis also happens during simpletests, and I can confirm the patch in #3 resolves the issue.
Comment #11
dave reidThis needs to be re-rolled to properly use links in t():
Bad:
t('There must be at least one !content_type defined to use the Node Processor.', array('!content_type' => l(t('content type'), 'admin/structure/types/add')));Good:
t('There must be at least one <a href="@content-type-add">content type</a> defined to use the Node Processor.', array('@content-type-add' => url('admin/structure/types/add')));Comment #12
twistor commentedWhat Dave says I do.
I'm never really sure how to handle links in t()'s correctly. Thanks.
I changed the first message to be a warning. I'm not sure why it wasn't before. I also turned repeat off since it can show multiple times per page.
Comment #13
twistor commentedFixed this in 7.x.
We can do this generically in 7.x now that we have generic bundle handling.
Comment #14
davemaxg commentedWe've been using Feeds 7.x-2.0-alpha7 extensively for almost a year on many node imports to a variety of content types without any issues related to a missing content type/bundle. However, after upgrading to alpha8, we've had multiple instances of the bundle getting cleared out. I haven't see anyone else post about this issue, but in looking at the release notes, I ended up on this thread because it seems highly likely that it's related to this fix.
This is the error message that we are seeing:
User xxxxxxx is not authorized to create content type.
I am not sure when/how the bundle gets cleared out as I do not run the imports, though they are run manually and usually involve large files. The importer is set to process on submission and in the background. In one case, I know the bundle got cleared during one of these imports but this may not be the actual or only way that it gets cleared. I do believe that it is a bug in the code, however, because it's not possible to clear out the bundle and save the importer using the admin UI since it's a required field.
Comment #15
megachriz@davemaxg
There is now a change record about this: https://www.drupal.org/node/2426449
Back to 6.x-1.x.
Comment #16
twistor commented