Entity displays must have a settings array

As discussed on IRC the settings key is always required so we should just enforce this in ComponentEntityDisplayBase.

Yeah that would make more sense to me.

So yeah, those tests should be changed, weird that we missed this.

I have updated the patch please review.

@visabhishek you can just take the patch from #4 and then fix the assertions in EntityDisplayTest and EntityFormDisplayTest

Hmm, so come to think of it. It doesn't make sense to have a settings key for extra fields because they don't go through the formatter plugin manager.

So this should do it.

Can we get a test for this? (Not the specific regression itself, but whatever it is that triggers a recoverable fatal error when the fix missing.)

Hmm so, even with a widget with no settings, there is always a settings key. Especially since #2136197: Move field/instance/widget/formatter settings out of annotation / plugin definition, pluginSettingsBase has a defaultSettings() method which will always return an array anyway. (and possibly that was ok before that too) So not sure if we still need the protection ...

last patch failed to apply so created this

There are minor issues with the patch in #20 - "warning: 2 lines add whitespace errors.".

Please review revised patch as it applies cleanly.

Changing the assertions to make tests pass.

Taking a look at this for NERDSummit2014

Reroll of patch from #24.
Auto-merge

+++ b/core/lib/Drupal/Core/Entity/EntityDisplayBase.php
@@ -302,6 +302,11 @@ public function setComponent($name, array $options = array()) {
+    if (!isset($options['settings'])) {
+      $options['settings'] = array();
+    }
+

You could just use $options += ['settings' => []] instead of the if()

I am looking on it now.

Reroll of patch from #29, core/modules/entity/src/Tests/ was moved to core/modules/field_ui/src/Tests/. I am not sure if "'settings' => array()" in each assert is needed if we have "if(!isset($options['settings']))" in setComponent method?

needs review

once again #33

pass unittest

I think that initialising third_party_settings would also fix this Migrate issue? #2394615: User Profile entity form display need third_party_settings initialised

I tested this and it does indeed fix the migrate issue. I think this is the best place for it, if there is no reason not to initialise third_party_settings as well then i'm going to close #2394615: User Profile entity form display need third_party_settings initialised in favour of this.

This issue is a normal bug fix, and doesn't include any disruptive changes, so it is allowed per https://www.drupal.org/core/beta-changes. Committed 1867d61 and pushed to 8.0.x. Thanks!