Problem/Motivation

In our installation profile, we have some views that need to vary with a cache context provided by an access control module that is optional; in other words, clients who use the profile can choose whether they want that access control module enabled to enforce access control that way, or leave it disabled (the default), in which case all users on the system have access to content.

Unfortunately, that means that views in the platform need to be exported with a cache context provided by the module so that, when it is enabled, the proper content is shown to each user relative to their permissions. We have discovered that when we do this, though, and the module is not enabled, the site no longer functions because the caching system assumes the cache context will always be available.

We get this error:

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "cache_context.user.custom_grants".

Steps to reproduce

  1. Create a custom module that defines a new cache context service called "cache_context.user.custom_grants".
  2. In the new custom module, define a hook_entity_type_alter() implementation that adds the new cache context to the list_cache_contexts definition of taxonomy terms (so that taxonomy term listings take the new cache context into consideration).
  3. Create a new view that lists taxonomy terms.
  4. Export site configuration.
  5. Confirm that the exported configuration for the view from step 3 includes the new cache context.
  6. Package site configuration up into an installation profile that does not enable the custom module from step 1 by default.
  7. Install a site from the install profile.
  8. Attempt to use the view created in step 3 in the new site.

The view won't load because the "cache_context.user.custom_grants" cache context service isn't available.

Proposed resolution

The cache system should skip over contexts that are not defined; OR, I suppose, views could filter out cache contexts that are not valid when it is loading a view from config.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

GuyPaddock created an issue. See original summary.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

If this is an install profile you can add a forced dependency on the module to the view by editing the yml, see node.type.forum.yml in core for an example

Then you put the view in the profiles config/optional folder and it gets enabled when the module is enabled

guypaddock’s picture

guypaddock commented

@larowlan: the views aren't optional; they're always expected to be installed. As I explained in the write-up, the module is also optional; the problem arises because caching has to be handled differently (more contexts) when the optional module is installed.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

Could you handle that with hook_modules_installed?

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.