I've just run into #1808626: Webform ajax is incompatible with the page cache. - further investigation revealed that the underlying cause is that the build_id is retained in ajax_get_form().
In combination with the anonymous page cache retaining the build_id is a very bad idea. I think it's best to demonstrate this with an example: Two anonymous users fill-out a multi-page form with ajax submission (just like in #1808626: Webform ajax is incompatible with the page cache.).
- User1 loads the page with the form. A build_id is generated and put into a hidden field. The form_state is stored into cache_form.
- User1 submits the first page of the form. The values are stored into the very same form_state array in the cache_form-table
- User2 loads the page with the form and gets the identical build_id from the cache.
- User2 submits the first page and thus overrides the value that were previously stored for User1.
Effectively this makes it impossible to use AJAX for multi-page forms because it breaks the assumption that different users get independent copies of the form_state array.
Solution strategies
I see two solutions for this issue:
- Don't retain the build_id just like it's done for non-ajax form submissions in drupal_get_form().
- Don't display a hidden form-element for the build_id if $conf['cache'] == TRUE and the form is only rendered (as opposed to submitted). ajax_get_form() would need to be adjusted
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | dont-retain-build_id-2096753.patch | 513 bytes | torotil |
Comments
Comment #1
torotil commentedAttempt to simply realize option 1.
Comment #3
torotil commentedOk it seems that the naive approach doesn't work because there is a reason for the build_id being retained in the first place: partial form submissions.
Comment #3.0
torotil commentedmissing word …
Comment #4
David_Rothstein commentedComment #5
David_Rothstein commentedThis was unpublished for a while because it was closely related to https://drupal.org/SA-CORE-2014-002, but now that that's out I'm republishing.
As far as I understand, this was completely fixed by the security release, so I'm tentatively marking this as fixed as well.