In case other modules would like to replace the core Feeds plugins, we should add an alter callback to allow such a change. For example, we're written an importer class which supports Content Translation but it required an update to the base Feeds classes. By adding an alter hook, we can replace the base class and other plugins can inherit the changes accordingly.

The patch to follow.

CommentFileSizeAuthor
#5 feeds_plugin_alter-1994654-5.patch327 bytesbanoodle
#1 1994654-add-plugin-alter.patch325 bytesminoroffense

Comments

minoroffense’s picture

minoroffense commented
Status: Active » Needs review
StatusFileSize
new 1994654-add-plugin-alter.patch325 bytes
twistor’s picture

twistor commented
Status: Needs review » Needs work

While I'm opposed to this in theory, your use case doesn't make sense. Why did you need to change the importer to support content translation? You should just have to subclass FeedsNodeProcessor. Also, I believe there is an issue somewhere that adds that functionality that could use a review or update.

Either way, this hook needs to be documented, and added to hook_hook_into().

megachriz’s picture

megachriz
Primary language Dutch
commented
Status: Needs work » Postponed (maintainer needs more info)

I think you could use one of the following hooks to alter the Feeds plugin definitions already:

  • hook_ctools_plugin_pre_alter()
  • hook_ctools_plugin_post_alter()

Example code:

/**
 * Implements hook_ctools_plugin_pre_alter().
 *
 * Alters the name of the Feeds user processor plugin.
 */
function mymodule_ctools_plugin_pre_alter(&$plugin, &$info) {
  if ($info['module'] == 'feeds' && $plugin['handler']['class'] == 'FeedsUserProcessor') {
    $plugin['name'] = 'User processor (altered)';
  }
}

Does this work for your use case?

minoroffense’s picture

minoroffense commented
Status: Postponed (maintainer needs more info) » Needs work

@MegaChriz I'll see if those hooks could work.

@twistor The reason I can't just extend another class is because of where the changes required to get the tnid value as a valid parent source element in FeedsParser.inc (see getSourceElement())as well as a mapping target in FeedsProcessor.inc (see getMappingTargets()). I don't want to have to rewrite every other class which implements those base classes (i.e. FeedsParserCSV) to get the added functionality in there.

I'm all for adding this functionality into Feeds directly (to support content translation) but with the work being done between Entity Translation and i18n suite of modules, I wasn't sure that would make its way in.

If the other method (altering directly against CTools) works, then we're good (perhaps just add some docs on how to do this). If not, I would still argue this as a valid use case. That way other changes to the base classes could be made if need be.

banoodle’s picture

banoodle commented
Issue summary: View changes
StatusFileSize
new feeds_plugin_alter-1994654-5.patch327 bytes

I have the same need. I tried applying the patch in comment #1 to 7.x-2.x-dev but it failed.

I'm attaching a new one that applies cleanly.

In our case we want to add a new behavior when items are removed from the feed (we want an option to be able to change workflow state) and this hook will facilitate that.

megachriz’s picture

megachriz
Primary language Dutch
commented
Category: Feature request » Support request
Status: Needs work » Fixed

@banoodle
By implementing the hook hook_feeds_config_defaults() you can add third party configuration to Feeds plugins. You do need to implement a form alter as well in order to configure that in the UI.
See also #2822831: Allow other modules to add other options for dealing with non-existent items.

For altering Feeds plugin definitions you can implement hook_ctools_plugin_pre_alter() or hook_ctools_plugin_post_alter() as mentioned in #3.

Status: Fixed » Closed (fixed)

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