FR: Make it possible to shield entries from being deleted/disabled

[kristiansp]

Description

When running feeds repeatedly as a way to sync with an external source, as opposed to a one-off import, it can be useful to have more control over how Feed Me handles existing entries that are not in the feed being imported.

Specifically, it would be useful to "shield" certain entries from being disabled or deleted, even though they are not in the feed. In my case, my feed is only containing new items (upcoming events), and I would like to keep existing events around for the current week, but delete older events.

The easiest way to get at this, it seems to me, is to give access to $processedElementIds in one of the FeedProcessEvents. Since Feed Me is doing a simple array_diff on existing elements and the ones that are processed, adding element ids to the array of processed elements would effectively shield them from being disabled/deleted.

I don't know if it's the most logical place to do it, but the way that requires the least changes to the code would be to do it in the afterProcessFeed event by simply triggering the event before the items are disabled/deleted, and to give the event access to modify the $processedElementIds array.

I will make a quick pull request, but if someone has some additional thoughts, I would be curious to hear them.

[daltonrooney]

+1 for this request because I have the same issue and was about to submit a similar pull request. 😀 In my case, we're importing multiple feeds into the same section, with each feed related to its own category. So the "enable/disable" feature only works if we're able to filter the list of existing entries by category before the feed is processed.

In my case I'm using EVENT_BEFORE_PROCESS_FEED, maybe it would make sense to add existing elements to both the before and after events?

[kristiansp]

@daltonrooney Yes, I've tried using the EVENT_BEFORE_PROCESS_FEED too, and in a way it feels more of a logical way to add it, as it's then pre-populating the list it should not touch (i.e. "already processed", although is not 100% semantically correct).

The issue I was facing then (if I remember correctly), is that you then have to populate actual matching elements with at least enough data that is required for it not to fail on import, and those elements will then be processed like all the others. (Or rather, you have to add them to the feed data?). In either case it feels error-prone, more cumbersome and hacky.

The simplicity of using the EVENT_AFTER_PROCESS_FEED event is that, after the feed is done processing, you just add a bunch of ids to the list of elements that should not be touched, before it makes a simple diff and deletes/disables the rest in bulk. If that made sense?

The downside to adding them at this point is that you have to append them to the array, otherwise you will lose all the elements you just imported too. So some specific parameter for this would be more robust, but would require at least a bit more changes, although it's not complicated per se.