Address test failures due presumably to changes in core

While the test results show errors only for Config_update.Drupal\Tests\config_update_ui\Functional\ConfigUpdateTest, IIRC locally I got a failure for a 2nd test class in config_update_ui, ConfigProfileOverridesTest.

#2915414: Omit "_core" key from normalized config entities, which includes the default config hash may be related.

There could be two reasons for this:

a) When we revert, we aren't getting the default_config_hash item into the config any more for some reason (like maybe it's getting removed during config save?).

b) When Core exports config on the single export page, it is no longer including the _core section.

I started with b). Steps:

Install core 8.7.x with the 'standard' install profile.
Log in, navigate to /admin/config/development/configuration/single/export, and export "contact.settings" of type "Simple configuration". Result:

default_form: feedback
flood:
  limit: 5
  interval: 3600
user_default_enabled: true
_core:
  default_config_hash: U69DBeuvXuNVOC15rVNaBjDPK2fWFbo9v4takdYSSO8

Implication: b) is not true.

Next looking at a). As a start, what are we doing to revert and what if anything has changed in the core code we're calling?

The test line we're getting this on relates to a config entity rather than simple configuration.

In ConfigReverter::revert() the relevant lines look to be these:

      // Load the current config entity and replace the value. Note that
      // the uuid and _core/hash values are retained for entity-based config,
      // since updateFromStorageRecord() only updates values that are part of
      // the passed-in array, and doesn't remove or alter other values.
      $definition = $this->entityManager->getDefinition($type);
      $id_key = $definition->getKey('id');
      $id = $value[$id_key];
      $entity_storage = $this->entityManager->getStorage($type);
      $entity = $entity_storage->load($id);
      $entity = $entity_storage->updateFromStorageRecord($entity, $value);
      $entity->save();

One possible place to look would be the relevant ::updateFromStorageRecord() method.

Looking at the most recent changes in what looks to be the relevant file:

$ git log core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php

commit f28f56207da4ea7db575cdf766039f872fe56f84
Author: Nathaniel Catchpole
Date: Fri Jul 20 19:38:39 2018 +0100

Issue #2986901 by gabesullice, alexpott: Followup for #2666392: ConfigEntityTypeInterface::getPropertiesToExport no longer returns NULL, throws exception instead

(cherry picked from commit e6cf8fca136ae893c0df7de3b00a85eef3094cfe)

commit b55ed6bd46f0dd189c25cbd842ac9495baf41d67
Author: Nathaniel Catchpole
Date: Fri Jul 13 14:11:18 2018 +0100

Issue #2666392 by alexpott, webflo, xaqrox, Boobaa, dawehner, Berdir: Unable to revert third party settings via config import

Our first test failures seem to be from after that earlier date (July 13, 2018).

Looking to the specific commit and file:

git show b55ed6bd46f core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.phpcommit b55ed6bd46f0dd189c25cbd842ac9495baf41d67
Author: Nathaniel Catchpole <catch@35733.no-reply.drupal.org>
Date:   Fri Jul 13 14:11:18 2018 +0100

    Issue #2666392 by alexpott, webflo, xaqrox, Boobaa, dawehner, Berdir: Unable to revert third party settings via config import

diff --git a/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php b/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php
index 3b90899..e3d38d1 100644
--- a/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php
@@ -450,9 +450,19 @@ public function updateFromStorageRecord(ConfigEntityInterface $entity, array $va
     $data = $this->mapFromStorageRecords([$values]);
     $updated_entity = current($data);
 
-    foreach (array_keys($values) as $property) {
-      $value = $updated_entity->get($property);
-      $entity->set($property, $value);
+    /** @var \Drupal\Core\Config\Entity\ConfigEntityTypeInterface $entity_type */
+    $entity_type = $this->getEntityType();
+    $id_key = $entity_type->getKey('id');
+    foreach ($entity_type->getPropertiesToExport($updated_entity->get($id_key)) as $property) {
+      if ($property === $this->uuidKey) {
+        // During an update the UUID field should not be copied. Under regular
+        // circumstances the values will be equal. If configuration is written
+        // twice during configuration install the updated entity will not have a
+        // UUID.
+        // @see \Drupal\Core\Config\ConfigInstaller::createConfiguration()
+        continue;
+      }
+      $entity->set($property, $updated_entity->get($property));
     }

So, there have been changes in the method we're calling--but whether that's related or not remains TBD.

@jhodgdon That all sounds right, but I'm not following the code well enough to be certain of this part:

As of the commit above, this function now does mess with __core.

The revised code calls ConfigEntityType::getPropertiesToExport(), and that at least under certain conditions includes '_core' among the listed properties.

That sounds right.

Note: I jumped into looking at the code. I haven't yet tested to confirm I can reproduce what I'm assuming is the bug--that when we revert a config entity, we lose the _core property.

Yep, thanks for fixing this, good to go. I added a test with core 8.5 and that passed too.