Drupal 7 color settings migration assumes that theme machine names do not contain underscores

This is a follow-up to #2500495: Upgrade path for Color 7.x, which is the commit/issue that introduced the d7_color migration. Not a single commit has touched it since!

Test failures analysis

1. PHP Fatal error:  Uncaught AssertionError: The container was serialized.
   

   This seems like a new regression. Reproduced.

   This is caused by a SchemaIncompleteException with the message Schema errors for color.theme.bartik with the following errors: color.theme.bartik: missing schema being thrown by \Drupal\Core\Config\Development\ConfigSchemaChecker because all Kernel tests have $strictConfigSchema = TRUE:

   

   And further debugging shows very clearly what the bug is: element_name is simply missing from the process pipeline, which causes @MigrateDestination=color to attempt to execute

         $this->configFactory->getEditable($row->getDestinationProperty('configuration_name'))
           ->set($row->getDestinationProperty('element_name'), $row->getDestinationProperty('value'))
           ->save();
   

   while the first parameter of the ::set() call will be NULL, which in turn will trigger the config schema error:
   

   Arguably \Drupal\Core\Config\Config::set() should fail hard on ::set(NULL, …). That would have made this problem evident immediately. Created task + patch: #3187720: Config::set($key, …) requires $key to be a string, but does not typehint nor check this.

2. There was 1 risky test:
   
   1) Drupal\Tests\color\Kernel\Migrate\d7\MigrateColorTest::testMigrateColor
   This test did not perform any assertions
   

   This too. Caused by the previous problem.

3. 1) Drupal\Tests\color\Kernel\Plugin\migrate\source\d7\ColorTest::testSource with data set #0
   […]
   Failed asserting that actual size 0 matches expected size 6.
   
   This too. Also caused by the first problem.

Review

Dependent on the solution to the problems above.

Done.

And now update ColorTest as needed.

@Wim Leers, thanks for improving the color migration.

and the migration plugin definition skips processing several rows (e.g. color_%_screenshot variables) which should be excluded by the migration source plugin.

This is putting back a change that was removed while working on the original issue that added the color migration, around this comment.. Generally, the practice we follow is to get all the data from the source and then use the process pipeline to filter. That way one only has to look at the migration yml to know what is going on. I know that this is not a hard and fast rule but I would prefer to reduce the scope of this to the improvement of handling theme names with underscores. And if we not skipping rows here then this can be a lot simpler, I think.

The test failure in #4 is not fun at all. One such error was fixed in #3189064: Migration sql source plugins can not be serialised because of reference to the database connection and I've started added other ones to #3192893: [META] Serialization issues in Migration tests.

Color is deprecated in 9.5 and removed in Drupal 10, moving to the contrib project.

Wrong project, try again.

Adding re-rolled patch.

Patch updated by fixing failed test case.