#3538483: Form build caching is broken in Drupal 11 addressed some caching bugs caused by this core change in Drupal 11 #2578855: Form tokens are now rendered lazily, allow forms to opt in to be cacheable, but it didn't solve all the issues.
See my comment in the other issue for a more detailed explanation.
Short term, for authenticated users, ensure that max-age=0 is set on the form. This restores behavior that Drupal 10 had.
Longer term, in the follow-up #3583047: [Drupal 11.1+] Integrate with Dynamic page cache, we need to ensure all the proper cache contexts are set on the form in every situation. This is especially important These means examining all code paths that depend on some external context (user data, query string params, url, etc). It's possible we're missing a bunch and were getting away with it because core was making the entire form uncacheable anyway.
We for sure know we were missing the user cache context which led to this bug that #3538483: Form build caching is broken in Drupal 11 attempted to fix. The fix there added the cache contexts in the wrong area (and added it to ALWAYS even if the feature for per-user submission limit was off) though so that at least needs to be fixed. However just adding user cache context here is probably not enough. The feature that sets individual user submission limits needs to also be aware of how much TIME has passed, since that feature lets you say for example "this user can submit 1 submission per 5 minutes". In that case the form caching should be disabled entirely anyway.
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | Screenshot_20260413_230624.png | 215.31 KB | mxr576 |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
bkosborneComment #3
liam morlandComment #5
bkosborneSubmitted an MR with the short term fix to restore caching behavior that Drupal 10 had, which is that max-age=0 is set for authenticated users. To restate: D10 added max-age=0 to entity forms for authenticated users. D11 doesn't do that anymore. Without that, caching bugs in Webform are revealed (missing cache contexts).
I also updated the existing test added in #3538483: Form build caching is broken in Drupal 11 to prove that this change was needed. Without this change, the test changes I made show a failure.
Comment #6
bkosborneComment #7
bkosborneComment #8
liam morlandTests are not passing.
Comment #10
liam morlandThis issue and #3505669: Prevent max-age=0 from bubbling for anonymous users to restore caching on CDN are classed as release-blockers for 6.3.0. Are the caching issues big enough that they ought to be release-blockers? Is there anyone able to look at this?
Comment #11
bkosborneYes IMO this should 100% be a release blocker
Comment #12
liam morlandComment #13
liam morlandTests are not passing. This likely needs to be solved in tandem with #3505669: Prevent max-age=0 from bubbling for anonymous users to restore caching on CDN.
Comment #15
jwineichen commentedTesting at DrupalCon Chicago 2026, the 1e5fa74c commit successfully fixes the caching issue for me.
Comment #16
liam morlandJust that commit and not the other changes? If so, please update the merge request and see if the tests will pass.
Comment #17
rachel_norfolkCorrecting the issue tag for DrupalCon
Comment #18
idebr commentedI updated the issue summary to limit the scope to the short term solution: ensure that max-age=0 is set on the form. This is also the current behavior for Drupal 10.
I created a follow-up to integrate with Dynamic page cache, see #3583047: [Drupal 11.1+] Integrate with Dynamic page cache
Updated test assertions to match the max-age set in WebformSubmissionForm
Comment #19
idebr commentedComment #20
mxr576Limiting the scope to restoring the behavior in Drupal 10 makes complete sense to me, this was the goal of the previous attempt, since providing support for proper form caching :tm: could require considerable amount of work.
The changes in the MR looks good to me however neither myself nor my colleague could reproduce the issue based on steps to reproduce with latest dev. (Last commit 794afa).
I have used the default Contact form and modified id based on step 5 and placed it inside the content region.
Enabled render caching debugging and I saw
usercache context on the Webform Contact form blocker render.What did I miss?
Comment #21
idebr commented@mxr576 The merge request contains a failing test, you can use the steps from the automated test to reproduce the issue. The test-only pipeline shows it fails: https://git.drupalcode.org/issue/webform-3561066/-/jobs/9223532
Comment #22
j-leeCode looks good to me.
Comment #23
luke.leberI cannot reproduce this on Webform 6.3.x-dev and 11.4.x-dev even using the minimal profile.
I think the steps to reproduce might need to be updated with other enabling criteria? I've seen issues before that can be reproduced within tests, but not in reality. I'm wondering if perhaps this is one of those kinds nowadays (assuming something upstream shifted to break the original steps to reproduce).
That said, I don't see anything wrong with the change, but want to call out the comment
to add some expectations. Cacheability affects more than just the webform module. All downstream users that have customized things now have to take on this burden too -- something that might not be fit for slipping into a minor release.