Invalid argument supplied for foreach() EntityOperationDeriver.php:42

I have the same error here.

Same problem here on Drupal 8.0.1 with both the dev from 3th of December and 1.2.

I have still exactly the same error and have not know what i can do !!!

And i Tested with:
- Newest Drupal (8.0.1)
- Drush 8.0.0 (comes with DevDesktop)
- Normal Composer Install and Updated Composer Version
- Drupal standard and minimal profile

it's really confusing

a rewrite definition is missing from drupalmoduleupgrade.rewriters.yml for the langcode data_type, so instead of having a variable called definition who should be an array, the variable is a string with the langcode eg. DE, and it cannot merge a string and a array.
To fix this we need to add definitions for the langcode in drupalmoduleupgrade.rewrites.yml

patch for language data_type.

@julien thanks but its not help for run drupalmoduleupgrader without the errors :(

@Lennard. Did you uninstall drupalmoduleupgrader and reinstalled it to rebuild the config?

@ Julien now i tried with uninstall and new install...

This Error gone:

PHP Fatal error:  Unsupported operand types in ****/modules/drupalmoduleupgrader/src/Plugin/DMU/Rewriter/GenericDeriver.php on line 50
Drush command terminated abnormally due to an unrecoverable error.                                                 [error]
Error: Unsupported operand types in ****/modules/drupalmoduleupgrader/src/Plugin/DMU/Rewriter/GenericDeriver.php, line 50

And this stay still:
Invalid argument supplied for foreach() EntityOperationDeriver.php:42 [warning]

yes this php warning is coming from something else that i didn't looked for yet.

Big Thanks for you Julien. Now i can used the module for menu routing and the first steps of porting.
For all other things of Changes in Drupal 8 must be programming by own work.
Therefore, one can not recommend it for beginners modules !!

+++ b/config/install/drupalmoduleupgrader.rewriters.yml
@@ -138,3 +138,21 @@ taxonomy_term:
+langcode:
+  type_hint: \Drupal\language\ConfigurableLanguage

How is a $langcode an object? It was supposed to be a language. I mean if the mapping would be from $language to this object, that sounds like would fit the naming patterns used. Not sure how that would fix your bug?

@Gábor Hojtsy, $langcode is maybe the wrong variable coming to:

  public function getDerivativeDefinitions($base_definition) {
    $derivatives = [];

    foreach ($this->config as $data_type => $definition) {
      $derivatives[$data_type] = $definition + $base_definition;
    }

    return $derivatives;
  }

as soon as you don't have en default uk language install.
it seems that static mapping needs to be done in config/install/drupalmoduleupgrader.rewriters.yml for now, default are core node, comment, taxonomy. I think each time a new core module is set during install, this file needs an update.
In my case the $langcode was coming up and was not an array. So it was concatenating an array with a string. To fix $langcode, the name is maybe wrong, but the object is now build from drupalmoduleupgrader.rewriters.yml with the right naming patterns after this.

All right, but drupalmoduleupgrader.rewriters.yml is a mapping for variable names to their Drupal 8 counterparts, right. In Drupal 7 $langcode would be for example 'fr'. How would that have the methods or properties you listed? $language would maybe if used properly :)

yes i agree but langcode cames up here. I don't know yet, if it is the module or the core returning this variable. I did put this issue on the left for sometime now, i should get back into it to sort this variable issue out.

Right, $langcode is a string, $language would have $language->getName(), etc. as per the mapping, so I don't think the mapping is correct or the code you dealt with uses the $langcode variable for a language object, which is not good in the first place. Not surprised if DMU cannot deal with that well :)

yes but where should it return $language instead of $langcode, i'm not sure if it's inside this module but more of the core itself.

It would be good to see the use case honestly.

looks the issue because no config schema provided
here's a quickfix to make module work

Yes fixes the issue for me.

The patch above applies to drupalmoduleupgrader 8.x-1.2, and not to the dev version. Looking at the code that was committed in #2635944: InvalidArgumentException' with message '$string (""), and the above patches, it seems that the proper fix to this issue has already been committed in that issue.