Respect form display weights in form preview

Moving to contact.module, which probably simply needs to expose preview as an extra field to fix this in contact_entity_extra_field_info()

And I knew I've seen this before: #1867030: Contact message preview appears at random form position after sorting fields in Manage fields

which weight, the form or the view display weight?

View respects the *view* weights.

That screenshot is the form display, what's your formatter configuration?

Yes, I'm talking about "Manage display". That's exactly what *should* affect that order, and based on your explanations I wasn't sure if that was clear to you.

Based on your feedback, tried it myself and can confirm that problem now. It's a fun conflict between the form system (which has some logic to avoid sorting elements with elements that have no children with an explicit #weight in FormBuilder::doBuildForm()) and the entity render cache process (which pre-creates empty render arrays with just a #pre_render, that then get marked as #sorted). Combined with the fact that most entity types actually have a preprocess where they copy all rendered fields into a new structure and drop any properties set on the container, like #sorted and are therefore not affected by this.

Here's a dirty fix, we probably want something deeper in the renderer, for example something that unsets #sorted if we run a #pre_render or similar function that might add/change elements and their weight.

Wow, I've actually hit this before, too, but didn't realize it was due to the #sorted thing, that's amazing!

yeah, this is not meant to be committed, we need tests and likely a very different fix.

It would actually also conflict with #2756689: Label of contact form message field is not hidden as that issue removes the whole method.

Great find :)

+++ b/core/modules/contact/src/MessageViewBuilder.php
@@ -30,6 +30,7 @@ public function buildComponents(array &$build, array $entities, array $displays,
+      unset($build[0]['#sorted']);

This would need a comment for sure :)

The patch of #9 doesn't work on 8.9.x anymore. I solved the problem by rendering the preview message as markup. It seems the form rendering interferences with the rendering of the nested contact message preview.

See the attached patch.

fixed Custom Commands Failed.

For tests requested in #12

The previous patch didn't apply to Drupal 10, so i've updated it.

Using #markup bypasses field formatters, caching, and theming, leading to inflexible, inconsistent, and unmaintainable output. As per Berdir's comment, overriding buildMultiple in the MessageViewBuilder and explicitly unsetting #sorted resolves the issue.
Just attaching the patch for now (Please validate if this is the right approach/place)

Have not reviewed but was previously tagged for tests and fixes should be in MRs vs patches

I am working on this issue.

I verified code and created MR for this. Attached the screenshots related to my testing.

Still needs test coverage

The Contact Module was approved for removal in #3476879: [Policy] Move Contact module to contrib.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3520460: [meta] Tasks to deprecate the Contact module and the removal work in #3520466: [meta] Tasks to remove Contact module.

Contact will be moved to a contributed project after the Drupal 12.x branch is open.