>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3604010. --> Reported by: [pfrenssen](https://www.drupal.org/user/382067) Related to !99 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>On a real (non-CLI) request, <code>WebformElementWebformComputedTwig.computedValue</code> always resolves to an empty string, while the sibling <code>webform_computed_token</code> element on the same built form resolves correctly. Both types share the <code>WebformElementComputedBase.computedValue</code> field resolver, so the divergence is in how the value is computed, not in the GraphQL wiring.</p> <p>Root cause is an interaction between Webform core and how this module builds the form since <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>:</p> <ul> <li>Webform's <code>WebformComputedTwig::computeValue()</code> bails out and returns <code>''</code> when <code>!$theme_manager-&gt;hasActiveTheme() &amp;&amp; PHP_SAPI !== 'cli'</code>. <code>WebformComputedToken::computeValue()</code> has no such guard.</li> <li><code>WebformThemeManager::hasActiveTheme()</code> is route-based: it returns <code>TRUE</code> only when <code>\Drupal::routeMatch()-&gt;getRouteName()</code> is non-empty.</li> <li><code>WebformForm::buildFormRequest()</code> deliberately builds the submission form under a route-less request (resolving to a <code>NullRouteMatch</code>) so that <code>RouteParametersWebformSourceEntity</code> cannot elect the <code>graphql_server</code> config entity as a spurious source entity. With no route name, <code>hasActiveTheme()</code> is <code>FALSE</code>.</li> </ul> <p>Result: on php-fpm (non-CLI) the Twig guard is hit and the value is empty; the token element, lacking the guard, resolves. This is a regression exposed by the build-form change in <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>): that change made <code>computedValue</code> read from the <em>built</em> form, which is what made the token variant resolve, but the route-less build request leaves the Twig variant gated off on the web path.</p> <p>The module's test suite does not catch this. Test runners are CLI, so <code>PHP_SAPI !== 'cli'</code> is <code>FALSE</code> and the Twig guard is skipped entirely; the value computes regardless. The existing <code>ComputedTest</code> already asserts a populated Twig <code>computedValue</code> and passes, giving false confidence. Functional (<code>BrowserTestBase</code>) requests run in-process under CLI as well, so they do not reproduce it either. Any regression guard must therefore target the build-time mechanism (a route / active theme being present during the build), not just assert output.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <p>Against a real (non-CLI) endpoint, query a webform that contains a <code>webform_computed_twig</code> element with a static template (e.g. <code>#template: 'Hello, world!'</code>, <code>#mode: text</code>):</p> <pre><pre>{ webformById(id: "&lt;id&gt;") { form { elements {<br>&nbsp; ... on WebformElementWebformComputedBase { computedValue mode }<br>} } } }</pre></pre><p>The Twig element returns <code>computedValue: ""</code>; a <code>webform_computed_token</code> element on the same form returns its populated value.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>In <code>WebformForm::buildFormRequest()</code>, give the clean build request a parameter-free synthetic route (set <code>_route</code> and a bare <code>_route_object</code> of <code>new Route('/')</code>). <code>\Drupal::routeMatch()</code> then reports a route name during the build, so <code>hasActiveTheme()</code> returns <code>TRUE</code> and Twig computation runs.</p> <p>Because the synthetic route carries no parameters, <code>RouteParametersWebformSourceEntity::getSourceEntity()</code> still finds no entity, so the load-bearing source-entity invariant of the route-less request is preserved. The theme is left to normal negotiation: the synthetic route is not flagged <code>_admin_route</code>, so <code>AdminNegotiator</code> does not apply and <code>DefaultNegotiator</code> selects the site's default front-end theme. That is the correct theme for a decoupled consumer: the same one that would render the form for an end user on a coupled site. The actual render goes through <code>renderInIsolation()</code>, so no further theme wiring is needed beyond passing the guard.</p> <p>The alternative, recomputing the Twig value in the producer/resolver instead of reading it from the built form, is rejected: it duplicates core logic, fights the build-form architecture of <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>, and would still hit the same theme guard unless a route were supplied.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Add the synthetic route to <code>WebformForm::buildFormRequest()</code> with a comment explaining the theme-guard / source-entity interaction.</li> <li>Add a targeted regression test that the form build exposes a route / active theme. This is the only thing that catches this regression, since the CLI test runner bypasses the Twig guard. Assert the mechanism (a non-empty route name / <code>hasActiveTheme()</code> during the build), not just the output.</li> <li>Expand <code>webform_computed_twig</code> value coverage in the shared fixture and <code>ComputedTest</code> across template variants: static, math, filter, conditional, loop, and <code>mode: html | text | auto</code>. This locks the computed-output shape and guards the build path even though, under CLI, it passes independently of the fix.</li> <li>Run phpunit, phpcs and phpstan before commit.</li> </ul>