Respect form display weights in form preview [#2833096]

Problem
When creating a new form (through Contact Forms), the user can define the form display and view display. Both are working fine when viewing a form or a submission (using the Contact Messages module). However, when the visitor clicks on preview before submitting, the preview shows the individual form field values in an apparently random order.

Inspecting the HTML, it seems, all previewed fields are sorted by their machine name. I am not sure, how the preview is built, in MessageForm.php it says
$form['preview']['message'] = $this->entityManager->getViewBuilder('contact_message')->view($message, 'full');
but I can't find the correct implementation of that function to take a look.

I think, the correct viewBuilder is in the Contact Storage module which is currently Third-Party but seems to be on its way to become part of Drupal 8.3.x (see #2750629: Add view builder for contact module's Message entity). Then I get lost where to look next in order to change the sorting to use weights.

Comment	File	Size	Author
#26	interdiff.txt	427 bytes	KapilV
#26	2833096-26.patch	3.11 KB	KapilV
#26	9.3.x: PHP 8.0 & MySQL 5.7 28,548 pass 10.1.x: PHP 8.1 & MySQL 5.7 28,929 pass
#24	render-preview-message.patch	3.11 KB	Ruuds
#24	9.3.x: PHP 7.4 & MySQL 5.7 Custom Commands Failed
#9	message-fields-weight-2833096-9.patch	675 bytes	Berdir
#9	8.3.x: PHP 5.6 & MySQL 5.5 21,389 pass
#8	view_display_order.png	17.87 KB	broon
#6	form_display_with_preview.png	13.48 KB	broon
#6	form_display_order.png	19.45 KB	broon

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

5 December 2016 at 12:42

Paul Broon created an issue. See original summary.

Comment #2

Berdir

German

Switzerland

CreditAttribution: Berdir at MD Systems GmbH commented 6 January 2017 at 23:28

Component:

entity system

» contact.module

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

Comment #3

Berdir

German

Switzerland

CreditAttribution: Berdir at MD Systems GmbH commented 7 January 2017 at 12:56

Status:

Active

» Closed (duplicate)

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

Comment #4

broon

Potsdam

CreditAttribution: broon commented 9 January 2017 at 11:05

Status:

Closed (duplicate)

» Active

Sorry, but I disagree with this being a duplicate. The linked issue is about the position of the preview in the form (as in having the preview as a whole above or below the form). My issue is that the individual values inside the preview are in wrong order. For example, assume you have two fields in your form: (1) Field 1, name "username", weight -10 and (2) Field 2, name "age", weight 0.

With the weight, the form will show the fields in the order [username, age]. However, if you click preview, the order will be [age, username] as the fields are sorted by machine name instead of the field's weight.

Comment #5

Berdir

German

Switzerland

CreditAttribution: Berdir at MD Systems GmbH commented 9 January 2017 at 11:11

which weight, the form or the view display weight?

View respects the *view* weights.

Comment #6

broon

Potsdam

CreditAttribution: broon commented 9 January 2017 at 12:33

File	Size
form_display_order.png	19.45 KB
form_display_with_preview.png	13.48 KB

Neither weight is respected in the preview.

By setting the form display weight, I can arrange fields within the form (working, see below the order of the fields in the form: [username, age]). I also have the same order set up on the view display page.

But when the user hits the "Preview" button, the fields within the preview do not have the same order as the fields in the form, they are in order [age, username].

Comment #7

Berdir

German

Switzerland

CreditAttribution: Berdir at MD Systems GmbH commented 9 January 2017 at 12:37

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

Comment #8

broon

Potsdam

CreditAttribution: broon commented 9 January 2017 at 22:03

File	Size
view_display_order.png	17.87 KB

Formatter configuration for what? The Preview "field" has no formatter options. Are you talking about the "Manage display" tab? It has no effect here afaik, but as said above it has the same order.

View display

Comment #9

Berdir

German

Switzerland

CreditAttribution: Berdir at MD Systems GmbH commented 9 January 2017 at 22:47

Status:

Active

» Needs review

File	Size
message-fields-weight-2833096-9.patch	675 bytes
8.3.x: PHP 5.6 & MySQL 5.5 21,389 pass

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.

Comment #10

tstoeckler

he/him

German

Essen, Germany

CreditAttribution: tstoeckler as a volunteer commented 10 January 2017 at 09:07

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

Comment #11

broon

Potsdam

CreditAttribution: broon commented 10 January 2017 at 09:22

Thanks for debugging the problem, sometimes it's just a single line. ;) Good job!

It works for me now but I am not deep enough into D8 core to actually RBTC this and as you said, this might have some implications on other behaviour.

Comment #12

Berdir

German

Switzerland

CreditAttribution: Berdir at MD Systems GmbH commented 10 January 2017 at 09:29

Issue tags:

+Needs tests

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.

Comment #13

Wim Leers

Ghent 🇧🇪🇪🇺

CreditAttribution: Wim Leers at Acquia commented 10 January 2017 at 10:37

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 :)

Comment #14

Berdir

German

Comment #24

Ruuds CreditAttribution: Ruuds at Groowup Digital Agency commented 1 June 2021 at 15:21

File	Size
render-preview-message.patch	3.11 KB
9.3.x: PHP 7.4 & MySQL 5.7 Custom Commands Failed

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.

Comment #25

KapilV CreditAttribution: KapilV as a volunteer and at Innoraft for Drupal Care, Drupal Association commented 2 June 2021 at 04:14

Assigned:

Unassigned

» KapilV

Comment #26

KapilV CreditAttribution: KapilV as a volunteer and at Innoraft for Drupal Care, Drupal Association commented 2 June 2021 at 04:17

Status:

Needs work

» Needs review

File	Size
2833096-26.patch	3.11 KB
9.3.x: PHP 8.0 & MySQL 5.7 28,548 pass 10.1.x: PHP 8.1 & MySQL 5.7 28,929 pass
interdiff.txt	427 bytes

File

Size

2833096-26.patch

3.11 KB

9.3.x:
PHP 8.0 & MySQL 5.7 28,548 pass

10.1.x:
PHP 8.1 & MySQL 5.7 28,929 pass

interdiff.txt

427 bytes

fixed Custom Commands Failed.

Comment #27

2 June 2021 at 04:17

Version:

9.3.x-dev

» 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #28

2 June 2021 at 04:17

Version:

9.4.x-dev

» 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #29

2 June 2021 at 04:17

Version:

9.5.x-dev

» 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #30

smustgrave CreditAttribution: smustgrave at Mobomo commented 6 February 2023 at 17:56

Status:	Needs review	» Needs work
Issue tags:		+Needs Review Queue Initiative

For tests requested in #12

Comment #31

6 February 2023 at 17:56

Version:

10.1.x-dev

» 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.