Closed (outdated)
Project:
Feeds
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
24 Jan 2018 at 06:58 UTC
Updated:
26 Nov 2025 at 14:32 UTC
Jump to comment: Most recent
Comments
Comment #2
megachrizThis sounds like a good idea. I have however one concern: an importer can be exported to code. When an importer exists in both code as in the database a 'deletion' will actually revert the importer. In this case I think the delete importer hook should not be invoked (but maybe a revert hook instead). There is another thing: when a module providing the importer in code gets disabled, the importer disappears as well. So maybe the delete hook should run as well when that module gets uninstalled? I think disabling a module should not result into data loss.
How does the View module does this? Views also has the concept of adding their config into code.
Comment #3
megachrizComment #4
rooby commentedGood point, I hadn't really considered exportables or thought of the views module.
The views object delete method calls hook_views_view_delete() at the end.
It doesn't appear to differentiate between a delete and a revert, so the condition would have to be that all extra data be stored on the object such that reverting to code wouldn't lose that additional configuration.
Besides, if you were providing a default configuration it would be good to be able to also specify additional third party configuration in that code also, like different views plugins do.
I also considered the crop approach, as per the linked issue about feeds_source.
That might be the only solution for extras that couldn't possibly go in the importer configuration itself. Well that and just leaving the extras in the database until the module in uninstalled.
Comment #5
bluegeek9 commentedUnfortunately, Drupal 7 is End of Life and no longer supported. We strongly encourage you to upgrade to a supported version of Drupal.