Consider adding allowed config list

Created on 28 June 2022, almost 2 years ago
Updated 17 April 2023, 12 months ago


In πŸ› Fatal error: Allowed memory size of 268435456 bytes exhausted in on line 149 Fixed we discovered issues with this module using a ton of memory due to infinite recursion issues.

Proposed resolution

To fix the issue we have a number of possible solutions available to us. One of those possible solutions is the use of a targetted / allowed list of config sets. The administrative user can select which sets of config they wish to expose to views.

This idea might push against the original goal of this module: to easily expose all of a site's config to views. But it is a good performance scoping technique and should be considered as an option.

Perhaps it would be good to provide both an inclusion and an exclusion list and have them not provide a default value. So that a user can choose to limit the scope of the module if they want that level of control.

Remaining tasks

  • Add an administrative page to manage this config if we don't have it.
  • Retrieve these lists in config_views_views_data()
  • Use these lists on line 75 of config_views_views_data() :
    if (!in_array($table_name, $exclusion_list) && isset($all_definitions[$key])){
  • Consider providing an explicit warning about how config_facets_facet blows things up (infinite recursion)

User interface changes

Add a new administrative page to manage exclusion / inclusion lists. Need to create an issue for this.

✨ Feature request

Needs work





Created by

πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

Not all content is available!

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

  • πŸ‡ΊπŸ‡ΈUnited States swirt Florida

    This approach makes a lot of sense. Many sites are only going to use this module to expose something specific and are unlikely to make use of all the possible things to expose.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    I'm headed to Florida Drupal Camp later this week. I'll have time to take a shot at this.

  • πŸ‡ΊπŸ‡ΈUnited States swirt Florida

    I am sorry I am not able to attend this year (first year I have missed in 8 yrs). Would have liked to work on this with you.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    I'll send you the code to review.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    I worked on this during Florida Drupal Camp and got pretty close to all the way done. I'm working through some initialization issues and probably some incorrect config schema related to my collection of values (checkboxes).

    I'm going to try to finish this work up and get a merge request in front of you all soon.

  • @cosmicdreams opened merge request.
  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

    Oh cool tests!

  • Status changed to Needs work 12 months ago
  • πŸ‡¬πŸ‡§United Kingdom vijaycs85 London, UK

    the config form looks good. probably we just need to add some test coverage.

  • πŸ‡¬πŸ‡§United Kingdom vijaycs85 London, UK

    We need to include coverage for adding a new entity type from the form and make sure it appears in the views drop down. I have a feeling we need to clear the views cache on the submit of this form so that the hook_views_data would get regenerated, but test would show as if that's the case.

Production build 0.62.1