Cache form table saves very large records when forms are displayed in a view

I'd just start by dumping out the contents of the $context array from that View and posting a representative example up here. I'm guessing we're just storing the View object in there and can filter it out like we filtered out product entities.

I have looked into this, and this is actually a Views bug.
I have opened an issue in that queue and posted a patch: #2059555: View needlessly stored in form state causes huge cache_form entries. Please apply it.

If the Views patch gets rejected I will reopen the issue and add a workaround to Commerce, but the patch makes sense to me for now.

Okay, thanks for clarifying. It's too much in any case.

Okay, let's add a workaround for Commerce. There is no need to serialize any of those params. Thanks for the feedback.

Here's a potential patch.
You will need to revert the Views patch in order for this to work. I will close the views issue.

#11: 2057073-10-reduce-views-form-state-cache.patch queued for re-testing.

Let's try this one.

Hi all, I am having this problem in v1.8 and wonder what the best way forward might be?

Our cache_forms table is growing at the rate of 200MB or more per day, and it's full of the content of any page viewed on our commerce section that is created by a View. And that's most product category/type pages.

I'm assuming it's fixed in the recent -dev version of Commerce, but I'm a bit cautious of updating to the -dev version since this site is live and the Commerce section is installed within a larger site. I think it would be quite hard to roll back if that became necessary?

I'm not a php coder, but if it's necessary to add a bit of code to a specific file I can do it... if it's quite clear!

Thanks for your help.

This patch is obviously ready to go.

Hi, hmmm, this doesn't appear to have worked for me in my commerce v1.8 installation. I applied the patch (manually, since it seemed quite simple), cleared caches, and the cache_form table is still growing by about 20MB every few times I load a commerce page created by a view.

Here's all the code surrounding and including the new code I entered from the patch, in /sites/all/modules/commerce/modules/cart/commerce_cart.module.
This code starts at line 2432, includes the new code from the patch at line 2444, and includes remaining code, unchanged, starting at line 2452 in the file. Sorry, the line numbers didn't come in when I copied in the code.

function commerce_cart_field_attach_view_alter(&$output, $context) {
  // Loop through the fields passed in looking for any product reference fields
  // formatted with the Add to Cart form display formatter.
  foreach ($output as $field_name => $element) {
    if (!empty($element['#formatter']) && $element['#formatter'] == 'commerce_cart_add_to_cart_form') {
      // Prepare the context information needed by the cart form.
      $cart_context = $context;

      // Remove the full entity from the context array and put the ID in instead.
      list($entity_id, $vid, $bundle) = entity_extract_ids($context['entity_type'], $context['entity']);
      $cart_context['entity_id'] = $entity_id;
      unset($cart_context['entity']);
      // Remove the data added by views_handler_field_field, it is unused, but
      // significantly increases the size of the cached form. This is 2057073-15-reduce-views-form-state-cache.patch
      if (is_array($cart_context['display']) && isset($cart_context['display']['views_view'])) {
        unset($cart_context['display']['views_view']);
        unset($cart_context['display']['views_field']);
        unset($cart_context['display']['views_row_id']);
      }

      // Add the context for displaying product fields in the context of an entity
      // that references the product by looking at the entity this product
      // reference field is attached to.
      $cart_context['class_prefix'] = $context['entity_type'] . '-' . $entity_id;
      $cart_context['view_mode'] = $context['entity_type'] . '_' . $element['#view_mode'];

      $entity_uri = entity_uri($context['entity_type'], $element['#object']);

      foreach (element_children($element) as $key) {
        // Extract the drupal_get_form() arguments array from the element.
        $arguments = $element[$key]['#arguments'];

Any ideas of what I should do now? Thanks for your help.

Hi all,

I'm facing the same problem as described in #20
I also added the patch from comment #15 to commerce 1.8 and still having cache_form growing significant. Also when using 'clear_cache' the cache_form doesn't clear but stays the same size...

Is there any implementation in commerce to keep 'cache_form' excluded from clearing when 'clearing cache'?
We're examining this issue for more as a week now and still none of the existing solutions/patches are solving this issue.

Any ideas?

Thanks for helping already.

I'm not really sure why the patch wasn't working for folks. In a quick local test, I saw form state cache_form rows for Add to Cart forms dropping from 200kb to 12kb in line with other Add to Cart forms on the site.

Perhaps there are other things in the form state on those sites where the patch alone isn't sufficient. My recommendation would be to either dump the $cart_context array and see what's in there or, if you can't find anything 200kb in size in there, check the $form_state in general.

If you can nail it down to a Commerce data issue, feel free to open another issue here and we'll address it.

Commit: http://drupalcode.org/project/commerce.git/commitdiff/5b57ab8

Sorry, that I have to reopen this issue, but you've committed the wrong patch. You should have taken the one from #15 (succeeding the automatted tests), but you've chosen an older one from #11 (failing the tests). The is_array() check is very important because otherwise I get the following fatal error (in a PHP 5.2.12 enviroment):

Fatal error: Cannot unset string offsets in xxx/drupal/sites/all/modules/commerce/modules/cart/commerce_cart.module on line 2449

Hmm, interesting. I didn't see that the patch in #11 was using the same empty() check, I just changed it from #15 expecting it to work the same way. So I'm curious to know what's actually going on here...

If it's not empty, it should be unsettable. Can you add a line there in that file and see what it dumps out?

  drupal_set_message('<pre>' . print_r($cart_context, TRUE) .'</pre>');

Just paste it all in here in a code block.

That's the interesting point, I was already wondering when debugging this for myself. Logically, the if condition should never be true in this case. I guess, this could be a PHP bug when checking empty() for an array key but having a string?? Here's the debug message:

Array
(
    [entity_type] => node
    [view_mode] => full
    [display] => full
    [language] => de
    [entity_id] => 14
)

EDIT: thinking about this again, I don't think this behaviour is a PHP bug. You can access string offsets in the same way you use an array, and - although I never tried this out - accessing a string offset not by number but by another char/string will probably translate this to an integer offset. So it's possible that the empty() check does not fail, but unsetting of course leads to an error. That's why the is_array() check makes really sense, and that's why prefer strictly typed languages over (nearly) untyped ones like PHP...

Ahh, you're right. I wasn't aware (or at least had forgotten) that $context['display'] may just be a string view mode name instead of an array; silly me for expecting an array structure to be consistent. : )

https://api.drupal.org/api/drupal/modules%21field%21field.api.php/functi...

I'll just tack an is_array() back on after that empty() check. Thanks for the report!

fwiw, I just tested this code in PHP 5.4.4 and the empty check worked as expected, returning 2 instead of 1:

$array = array(
  'display' => 'full',
);

if (!empty($array['display']['views_view'])) {
  return 1;
}

return 2;

However, using PHP 5.2.17 this returns 1. It appears this may just be a bug in PHP 5.2.x that's since been fixed, and it explains why I didn't run across it in testing. : )

I'm going to make the if statement:

if (!empty($cart_context['display']) && is_array($cart_context['display'])) {
  // ...
}

We don't really need to check if a specific key exists before unsetting it.

Commit: http://drupalcode.org/project/commerce.git/commitdiff/6583e33

Works perfectly :) Thank you!

The patch on #29 worked perfectly! Thanks.

Have you tested this patch with the Product variations ajax select option? I believe this might be the reason why some people still see the error after applying this patch. (Including myself)

This issue still exists.

One Drupal Commerce site I have looked at has a cache_form table size of 7GB! The site heavily uses views, and needless to say it is crawling.

This is with Commerce 7.x-1.9 and Views 7.x-3.7.

I seem to be having the same issue. A fix would be fantastic as the table seriously crashes the server it gets so big.

Views - 7.x-3.7

Latest version of Commerce Kickstarter

I can confirm we are also seeing this behavior. Working on a fix.

I just got DB table 12 GB big in one day.

I will try this https://www.drupal.org/project/optimizedb that should help.

I have a same problem. in my site mysql write 7GB on every hour. i truncate cache_form after run cron but this isn't a correct souloution.

I faced same problem, cleared the cache and now will set cron for this, though there are many modules which provides solution for reducing size of database. Also this module will solve the problem https://www.drupal.org/project/optimizedb

We have cache_form over 40GB :) Our solution was this module https://www.drupal.org/project/safe_cache_form_clear with uploaded "patch".
And run with drush and system cron every hour during peak with limit e.g. 20000 items (settings.php $conf['safe_cache_form_clear_limit'] = 20000;)
+ every 10 minutes between 0-5AM to completely clear the expired.