feeds_alter doesn't support hook_module_implements_alter, hook_hook_info and hook_hook_info_alter

This function is just ridiculous. It should have never existed.

Suscribe, I think that a problem aside of this is that the "default" target mappings for fields, links etc are not exposed properly to hook_feeds_processor_targets_alter so a module that doesn't weight more that feeds can't really alter the target mappings

1. I don't understand why the other contrib modules don't just have feeds integration in their own modules...

But for fields and taxonomy are required to be in feeds right?, now you can't alter a field mapping without doing a weight+1 to the contrib to happen after feeds, maybe this shouldn't be this way.

Link integration with feeds should be in link module, imho.

Correct, core implementations should go in feeds. Things like Date module, Organic groups, etc should be going in files like date.feeds.inc and og.feeds.inc.

For having things like feeds.link.inc, I think we should add a hook_feeds_processor_targets_info for declaring additional mappings and then do a drupal_alter so that the hook_feeds_processor_targets_alter can modify the targets previously added.
Probably the place to do the module_implements would be FeedsProcessor->getMappingTargets.

Marked #1224836: modulename.feeds.inc files are not automatically included as a duplicate of this issue.

This should solve things in the meantime until we remove stupid, stupid feeds_alter().

I couldn't apply this patch as a part of a drush_make script.

This patch is from #9 in p0 so that it can be applied with drush_make

I'd say that latest drush make should support p1 as #745224: Apply patches from git diff and git format-patch

subscribe

Works for me, on a test with ~100 nodes, using CSV importer, and the patch makes sense.

Patch provided on item #11 works, when is this going to be applied to be committed?

#edit

Correction it enables the ability to see the token/mapping fields in the processor mapping config screen. However it doesn't properly load the data on view or edit of the target node. :(

This is currently blocking #1341012: Feeds integration for Entity reference fields.

So what would be the appropriate test case for this patch?

How about checking if something added in a test include file is actually there?

I was hoping for something a bit more specific. What would "something" be?

So specifically, what would be a detail set of steps that would demonstrate the problem, that the patch would then resolve.

This would be the test:
Implement this patch;
Take your favorite mapper. Make sure it is in a mymodule.feeds.inc file;
remove all references to the new file from the . Module and the. Info files;
create a new importer;
import your data.

+1
I committed #988856: Feeds mapper for node_reference and user_reference fields, but I would happily ditch the implementation of hook_init() to include the file containing the feed hooks.

This doesn't need a test. Committed #9 to 7.x-2.x.
http://drupalcode.org/project/feeds.git/commit/c1fb8e2

Dave, thanks for committing. This works nicely and solves an issue in Addressfield (#1023068: Feeds mapper for Address Field). When will there be a new beta release of Feeds?

The original issue "feeds_alter doesn't support hook_module_implements_alter, hook_hook_info and hook_hook_info_alter" has not been fixed by this commit/patch. Anyone searching for this problem will look at this issue, and assume that the problem has been fixed in the latest code, which it definitely has not been. The attached patch does a little to help alleviate this issue, although the only real fix will be to completely remove feeds_alter.

I went ahead and ripped out feeds_alter(). All tests are passing. Does that satisfy your problems?

http://drupalcode.org/project/feeds.git/commit/8658a4e

If feeds_alter is still required by Contrib modules, is there any chance you could add the patch I provided in #1139676-25: feeds_alter doesn't support hook_module_implements_alter, hook_hook_info and hook_hook_info_alter so that the order of the functions called by feeds_alter() can be tweaked a little.

feeds_alter() is deprecated any module using it should be fixed.

What module are we talking about?

The function may well be deprecated, but that doesn't mean it shouldn't be fixed, even if the fix is only partial.

Closed #3054803: func_get_args(), no longer report the original value as passed to a parameter as a duplicate.

@sdrycroft
It's been five years. Can this function finally be removed now?

Hi @magachriz,

As per my understanding we have to remove that function func_get_args(),
Please confirm so that we can contribute the patch for it.

@devdesagar
Feeds isn't using the feeds_alter() function, so we either remove the whole function or do nothing. The function wasn't removed yet because five years ago it could possibly still used by modules that integrated with Feeds seven years ago and that have not updated since.

Applied the patch just to fix the PHP7.2 warning

Applied the patch (https://www.drupal.org/files/issues/2020-05-12/feeds-PHPCompatibility-11...) to fix the PHP 7.3 warning in feeds.module.

Hi, Patch#35 works fine for me. Please find the screenshot.

Patch #35 works for me. Please find the screenshot for the same.

I'll take a bit of a bold move, we don't use this function, it's been deprecated for 6+ years and the deprecation says it will be removed before 2.x release, so I removed it.

LMK if this causes and grief for y'all.