Use setConfiguration() to merge default configuration values

Funny that the patch didn't trigger testbot. Re-uploading...

Plugin auto-discovery and configuration is still murky waters for me. I've used the simplest approach possible. Hope it doesn't break any tests.

Also fixed a couple of docs nits along the way.

Could this be the issue? Configurable plugins should merge default configuration values within setConfiguration()

Yep! That was the issue. Funny I'd been following that issue and yet it never occurred to me that it was the cause.

So, here's the final fix.

+ protected $plugin = 'log';
???

That's what makes this patch work actually.

This is the problem: in Entity\SmsGateway

  /**
   * Encapsulates the creation of the SMS gateway SingleLazyPluginCollection.
   *
   * @return \Drupal\sms\Plugin\SmsGatewayPluginCollection
   *   The SMS gateway plugin collection.
   */
  protected function getPluginCollection() {
    if (!$this->pluginCollection) {
      $this->pluginCollection = new SmsGatewayPluginCollection(
        \Drupal::service('plugin.manager.sms_gateway'),
        $this->plugin,
        $this->settings
      );
    }
    return $this->pluginCollection;
  }

  /**
   * {@inheritdoc}
   */
  public function getPluginCollections() {
    return ['settings' => $this->getPluginCollection()];
  }

SmsGateway::getPluginCollections() gets called without any initial values by EntityForm::copyFormValuesToEntity() without the plugin type first being initialized. This is because of how our SmsGatewayForm is implemented: the form is first created without specifying the plugin type because we want to use the same form to choose the plugin type.

I just encountered this issue again (I'd forgotten about it). Drupal 8.4.0-beta1 is out, stable is due in October. We need to fix this.

There are different problems if we are required to hard code a fallback plugin id

What kind of problems are you seeing?

The only other options I can see are to override the DefaultSinglePluginCollection constructor in our SmsGatewayPluginCollection and revert to the original implementation (don't call $this->addInstanceId()), or we change the way we're implementing the plugin form.

I'll post alternative patches later on today.

So, a much neater approach following #14. No need to hardcode the fallback gateway, but we have to override the constructor and only call $this->addInstanceId() if there is a plugin ID specified.

:)

Tests pass on D8.4. I will commit this by the end of the day if there is no further objection to the approach.

Ok. Great. Committed / pushed to 8.x-1.x