Problem/Motivation

Anytime configuration for views is changed things need to pass through the ViewsConfigUpdater. web/core/modules/views/src/ViewsConfigUpdater.php

This class is really complex even though it's essential for managing config changes.

I would like to help document the class, possibly simplify the class and a stretch goal may be determine if this can be extended to help with updating more generic config updates.

Steps to reproduce

Review some issues that have updated views:
https://www.drupal.org/project/drupal/issues/2640994#comment-15597379
https://www.drupal.org/project/drupal/issues/3333401

Proposed resolution

ViewsConfigUpdater is a class that helps when views config changes happen.
It is needed whenever a views configuration item is added, removed or modified.

The method you create to process the update needs to be called in two places:
updateAll
and
views.post_update

The primary function is processDisplayHandlers which is very complex, but essentially loops over the nested display config.

After updating you will need to update several things in core.
1. Any embedded views will need to be updated with the new config.
2. You will need a new view test to confirm your updates add / remove / update the config as expected.
It is important to note that some of these views that need to be updated may be in zips in the codebase.

In some cases you may need to deprecate the configuration.

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Data model changes

N/A

Release notes snippet

TBD

Comments

nicxvan created an issue. See original summary.

nicxvan’s picture

nicxvan commented

@dww mentioned on slack one area for possible improvement:

Yeah, it could potentially be refactored to not make it so hard to use. Eg this badness of the class trying to save changes that then trigger views_view_presave() instantiating the class again to redo the work, etc.

nicxvan’s picture

nicxvan commented

I think it may be out of scope for this issue, but one of the issues is also that views config updates often require fixture updates which is a whole layer of complexity since they are zipped.

nicxvan’s picture

nicxvan commented

Here is how ECA approaches a similar issue: https://git.drupalcode.org/project/eca/-/merge_requests/423/diffs#031db4...

nicxvan’s picture

nicxvan commented

Additional issues adding this now:
#1383696: Allow a custom HTML element to be selected for a grouping field
#2770835: Add support for tables with two headers in views table display

nicxvan’s picture

nicxvan commented
Issue summary: View changes
catch’s picture

catch
he/him
Primary language English
commented
Related issues: +#3443942: Add proper deprecation notices in config entity presave bc layers
dww’s picture

dww
we/he/they
commented

My comment is linked in the summary, but copying here for visibility:

However, I had to completely rewrite ViewsConfigUpdater::processEntityArgumentUpdate() to operate on entire View entities, instead of using all the per-handler plumbing we've got. To my great dismay, if you copy the existing patterns, ViewsConfigUpdater process functions make a bunch of changes to handler config, then try to save the view, but that instantiates another ViewsConfigUpdater object (this time, with deprecations enabled) to do all the work again. 🤯 So apparently, The Right Way™️ to update a view with all this plumbing is that your process function has to directly update the $view (which isn't even normally passed in to your process function if you think you're just dealing with handlers), not just fix the $handler. 🤦‍♂️

It's probably out of scope to actually fix that as part of an issue with the title "Document ...", but maybe we want to expand the scope here?

nicxvan’s picture

nicxvan commented

I'm ok with slightly expanding scope or making this more of a META.

Honestly, especially now that we are starting to validate config and deprecate it a more generic config updater may be necessary.

@jurgenhaas wrote an updater too to help with ECA token changes. #3449735: Provide post update helper function to rename tokens

Having some generic update notification / modification almost like a hook would be helpful for core and for contrib to keep configuration up to date.

quietone’s picture

quietone commented
Version: 11.0.x-dev » 11.x-dev

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.