Failing Tests: Configurable plugins should merge default configuration.

Looks like we're only failing on 8.4.x and PHP7. Which is...an interesting combination of things. Maybe something with arrays changed.

There are far fewer fails on 8.3.x. I wonder what changed in 8.4.x...

It's just the js tests failing on 8.3.x from what I can tell. Not sure if that is a problem with my local or not...

Wow, something very odd is going on. The js tests pass if run with the vendor/bin/phpunit runner, but are failing when run with run-tests.sh. I wonder if there's a core issue for this?

At least I can fix some of the notices...

+++ b/src/Plugin/Flag/EntityFlagType.php
@@ -166,7 +166,7 @@ class EntityFlagType extends FlagTypeBase {
-      '#default_value' => $this->configuration['extra_permissions'],
+      '#default_value' => $this->configuration['extra_permissions'] ?? [],

This should use \Drupal\Component\Plugin\ConfigurablePluginInterface::defaultConfiguration()

So the funny thing about most of these failures is that, as Andypost points out, we should be using ::defaultConfiguration(). With the exception of extra_permissions, we *are* using defaultConfiguration() for all the classes that throw the notice.

When I dug around, we do call defaultConfiguration in the FlagTypeBase constructor:

$this->configuration += $this->defaultConfiguration();

But for some reason this isn't calling the child class, but the base class's defaultConfiguration(). We then get an empty array, and all those notices pop up.

Ah, this is the issue: https://www.drupal.org/node/2852190

Here's a fix to do just that.

Oops, missed a plugin where this fix was also needed.

The fix above put the array merge in the wrong method (getConfiguration() rather than setConfiguration()).

Ok, this time! Typo in that last patch using $this->configuration instead of the passed parameter!

Not sure how this has happened

It is nice to have an answer ... I have updated the issue summary to make the change record prominent.

The patch looks like a good solution.

Tests are happy so +1 from me.

I just queued the tests to run against 8.3.x. I think they will be backward compatible since no new methods that might not have existed on 8.3.x are added here.

And it passed. I think this is good to go.