"Edit Group(s) element" fails when too many groups are present

Created on 9 June 2022, over 2 years ago
Updated 14 November 2024, 7 days ago

1.0 Problem/Motivation
When there are more than ~475 Groups in a CiviCRM system, it is not possible to save the "Edit Group(s) element" dialog when building a webform. Disabling groups does not help, but temporarily setting their is_hidden flag (using SQL) seems to provide a workaround.

2.0 Detailed steps to reproduce (embed screenshots)

  1. Install a clean copy of Drupal 9 with CiviCRM and webform_civicrm. This has been tested on Drupal 9.3.15, CiviCRM 5.50.1, and webform_civicrm 6.2.0.
  2. Install this extension to create many Groups (intended for development sites only): https://github.com/AsylumSeekersCentre/au.org.asylumseekerscentre.create...
  3. Use API Explorer v3 to call Group.createmany with number_to_create set to 500
  4. Create a new webform
  5. Enable CiviCRM processing on the webform
  6. Set the "Number of Contacts" to 1 in the CiviCRM section
  7. Set "Enable Tags and Groups Fields" to "Yes"
  8. Set "Group(s)" to "User Select" and press Save Settings
  9. Switch to the Build tab of the webform
  10. Edit the "Group(s)" element
  11. Change the radio button from "Live Options" to "Static Options"
  12. Use the checkbox in the headings to deselect all of the options
  13. Select a small number of Groups (I used the first three in the list, including the Administrators group)
  14. Scroll to the bottom and press Save
  15. Note that after the wheel finishes spinning, the Edit dialog does not disappear as it usually would
  16. Close the Edit dialog and open it again
  17. Note that the Static Options selection has not been saved, and it's still set to Live Options

3.0 Proposed resolution
Ideally, it would cope with any number of Groups available on the system, if a sane number are added to the webform.

Alternatively, a workaround might be to treat Disabled groups the same way it treats Hidden groups (that is, exclude them from the list of static options). This would allow admins to keep the set of enabled groups below the threshold at which it starts to fail, without having to delete all of the old groups.

4.0 Other notes

No messages appear in the Drupal log after the failure occurs.

This issue might affect other long lists of "CiviCRM Options", but we've only encountered it with Groups.

With around 460 groups, the failure occurs when trying to add all of them to the webform as static options, but it works when only adding three. Somewhere around 475 groups, saving always fails.

The SQL field which stores the webform configuration is a longblob, so it's very unlikely to be exceeding the maximum storage size for the field.

My attempts to trace the failure using xdebug have shown that it lands in the onException method of this class:
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Form%21Ev...

The stack trace at that point looks like this:

[0] Drupal\Core\Form\EventSubscriber\FormAjaxSubscriber->onException @ /var/www/clean_d9/web/core/lib/Drupal/Core/Form/EventSubscriber/FormAjaxSubscriber.php:83
[1] call_user_func:{/var/www/clean_d9/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:142} @ /var/www/clean_d9/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:142
[2] Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch @ /var/www/clean_d9/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:142
[3] Symfony\Component\HttpKernel\HttpKernel->handleThrowable @ /var/www/clean_d9/vendor/symfony/http-kernel/HttpKernel.php:219
[4] Symfony\Component\HttpKernel\HttpKernel->handle @ /var/www/clean_d9/vendor/symfony/http-kernel/HttpKernel.php:91
[5] Drupal\Core\StackMiddleware\Session->handle @ /var/www/clean_d9/web/core/lib/Drupal/Core/StackMiddleware/Session.php:58
[6] Drupal\Core\StackMiddleware\KernelPreHandle->handle @ /var/www/clean_d9/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php:48
[7] Drupal\page_cache\StackMiddleware\PageCache->pass @ /var/www/clean_d9/web/core/modules/page_cache/src/StackMiddleware/PageCache.php:106
[8] Drupal\page_cache\StackMiddleware\PageCache->handle @ /var/www/clean_d9/web/core/modules/page_cache/src/StackMiddleware/PageCache.php:85
[9] Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle @ /var/www/clean_d9/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php:48
[11] Stack\StackedHttpKernel->handle @ /var/www/clean_d9/vendor/stack/builder/src/Stack/StackedHttpKernel.php:23
[12] Drupal\Core\DrupalKernel->handle @ /var/www/clean_d9/web/core/lib/Drupal/Core/DrupalKernel.php:708
[13] {main} @ /var/www/clean_d9/web/index.php:19

I haven't figured out where to go from there to diagnose the problem.

Also (and perhaps this should be a separate issue), changing the "Type" from "CiviCRM Options" to "Select" or "Select other" causes a different failure (when there are too many groups, as above). When pressing the minus button to remove a group from a Select list (still in the "Edit Group(s) element" dialog), it presents this error message:
An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (3.91 GB) that this server supports.

Originally the error message said the maximum size was 2 MB, so I increased it to an unrealistic value to confirm that it's not solved by changing the post_max_size and upload_max_filesize PHP limits.

πŸ› Bug report
Status

Active

Version

6.2

Component

Webform/Drupal

Created by

πŸ‡¦πŸ‡ΊAustralia jude.hungerford

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Has there been any progress in reolving this? We have webforms that were migrated over from D7 that were fine until we tried to edit the field, which when it was saved wiped out our existing group settings.

  • πŸ‡¨πŸ‡¦Canada karing πŸ‡¨πŸ‡¦

    I've not heard of any follow up on this or anyone else hitting it. It's definitely an edge case to have that many groups.

  • πŸ‡ΊπŸ‡ΈUnited States elisseck San Diego

    Hi all,

    We resolved this issue by upping the PHP directive max_input_vars. The issue is related to the number of inputs submitted by the build form when you have a large number of groups. You'll need a max_input_vars value of 3 * $number_of_groups + a handful for the rest of the build form items. The default is 1000 so I'd imagine folks with over 330 groups or so are hitting this.

    Changing max_input_vars is fine for us... but if I had to propose a solution for folks that can't for whatever reason... it would probably be either "only submit changed values" or "some sort of groups filtering like on the permissions page" - where I know Drupal has run into this issue before.

    I'm not that familiar with modern drupal webform so i'm not sure how viable either of those would be.

Production build 0.71.5 2024