Error: Cannot use object of type Drupal\features\ConfigurationItem as array

I hit the same issue when upgrading from features-8.x-3.2 to 8.x-3.2.
Features is a great module and a very important one to us, thanks for helping look in to this issue!

Here is a patch for this.

Tested this patch -- I was able to revert my feature successfully. Thanks @mpotter!

Committed to bb63715 and tagging a 3.4 release. Sorry for this regression!

Re-opening this issue as I found a slight issue on the patch for importing new configuration. Sorry when I was testing earlier, I missed the scenario of importing completely new configuration into the system.

Currently seeing:

PHP Fatal error:  Call to a member function getData() on null in /var/www/build/html/modules/contrib/features/drush/features.drush.inc on line 655
Drush command terminated abnormally due to an unrecoverable error.

I think I have a fix for this -- just testing this out before adding a patch.

Added patch to support both reverting existing and importing new configuration.

I kept digging more on this. So I noticed that even though the feedback from drush fr was reporting a successful revert, the actual config was not reverting. New configuration, however, was importing correctly.

I've attached a new patch -- Although this works, I wasn't sure if this is the correct way to handle configuration revert.

This patch goes back to some of the previous code using config_update that we are trying to replace with core code.

The core createConfiguration() function *does* handle creating new configuration. So we shouldn't need to call config_update::revert. All we need to do is handle the case where getData() cannot be called for new config. In that case we just need to pass an empty value and the Features createConfiguration() wrapper will load the config from the module.

Can you try this patch instead?

Sorry, that looks like your patch in #10. Let me look into this more. The core createConfiguration() function should be importing/reverting existing config and our tests for the FeaturesManager::import() function were passing, so something either isn't getting tested properly or there is some other problem here.

OK, the FeaturesManager::createConfiguration will load the config from your package if you don't pass any config data. Calling "getData" is returning the *CURRENT* value of the config, not the *NEW* value loaded from your Features module.

So, it's even easier. Try this patch:

Thanks for your review and comments @mpotter.

I did another test with the latest patch: features_import_dependency_error-2856466-16.patch.

Test:

1. I checked out a branch that has changes to an installed feature (new config and updates to existing config - added new field storage for node entity, and updated the entity form display & entity view displays for node)
2. I imported an existing database dump of a dev instance locally.
3. I ran drush fra to update the configuration

Results:

• Confirmed that the feedback from running the command showed that the new config imported, and existing config was reverted.
• Logged into the site and confirmed that the new config indeed had been imported and same with the updates to the existing config

Same issue here like #9. I've checked Patch #16 with 8.x-3.4 and it work's with my updated config now.

Thank you
Ralf

Slightly improved patch removes extra un-needed call to getConfigCollection. This is what I'll be committing.

Testbot ran *after* the patch was committed. This is working and fixed.