Prevent Drupal from caching pages with forms that include an address field widget

After extensive investigation, it would appear as though there may be something unexpected with how core suppresses validation errors when #limit_validation_errors is set. I don't know the full scope of the issue.

I've confirmed that Address Field is using #limit_validation_errors correctly, and form.inc ultimately calls form_set_error(NULL, '', $form_state['triggering_element']['#limit_validation_errors']); as expected, but even still, the validation error isn't adequately suppressed.

We can hack around it in address field with this patch. This may be a terrible idea, but it works around the problem.

For a slew of related, but ultimately unhelpful reading:

• http://www.drupal4hu.com/node/286
• http://drupal.org/node/1488294

To make this even more obvious and even simpler to reproduce, I've provided a test. In addition to more basic AJAX tests, it tests the exact scenario described in the issue summary above.

I've attached two patches: a test-only patch (which should fail when run), and a patch with the fix from #1.

I've also renamed the issue to be more clear. I'm also going to bump this to major as per this page describing major as an "error which is only triggered under rare circumstances or which affects only a small percentage of all users"

With proper patches this time...

This is related to the Drupal form API's misuse of cache backends as semi-persistent storage for form structure.

The key used to access the form data (stored in cache_form) is based on the validation token associated with the form, which was generated when the form was initially rendered. As such, the validation token for a given form on a given page will be identical for all anonymous users when the Drupal page cache is enabled.

Initially, this doesn't matter because they see the form rendered as it was originally rendered (with all defaults / no data filled out).

When you change the country on an Address field, for what I believe are reasons related to form validation (don't quote me there), it actually changes (and saves in cache_form) an alternate structure for the form relevant to the country. The difference most relevant here is on administrative area where it can change from a textfield to a select list (or from one select list to another). Once the form is actually submitted (as opposed to AJAX-submitted), it attempts to validate the user's input against a now-invalid form structure.

Again, because cache_form's keys are based on the validation token of the originally rendered page, and because all anonymous users have access to that form/token/page, all any anonymous users have the ability to mess with the structure against which actual form POSTs will be validated.

Note that even with the patch above, we were still seeing this error come through on occasion. We ended up going even further:

  // If country change triggered the submission, kill all errors and messages.
  if (_form_element_triggered_scripted_submission($element, $form_state)) {
    drupal_get_messages();
    drupal_static_reset('form_set_error');

    // If the country was changed via AJAX, and the user is anonymous, the
    // existing page cache entry will be invalid, so we have to wipe it. Note
    // we're using the referer here because we're in an AJAX context.
    if (isset($_SERVER['HTTP_REFERER']) && $GLOBALS['user']->uid == 0) {
      cache_clear_all($_SERVER['HTTP_REFERER'], 'cache_page');
    }
  }

It's a big hammer to swing, and even still we see one or two slip through each day (presumably in situations where users are filling out a given form simultaneously).

Thanks for the attention, Ryan.

Unfortunately, #2 would not be a workable solution in my particular case because I'm using Form Block to place user registration forms across whole content types, the effect of which would render a vast majority of the site uncacheable.

Agreed that it'd be better to leave as-is than to introduce the drupal_page_is_cacheable() call.

My use-case includes (but isn't limited to) paid search landing pages where you want the page to be as fast as possible (cached), but also have the form ready immediately (so no ideal way to instantiate a session on the fly). In the code snippet above, only the page cache entry of the associated page is cleared (including query params), and only when a country is changed. It could probably be optimized a little more by only clearing the page cache if the country selected happened to include a select list of administrative divisions (because otherwise, the country change is of little consequence).

And related to that, just to back up a little bit... Something that I often forget when I'm analyzing this issue...

Just to restate the issue, the kernel of the problem is that the page cache is retaining form HTML with a build ID that matches a cached form state primed by some other user. Honestly, I don't consider this a problem of Address Field any more than it would be the problem of any other module using the #ajax framework in a similar way.

You're correct in identifying the underlying oddity of Form API's AJAX component with regards to anonymous users. However, the specific problem that arises that's rarely seen with other AJAX-enabled modules is that Address Field can modify the #type of certain fields under certain circumstances (namely, administrative division).

In situations where it doesn't modify #type, it's of little consequence (e.g. if the default country is the UK and someone changes it to Vietnam, there are no issues because the state field #type was never changed, and thus, Core never gets a chance to run its FAPI validation for select fields). Problems can even be avoided in narrow circumstances where two countries coincidentally have administrative areas with the same shortcode (e.g. starting with Washington, US and switching to Western Australia, Australia).

Perhaps instead of mucking around with cache clearing, we might be better off focusing on better suppressing the core select field validation handler. This area of code, fore reference: https://github.com/asmallwebfirm/scale_addressfield/blob/7.x-1.x/scale_a...

It feels very wrong/dirty, but it might be the only way to support dynamic field #type swapping via AJAX

If you're not comfortable with committing something that takes that approach, I think I'd be alright with option #1 you mentioned in comment #9.

Thanks again, Ryan. Just "verifying" that Drupal 7.27. resolves this issue.