Contrib.social

Performance problem caused by webform_query_webform_submission_access_alter() with large numbers of webforms

Open on Drupal.org →
Created on 4 August 2021, about 4 years ago
Updated 8 December 2023, almost 2 years ago

The webform_query_webform_submission_access_alter() function determines every single webform that a user is allowed to access, then adds those webform IDs to the query. The problem is that in order to do this it has to load every single webform on the system and call the access method on each of them. On sites with a large number of webforms (thousands in our case) this is prohibitive. It gets even worse if you have any non-trivial code in an implementation of hook_webform_access(). Even though the results are cached, even executing this a single time for a user in such a situation is likely to exhaust available memory and exceed timeouts.

It seems to me that Webform needs to follow the lead of core in how it's implemented its node access system with grants and realms so as to avoid having to do this. I recognize this is a significant refactoring effort, and am open to other suggestions, but I just don't see how this can scale otherwise.

🐛 Bug report
Status

Active

Version

6.0

Component

Code

Created by

🇺🇸United States azinck

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.

  • Comment almost 2 years ago →
    🇺🇸United States gribnif

    We have nearly 12,000 webforms on our site that worked fine in D7, but since moving to D9 we're hitting this exact performance problem due to calls to Webform::loadMultiple(). I've had to comment-out webform_query_webform_submission_access_alter(), webform_library_info_build() and \Drupal\webform\Plugin\Condition\Webform::buildConfigurationForm() in order to avoid this problem.

    It's a pity that such a useful and popular module doesn't scale well. Please consider addressing this issue across the entire codebase.

  • Status changed to Postponed 12 days ago
  • Comment 12 days ago →
    🇺🇸United States jrockowitz Brooklyn, NY

    The performance issue with webform_library_info_build has been addressed via 🐛 Out of memory because of too large library definitions Needs work .

    The solution involved adding a layer of caching which is maybe something we can do for the performance issues

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024