>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3604017. --> Reported by: [pfrenssen](https://www.drupal.org/user/382067) Related to !98 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>A <code>webform_email_confirm</code> element configured with <code>#required: true</code>, <code>#description</code> and <code>#help</code> exposes empty metadata over GraphQL: <code>metadata.required</code> is <code>false</code>, <code>metadata.description</code> and <code>metadata.help</code> are <code>""</code>, while <code>metadata.requiredError</code> on the same element resolves correctly. The authored values are silently lost: there is currently no field a consumer can read them from.</p> <p>Root cause is the build-form switch from <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/graphql_webform/-/work_items/3595276" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/graphql_webform/-/work_items/3595276</a></span> (part of <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/graphql_webform/-/work_items/3595219" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/graphql_webform/-/work_items/3595219</a></span>). These fields resolve through the generic <code>WebformElementProperty</code> producer, which reads the <strong>built</strong> element render array. For <code>webform_email_confirm</code>, the render element's <code>#process</code> callback (<code>WebformEmailConfirm::processWebformEmailConfirm()</code>) redistributes parent properties before the schema walks the element:</p> <ul> <li><code>#description</code>, <code>#help</code>, <code>#help_title</code>, <code>#help_display</code> are copied onto the <code>mail_1</code> sub-element and then <strong>unset</strong> on the parent.</li> <li><code>#required</code> is copied onto the sub-elements and then forced to <code>FALSE</code> on the parent.</li> <li><code>#required_error</code> is copied onto the sub-elements but is <strong>not</strong> cleared on the parent, which is why <code>requiredError</code> still resolves. That is the asymmetry in the report.</li> </ul> <p>So on the built parent element the schema walks, these properties are gone, and the producer reads empty. The <code>mail_1</code> / <code>mail_2</code> sub-elements that now hold them are not exposed as separate GraphQL elements, so the values are unreachable.</p> <p>The module currently codifies this data loss as intended, on an incorrect premise. <code>EmailConfirmTest::testMetadataDescriptionHelpRequiredAbsorbed()</code> asserts the empty values, and its docblock (and the <code>graphql_webform_test_emailconf</code> fixture description) state that a frontend reads the authored values from the confirmation input fields (<code>confirmDescription</code>, ...). That is wrong: <code>confirmDescription</code> resolves from the distinct <code>#confirm__description</code> property of the second input, not from the parent <code>#description</code>; and the parent values are moved onto <code>mail_1</code> (the first input), not the confirmation input. The authored <code>#description</code> / <code>#help</code> / <code>#required</code> have no exposed read path. This is a regression, not intended behavior.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <p>Define a webform with a <code>webform_email_confirm</code> element setting <code>#required: true</code>, <code>#required_error</code>, <code>#description</code> and <code>#help</code>, then query:</p> <pre><pre>{ webformById(id: "ID") { form { elements {<br>&nbsp; ... on WebformElement { metadata { key required requiredError description help } }<br>} } } }</pre></pre><p>Observe <code>required: false</code>, <code>description: ""</code>, <code>help: ""</code>, but a populated <code>requiredError</code>.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Restore parent-level exposure in <code>WebformElementProperty::resolve()</code>. When the element is <code>webform_email_confirm</code> and the requested parent property is empty, fall back to the value carried on the <code>mail_1</code> sub-element. This mirrors the existing <code>webform_multiple</code> wrapper fallback already in that producer, which recovers a property the wrapper redistributes to its per-item template.</p> <p>The fallback must locate <code>mail_1</code> in both positions the <code>#process</code> callback can leave it: directly at <code>element['mail_1']</code>, or nested at <code>element['flexbox']['mail_1']</code> when the element uses the side-by-side flexbox layout. This recovers <code>required</code>, <code>description</code>, <code>help</code> and <code>helpTitle</code> on the parent, matching the pre-build-form contract and consumer expectations. <code>requiredError</code> still reads from the parent and is unaffected.</p> <p>The alternative, exposing <code>mail_1</code> / <code>mail_2</code> as their own GraphQL elements and telling consumers to read metadata there, is rejected: it is a larger surface change, and the parent-level contract is what consumers already expect and what every other element type provides.</p> <p>Other element types that redistribute properties were checked: <code>webform_multiple</code> is already handled by its wrapper fallback, and the composite form-element trait and <code>webform_terms_of_service</code> keep their parent <code>#description</code> / <code>#required</code>. The gap is specific to <code>webform_email_confirm</code>.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Add the <code>webform_email_confirm</code> fallback to <code>WebformElementProperty::resolve()</code>, handling the flat and flexbox-nested <code>mail_1</code> positions.</li> <li>Rewrite <code>EmailConfirmTest::testMetadataDescriptionHelpRequiredAbsorbed()</code> to assert the restored <code>required</code> / <code>description</code> / <code>help</code> / <code>helpTitle</code> (alongside the already-correct <code>requiredError</code>) for the fully-configured fixture element.</li> <li>Correct the now-inaccurate prose: the test docblock and the <code>graphql_webform_test_emailconf</code> fixture description that claim the values are read from the confirmation input fields.</li> <li>Run phpunit, phpcs and phpstan before commit.</li> </ul>