PHP 8.0/8.1 compatibility

I've turned on automated testing for PHP 8. There may exist more incompatibilities. It is possible that some of them could also exist in modules that Feeds integrates with. These modules are ctools, date, entity_translation, feeds_xpathparser, i18n, link, og, rules and variable.

PHP 8 testing:
https://www.drupal.org/pift-ci-job/2263997

Patches/issue forks are welcome. I think I won't have time to address this myself.

It looks like the testbot on issue forks can only work with patches? On "Add test / retest" I cannot trigger a test for D7.

Yeah @MegaChriz I've mentioned it on Slack to a few, D7 isn't an option for Core version
https://drupal.slack.com/archives/C51GNJG91/p1639651108308000

Committing this small fix for now, but leaving this open until we can test further.

Could we get a release of this rolled out?

@Christopher Riley
We could create a new release, but it seems like that PHP 8.0 compatibility for Feeds 7.x-2.x isn't done yet. There are a lot of tests failing on PHP 8.1. There are also a few tests failing on PHP 7.4.

Adding a patch for the 7.x-2.0-beta5 release that addresses the deprecation warning:

Deprecated function: Required parameter $context follows optional parameter $feed_nid in include_once() (line 1439 of /var/www/html/includes/bootstrap.inc).

This should be focused on PHP 8.0, 8.1 support and 7.4 test fixes should be in a separate issue.

I think this issue could likely be closed as-is - the only error that appears in the PHP 8.0 tests that doesn't also appear in the 7.4 tests relates to feeds_xpathparser.

feeds_xpathparser is more or less unmaintained, so I think we should ignore these test failures. I see that a lot of the test failures for PHP 8.1 are related to the date module.

@DamienMcKenna
Should we add a test_dependency for the dev version of the date module or wait for a new D7 release of that module?

For PHP 8.1 compatibility? I'm had been holding the next 7.x-2.x release until we resolve a problem that affects d.o, but I suppose I could release it sooner.

@DamienMcKenna
Yes, for PHP 8.1 compatibility. I'm not in a hurry though. I don't pay much attention to the D7 version of Feeds anymore. But I do like to know if there are perhaps more PHP 8.1 issues in Feeds after the tests no longer report ones that look like to be in the date module. Then I would be more confident to create a new Feeds release for D7 for which I can say it is PHP 8.1 compatible.
Only create a new release for the date module if that doesn't hurt your plans with the module.

This issue has actually been targetting both PHP 8.0 and PHP 8.1 so far. Is it too bad to try to handle both in one issue? I'm probably not creating a Feeds release that supports PHP 8.0, but not PHP 8.1.

Given that the module supports both and that the test issues are in other modules, it's a fair point to expand the scope, if nothing else it'll make it easier for people to find.

I'll do a new release of the Date module today.

I just released a new version of Date today with the PHP 8.1 compatibility, hopefully that will fix those test failures for Feeds on 8.1 too.

I can confirm that I was getting this warning when running drush updb:

And that, after applying patch #17, the warning does not appear.

Patch #17 does not apply to dev, and that's because dev already has the fix for that warning.

Can someone evaluate whether anything more needs to be done on this issue, or if it can be closed?

Could we have a new beta/rc release for 7.x-2.x that contains the PHP 8 fixes?

Also, I noticed that in feeds_mapper_file.test, there are two identical lines. See lines 773 and 776:

https://git.drupalcode.org/project/feeds/-/blob/58939ee8c0992a6e2aa822af...

The merge request on this issue added line 776. Is there a reason to have this in there twice?

'instance[settings][file_directory]' => '',

Closing this as-is and releasing right away so people can move to PHP 8 with a few less warnings. Thank you for all your help

Conflict with search_api_solr :
function feeds_batch($method, $importer_id, $feed_nid, &$context) {
if (!isset($feed_nid)) {
$feed_nid = 0;
}

Does not allow to revert some feature like : search_api_index_fields

While function feeds_batch($method, $importer_id, $feed_nid = 0, &$context) {
This works fine.

Any suggestions.

Regards,

The code is functionally identical. If you have custom code calling feeds_batch without that parameter, it would still work the same way.

If you have a specific issue, use PHP's xdebug and set a breakpoint, or put in a debugbacktrace statement and see where the issue is coming from.