Contact message preview appears at random form position after sorting fields in Manage fields

Problem is \Drupal\contact\MessageForm::form() - preview have no weight assigned

Here is the test scenario to trigger the bug :

Part 1 :
Go to the bottom of front page and click on “contact”
Fill the “subject” and “message” fields and click on preview
Check the result: you should see the preview of your message under the message input area. It's the expected behavior.

Part 2 :
Go to /admin/structure/contact
Select “manage form display” for the selected contact form (“Website feedback”)
Sort fields by avoiding weight negative values
Save, restart the part 1 and see the result : contact message preview appears random form position.

We can't simply set some static weight to the container preview, as it can be different for other fields according to “manage form display” Contact page settings. My suggestion is to make preview position configurable like any other Contact page field. Then we will have weight defined by default as well as a new weight for container preview if something will be changed in the display settings. Patch attached.

Also we need test to make sure that preview is always on top (like min element weight -1)

+++ b/core/modules/contact/contact.module
@@ -77,6 +77,11 @@ function contact_entity_extra_field_info() {
+      'weight' => 40,

I won't work, because fields could be reordered in UI but preview should be always above

for tests

adding a test

Thanx, looks great, just a question of BC... do we need update hook?

#6 @andypost says that the field should always be on top... but the fix suggests that we allow re-ordering.

And yes I think we should have an update.

Also #6 seems to contradict #4 - I think #4 is right - the preview should be at the bottom of the form by default.

Yeah, it is at the bottom by default, so a default weight of 40 means there is a pretty good chance that it is still at the bottom by default when applying this patch.

I also don't think this needs an update function. Entity displays update themself automatically with extra and base field definitions, Manually verified that this works fine, it just needs a cache clear. We could add an empty update function to enforce that happens, but IMHO, that's overkill for an addition like this, there are probably other update functions and nothing is broken (not more than without the patch, that is) until you do clear the cache.

Patch unfortunately had a trivial conflict due to an array() => [] change, re-uploading, hope it's still OK if I RTBC.. attaching an actual diff of the two patches to show that I changed nothing, it's just the context that changed.

random fail

More random fails.

Committed and pushed 57fdb94 to 8.3.x and 05c29b2 to 8.2.x. Thanks!