Views do not add the "active" class anymore

In D8 we have two mechanisms:

• For anonymous users we still add the active class
• For authenticated users we use javascript to add the class, as this allows for better cacheability.

Mh, afaik views is not doing anything special here, maybe later I'll have a deeper look into it.

In general I think this should NOT be an option on the row but rather on the field itself. This is more of a logical place to look for, when users would try to find it, IMHO.

@dawehner Where in the field settings would you see this option ?

I'm still a bit confused why we need that in views but not in other places in core. It sounds like a feature/setting we want for the normal link generation as well.

Changing status. Lets see if test bot can get the latest patch.

oops, wrong status

@Haza, great patch! Thank you, it works perfectly.

Nice to have as a patch, but this was all 9 months ago. Has it not gone into core?

Rerolled the patch, please review

Cheking

Checked the patch for 8.4-dev. Works fine.

+++ b/core/modules/views/src/Plugin/views/row/Fields.php
@@ -36,6 +36,7 @@ protected function defineOptions() {
+    $options['generate_active_class'] = array('default' => FALSE);

this line should use short array syntax

Fixed bugs with array syntax.

@merryhamster : Thanks for patch in #28.suggestion in #29 were taken up in #30.

#31 looks ready for prime time. Let's get this committed!

1. +++ b/core/modules/views/config/schema/views.row.schema.yml
   @@ -14,6 +14,9 @@ views.row.fields:
   +      label: 'Generate active class on links'
   
   +++ b/core/modules/views/src/Plugin/views/row/Fields.php
   @@ -57,6 +58,13 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
   +      '#title' => $this->t('Generate active class on links'),
   

   'Generate "active" class for links'

   Also: string addition, will need review.

2. +++ b/core/modules/views/src/Plugin/views/field/FieldPluginBase.php
   @@ -1154,6 +1154,11 @@ public function advancedRender(ResultRow $values) {
   +          // Setting the active class in a link is now an opt-in feature, so
   

   s/in a link/on a link/

3. +++ b/core/modules/views/src/Plugin/views/field/FieldPluginBase.php
   @@ -1154,6 +1154,11 @@ public function advancedRender(ResultRow $values) {
   +          // we need to check if the features is activated for this views.
   

   s/this views/this view/

4. +++ b/core/modules/views/src/Plugin/views/field/FieldPluginBase.php
   @@ -1383,6 +1388,7 @@ protected function renderAsLink($alter, $text, $tokens) {
   +      'set_active_class' => !empty($this->view->rowPlugin->options['generate_active_class']) ? TRUE : FALSE,
   

   The ternary opterator here can be removed.

#31 works like a charm (I think it could be only a little bit cleaned) with 8.3.3. Could be ported on 8.3.4?

As per #35 fixed the issue.

minor changes

This should fix the failing tests.

Let's try that again.

The only change I would make is go with "Add" and not "Generate".

Thanks @Bojhan, that makes sense. Doing that in this patch.
I've also changed the option to add_active_class in order to keep things consistent in the code.

Only a question, if you group by a field (For example if you group all the products for their parent category and also this should be linked), the is-active class is correctly added to product when I'm inside it, but not to the grouped link if I come back to one level (I hope I explained myself)

I successfully applied #45 patch on an actual 8.3.4 system and it works fine. So +1 for RTBC.

This feature is essential for me in D8 because I usually create dynamic menus with views and love this feature in D7.

@C_Logemann — if you're building dynamic menus with Views, check out the little-known Link Trail by Path module as well!

This works as an alternative to patching Views—on almost all site content, not just Views—and also adds active-trail functionality:

https://www.drupal.org/project/link_trail_by_path

Patch #45 works fine for me too, thank you !

Fixing a comment nitpick mentioned in #35.2 and changing my tests failure fix to be more in line with #35.4, which makes more sense.

Tested, worrked

We're missing test coverage for the new functionality. This is not a bug but by design. The active class handling was changed in Drupal 8 for performance. See https://www.drupal.org/node/2167077

-- MY BAD: patch from #54 is working for me after all. Thanks, olafski

Original message:
Applying the patch manually to 8.4 doesn't seem to do anything. No active class added.
Is there some additional configuration / setting needed?

@firfin, the patch in #50 worked for me on Drupal 8.4.2. To see the result I had to clear all caches after applying the patch.

Please only tag string changes after the issue is actually committed. Thanks!

$item['rendered'] can be an object of Markup, not a PHP array.
This will cause a fatal error (that's happened for me).
Fixed the issue, patch attached.

@bohart which kind of MarkupInterface object you get there?

I'd say wont-fix because d8 set active class at front side & this change will break all caching in views
There's change record https://www.drupal.org/node/2167077
According that setting active class is set via drupal.active-link library https://cgit.drupalcode.org/drupal/tree/core/core.libraries.yml#n72
The code is https://cgit.drupalcode.org/drupal/tree/core/misc/active-link.js so probably here some bug with views field plugins render of links
Or somehow theme or custom-whatever excludes library from pages - needs to dig

1. +++ b/core/modules/views/config/schema/views.row.schema.yml
   @@ -14,6 +14,9 @@ views.row.fields:
   +    add_active_class:
   

   this will require to update all saved views! so needs upgrade patch and tests

2. +++ b/core/modules/views/src/Plugin/views/field/FieldPluginBase.php
   @@ -1154,6 +1154,11 @@ public function advancedRender(ResultRow $values) {
   +          if (!empty($this->view->rowPlugin->options['add_active_class']) && is_array($item['rendered']) && !empty($item['rendered']['#url'])) {
   

   Better to check that "rendered" is of renderable interface
   very probably #url could be found in context of renderable element
   Means need explicit tests for both cases

Checked core usage of system_page_attachments() is the only now

  // Handle setting the "active" class on links by:
  // - loading the active-link library if the current user is authenticated;
  // - applying a response filter if the current user is anonymous.
  // @see \Drupal\Core\Link
  // @see \Drupal\Core\Utility\LinkGenerator::generate()
  // @see template_preprocess_links()
  // @see \Drupal\Core\EventSubscriber\ActiveLinkResponseFilter
  if (\Drupal::currentUser()->isAuthenticated()) {
    $page['#attached']['library'][] = 'core/drupal.active-link';
  }

On other hand this option could be useful at view level to attach core's core/drupal.active-link but that affects whole page...
So maybe better to name it kinda "Add view option to bubble up core/drupal.active-link library"

Not clear why that library works only for data-drupal-link-system-path data attribute
and only for menu links https://www.drupal.org/node/2281785

Or core hides this attribute from anonymous users for reason?

maybe js could filter somehow window.location of brower additionally to route naming for links - looks more markup related

+++ b/core/modules/views/src/Plugin/views/row/Fields.php
@@ -57,6 +58,13 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
+    $form['add_active_class'] = [
+      '#type' => 'checkbox',
+      '#title' => $this->t('Add active class on links'),
+      '#default_value' => $this->options['add_active_class'],
+      '#description' => $this->t('If checked, if the fields link to the current page, an "is-active" class will be added on the link.'),
+    ];

Given that this results into the view being less cacheable, I'm wondering whether we could tell tha t the user somehow.

@dawehner: Yes we should tell the user that this feature has an impact on caching.
I think it's enough to extend the description text with a warning.

Suggestion (also see patch and interdiff):
"If checked, if the fields link to the current page, an "is-active" class will be added on the link. WARNING: This feature limits the caching possibilities of this view and should only be enabled when needed."

+++ b/core/modules/views/config/schema/views.row.schema.yml
@@ -14,6 +14,9 @@ views.row.fields:
+      label: 'Add "active" class on links'

+++ b/core/modules/views/src/Plugin/views/row/Fields.php
@@ -57,6 +58,13 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
+      '#title' => $this->t('Add active class on links'),

There is a slight discrepancy here. Can we enclose the word "active" with quotes on the form element as well?

Reroll #64 patch for 8.7.x and added fix for #66.

It also needs upgrade path for existing views & tests (including cachability)

+++ b/core/modules/views/config/schema/views.row.schema.yml
@@ -14,6 +14,9 @@ views.row.fields:
+    add_active_class:

+++ b/core/modules/views/src/Plugin/views/field/FieldPluginBase.php
@@ -1161,6 +1161,11 @@ public function advancedRender(ResultRow $values) {
+          if (!empty($this->view->rowPlugin->options['add_active_class']) && is_array($item['rendered']) && !empty($item['rendered']['#url'])) {
+            $item['rendered']['#url']->setOptions(['set_active_class' => TRUE]);

@@ -1390,6 +1395,7 @@ protected function renderAsLink($alter, $text, $tokens) {
+      'set_active_class' => !empty($this->view->rowPlugin->options['add_active_class']),

I think better to unify more - use the same name "set_active_class" for property

Well at the moment Views (D. 8.6.13) Views still doesn't add the "active" class.
The patch is still not applied.... Am I missing something...?

@francoud the patch is not applied to core yet is because (as of now):

• It is missing test coverage for the new feature.
• It needs an upgrade path to update existing views on sites.
• It needs an upgrade path test to verify it works.
• #69 needs to be addressed.

After that and if there are no more concerns raised up by anyone, it can (hopefully) be marked as Reviewed & tested by the community at which point the core commiters will have a look at it, review it and if deemed acceptable, commit it.

Thanks Manuel Garcia.

Not tested systematically but patch #67 works for me on a Drupal 8.7.1 site.

This addresses #69 and slightly tweaks the UI copy.

+++ b/core/modules/views/src/Plugin/views/row/Fields.php
@@ -57,6 +58,13 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
+      '#description' => $this->t('If checked, if the fields link to the current page, an "is-active" class will be added on active links. WARNING: This feature limits the caching possibilities of this view and should only be enabled when needed.'),

Is this actually true any more? The active class for links is set by misc/active-link.js. It does add some extra markup to the page though for that js, in https://api.drupal.org/api/drupal/core%21includes%21theme.inc/function/t...

Is this actually true any more? The active class for links is set by misc/active-link.js.

Are you asking whether the "WARNING" bit is still true?
I believe this is no longer applicable and should be removed.
Enabling "set_active_class" adds some overhead in LinkGenerator, but the rendered content should be totally cacheable since the class assignment is handled in javascript. IMO the additional processing cost is not worth mentioning in Views UI.

Attached patch updates the message.

Happy to see progress on this!

I've updated the issue summary with the current status, etc.

Patch in #78 works for me. Drupal 8.7.7

Patch in #78 works fine on Drupal 8.8.1

Clean-up implementation a bit but still needs tests and upgrades

Further clean-up

Latest patch in #84 works fine on Drupal 8.8.1, thanks for the update @andypost.

I don't understand why the community doesn't include this in the core? Is there a way I can make it so that I don't have to apply the patch every time I update the Drupal 8 core?

Thx

@timme77 making changes to core takes significant time and effort.
the patch is on its way in to core, with several tasks remaining:

1. Write the patch
2. Review it
3. Add test coverage for the new feature.
4. Write upgrade path to update existing views on sites.
5. Write upgrade path test to verify it works.

Belive me, it's frustrating for everyone to have to wait so long on what seem like minor changes like this.
The sooner you or other volunteers can help out with these, the sooner the patch will land in core.

I decided to have a go at the upgrade path & upgrade path test

I'm getting a schema error locally, however config_inspector does not seem to find any errors...
Schema key views.view.archive:display.default.display_options.row.options.set_active_class failed with: missing schema

Any pointers would be very welcome :)

OK so the problem was that we only want to update the display configuration if:
- display uses fields
- display uses row options

Hopefully this will come back green now.

Great progress! The only missing is test

+++ b/core/modules/views/tests/src/Functional/Update/SetActiveClassTest.php
@@ -0,0 +1,46 @@
+    // Check that the new set_active_class has been set.
+    $this->assertTrue(isset($display['display_options']['row']['options']['set_active_class']));
+    $this->assertSame(FALSE, $display['display_options']['row']['options']['set_active_class']);

it may add a path to view to make sure that attribute is set in HTML

Thanks @andypost for the suggestion about the test, makes sense.

Rerolled #90, three-way merge did the trick:

Checking patch core/modules/views/config/schema/views.row.schema.yml...
Checking patch core/modules/views/src/Plugin/views/field/FieldPluginBase.php...
error: while searching for:
      $tokens = NULL;
      if ($this instanceof MultiItemsFieldHandlerInterface) {
        $items = [];
        foreach ($raw_items as $count => $item) {
          $value = $this->render_item($count, $item);
          if (is_array($value)) {
            $value = (string) $this->getRenderer()->render($value);

error: patch failed: core/modules/views/src/Plugin/views/field/FieldPluginBase.php:1164
Falling back to three-way merge...
Applied patch to 'core/modules/views/src/Plugin/views/field/FieldPluginBase.php' cleanly.
Checking patch core/modules/views/src/Plugin/views/row/Fields.php...
Checking patch core/modules/views/tests/fixtures/update/set-active-class.php...
Checking patch core/modules/views/tests/fixtures/update/views.view.test_set_active_class.yml...
Checking patch core/modules/views/tests/src/Functional/Update/SetActiveClassTest.php...
Checking patch core/modules/views/views.post_update.php...
Applied patch core/modules/views/config/schema/views.row.schema.yml cleanly.
Applied patch core/modules/views/src/Plugin/views/field/FieldPluginBase.php cleanly.
Applied patch core/modules/views/src/Plugin/views/row/Fields.php cleanly.
Applied patch core/modules/views/tests/fixtures/update/set-active-class.php cleanly.
Applied patch core/modules/views/tests/fixtures/update/views.view.test_set_active_class.yml cleanly.
Applied patch core/modules/views/tests/src/Functional/Update/SetActiveClassTest.php cleanly.
Applied patch core/modules/views/views.post_update.php cleanly.

Adding coverage for the functionality itself.

I went with just adding it to the upgrade path test itself, to save the bot some time (and money). Let me know if we should move it to its own functional test instead.

Active link class library has own functional tests, so here we just need to be sure that class is set and library attached, imo that's should be enough

Patch #94 came out wrong due to incorrect git diff config on my end.

Here's the correct patch and the diff between them in case someone's curious.

Re #95:

Active link class library has own functional tests, so here we just need to be sure that class is set and library attached, imo that's should be enough

AFIK there is no need to check for the core/drupal.active-link library itself, as far as I can tell it is always added for authenticated users no matter what: https://git.drupalcode.org/project/drupal/blob/8.8.x/core/modules/system...

I believe it doesn't hurt to have the extra coverage for when the current page is not the the page of the link and thus should not have the active link, so I'm leaving it in place :)

I went with just adding it to the upgrade path test itself, to save the bot some time (and money). Let me know if we should move it to its own functional test instead.

I like your thinking, but unfortunately it needs its own test. Update tests are removed when we remove the update itself (D10 probably) which would mean we would lose the coverage then.

+++ b/core/modules/views/src/Plugin/views/row/Fields.php
@@ -57,6 +58,13 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
+      '#title' => $this->t('Set the active class on links'),

hmmm the wording of the title makes it look like this would always be added. The description clarifies this, but we all know people don't read the UI, so can we clarify the title to make it clear this is added conditionally? Maybe just 'Set the active class on links to the current page', dunno, something like that.

The rest looks great !

Thanks @Lendude for the review!

Changing the option title here as suggested, I agree this clearer.

Also moving the functional test to its own actual functional test, and added a bit of coverage for the option in the views UI itself for good measure.

Dove into this a little more, so more things I see:

+++ b/core/modules/views/src/Plugin/views/row/Fields.php
@@ -57,6 +58,13 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
+      '#description' => $this->t('If checked, if the fields link to the current page, an "is-active" class will be added on active links.'),

Sorry I missed this the first time around but this sentence is a bit wonky. How about:
'When checked an "is-active" class will be added to all fields that are rendered as links that reference the current page.'
Hmm something like that.

+++ b/core/modules/views/src/Plugin/views/field/FieldPluginBase.php
@@ -1163,7 +1163,13 @@ public function advancedRender(ResultRow $values) {
+            $item['rendered']['#url']->setOption('set_active_class', TRUE);

@@ -1393,6 +1399,7 @@ protected function renderAsLink($alter, $text, $tokens) {
+      'set_active_class' => !empty($this->view->rowPlugin->options['set_active_class']),

We add the toggle for 'set_active_class' in two spots, but we are only testing one as far as I can see. So one lacks test coverage.

And then there is #13 which has not been addressed. I agree with @dawehner that the row settings are not a very logical place to add this option. If we feel that this IS the right place for this can we get some motivation as to why that would be? The setting isn't used in the row, it used at a field level.

Thanks again @Lendude for following up on this :)

First, the latest patch needed reroll due to #2989745: views_update_8500() inlines configuration changes instead of this being done on config save for bc

Re #13 I think that makes sense, and also makes this feature more granular which is nice. I have moved it in this patch, which required adjusting the schema, update path and tests.

Also took the time to make use of the new ViewsConfigUpdater class on the update path.

The interdiff is very large mainly because I've updated core's default views (hopefully I didn’t miss any).

Sorry git diff is getting confused and generating strange patches. I regenerated the patch on #102 using git diff -C95% and the new test views added should be easier to review.

@Manuel Garcia nice! Much more logical. Rewrite looks great.

The only real thing I'm concerned about is the placement. It is in prime real estate right now. I think it would be better to fold this into the 'rewrite results' fieldset, or maybe one of the others, but that one makes the most sense to me. Thoughts?

Thanks @Lendude for the review. I agree we should move it, I gave this some thought, and I believe the place to put this option is under Style settings. Since that is what CSS classes are used for, to me it makes sense to put it there. Doing so in this patch.

grr again git with the weird diffs, using git diff -C95% for this one, interdiff on #105 is ok. Appologies..

I'm happy, lets see what others think

Thanks @Lendude - just updating the issue summary a bit.

Mostly looks great, thanks! Big patch, but the actual change is quite small.

However, I've got a few nits / concerns before this is committed:

1. +++ b/core/modules/views/src/Plugin/views/field/FieldPluginBase.php
   @@ -706,6 +708,14 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
   +      '#description' => $this->t('If checked, if the field links to the current page, an "is-active" class will be added on active links.'),
   

   This description is rather clumsy:

   A) The double "if X, if Y" at the start is a bit weird.

   B) "Checked" seems potentially confusing.

   C) "... will be added on active links." is weird. I thought we already qualified what links would see a change with "if the field links to the current page"...

   How about:

   'If the field links to the current page, an "is-active" class will be added if this option is enabled.'

   Or something?

2. +++ b/core/modules/views/src/ViewsConfigUpdater.php
   @@ -273,6 +276,21 @@ public function needsMultivalueBaseFieldUpdate(ViewEntityInterface $view) {
   +   * Sets default value for field set active class option.
   

   Maybe "set_active_class option" instead? With just spaces, it's a bit clumsy to parse.

3. +++ b/core/modules/views/src/ViewsConfigUpdater.php
   @@ -391,6 +409,30 @@ protected function processMultivalueBaseFieldHandler(array &$handler, $handler_t
   +   * Processes field set active class defaults.
   

   And here... "Processes field set_active_class defaults."

4. +++ b/core/modules/views/tests/fixtures/update/views.view.test_set_active_class.yml
   @@ -0,0 +1,183 @@
   +label: 'Test block set active class'
   ...
   +      title: 'Test block set active class'
   

   A) What's "block" got to do with it? ;)

   B) "set_active_class" again here?

5. +++ b/core/modules/views/tests/fixtures/update/views.view.test_set_active_class.yml
   @@ -0,0 +1,183 @@
   +      sorts:
   +        created:
   +          id: created
   +          table: node_field_data
   +          field: created
   +          order: DESC
   +          entity_type: node
   +          entity_field: created
   +          plugin_id: date
   +          relationship: none
   +          group_type: group
   +          admin_label: ''
   +          exposed: false
   +          expose:
   +            label: ''
   +          granularity: second
   

   Why do we care about sorts for this fixture?

6. +++ b/core/modules/views/tests/modules/views_test_config/test_views/views.view.test_set_active_class.yml
   @@ -0,0 +1,183 @@
   +label: 'Test block set active class'
   

   And here?

7. +++ b/core/modules/views/tests/modules/views_test_config/test_views/views.view.test_set_active_class.yml
   @@ -0,0 +1,183 @@
   +      sorts:
   +        created:
   +          id: created
   +          table: node_field_data
   +          field: created
   +          order: DESC
   +          entity_type: node
   +          entity_field: created
   +          plugin_id: date
   +          relationship: none
   +          group_type: group
   +          admin_label: ''
   +          exposed: false
   +          expose:
   +            label: ''
   +          granularity: second
   

   Don't think the test is going to care about sorts, either. Generally, I'm in favor of less moving parts in any given test. If a test doesn't care, don't include that Views feature. Views tests are already complicated and bloated enough. ;)

8. +++ b/core/modules/views/tests/src/Functional/Update/SetActiveClassTest.php
   @@ -0,0 +1,50 @@
   +    // Assert no fields in the test view have the set active class option set.
   

   set_active_class

9. +++ b/core/modules/views/tests/src/Functional/Update/SetActiveClassTest.php
   @@ -0,0 +1,50 @@
   +      $this->assertTrue(isset($field['set_active_class']));
   

   $this->assertArrayHasKey('set_active_class', $field);

10. +++ b/core/modules/views/tests/src/Functional/Update/SetActiveClassTest.php
    @@ -0,0 +1,50 @@
    +      $this->assertSame(FALSE, $field['set_active_class']);
    

    $this->assertFalse($field['set_active_class');

11. +++ b/core/modules/views/tests/src/Functional/ViewsSetActiveClassTest.php
    @@ -0,0 +1,90 @@
    +    // Enable the Set the active class on links to the current page option in
    +    // the view.
    

    Enable the set_active_class option in the view.

Thanks!
-Derek

@dww thanks for your review.
I've added all your warnings and re-rolled the patch against 9.1 branch

Sorry, was added a wrong interdiff.
Also I've made the patch for 8.9 branch with fixes

Trying to fix the failed tests.
The Interdiff the same for both patches

First, thank you @dww for the review, all good points.
Also, thank you @aleevas for moving this forward.

I reviewed the changes since #106 and they look good to me. I attach an interdiff which includes all changes since then for easier review.

I noticed that the change in #109.11 were not quite right so fixing that here. The rest of points on #109 were addressed correctly.

Fixing the failing test here as well (hopefully)

Oops forgot the interdiff I talked about in #117...

Thanks for the fixes, @Manuel Garcia and @aleevas!

This is all I can find in #117 to complain about:

+++ b/core/modules/views/src/Plugin/views/field/FieldPluginBase.php
@@ -1164,7 +1174,13 @@ public function advancedRender(ResultRow $values) {
+          // Setting the active class on a link is now an opt-in feature, so
+          // we need to check if the feature is activated for this field.

"we" would fit on the previous line. ;)

Definitely not worth re-rolling just for that, so I'm going to RTBC. But if anyone finds anything else that needs fixing, we could fix this, too.

Thanks again!
-Derek

1. This needs a change record to document the new functionality and the views changes.

2. +++ b/core/modules/views/src/ViewsConfigUpdater.php
   @@ -455,6 +473,30 @@ protected function processMultivalueBaseFieldHandler(array &$handler, $handler_t
   +      if (!isset($handler['set_active_class'])) {
   +        $handler['set_active_class'] = FALSE;
   +        $changed = TRUE;
   +      }
   

   We need to trigger an E_USER_DEPRECATION error here. Something similar to:
   @trigger_error(sprintf('The entity link url update for the "%s" view is deprecated in drupal:9.0.0 and is removed from drupal:10.0.0. Module-provided Views configuration should be updated to accommodate the changes described at https://www.drupal.org/node/2857891.', $view->id()), E_USER_DEPRECATED);

   And this message should be tested by the legacy test.

3. I think we should \Drupal\Tests\views\Kernel\ViewsConfigUpdaterTest too.

Hi @alexpott,
I have addressed your above comments. Please have a look and let me know if there are any issues.

Hi @alexpott,
Since my previous patch test cases are failed, I am reuploading the patch with some changes. Please have a look.

Fixing these test cases. Uploading the patch again.

Found some parameters are missing. Uploaded the patch again.

Please have a look at this patch.

I think the number of deprecations here should make us step back and have a think. I have a couple of thoughts:

• Is this really the correct level for this setting to go on? Would it make more sense to be part of \Drupal\views\Plugin\views\field\LinkBase - then we’d have far fewer handlers to deal with. On the other hand FieldPluginBase has the make link setting so … hmmm tricky.
• Is it worth considering allowing set_active_class to be omitted from config and therefore not exported to config if it is equal to false. That way none of the configuration change would be necessary. However, doing this comes with the downside of an exported view not having all the settings - so if the default value were to change then all existing views would change.

Could this work/be made available for D7 as well?

I have the problem that many fields don't have the "active" class and thus hover effect styling is not possible
and therefore have to manually add this to each field every time (via style settings > customize field html > create a css class > "active").

@markusd1984 This core issue is about loosing this possibility with views integration in D8 core. Now we have already D9 core stable and this is still not included. The better place to start is the Issue Queue of D7 Views Module. Maybe there is already an existing issue and hopefully a working patch for you. If not you can always open a new issue there.

Here's a try to reroll #128.

Fixed PHPCS error for #136-9.3, Attached interdiff for same. Please review.

Following this thread. I'd love to see this incorporated into core as it is currently an issue for our site trying to style active links generated by a view.

Here is a reroll of #139 for Drupal 9.4.1.

please review my work

please review my work

Patch or MR doesn't apply anymore
The last patch or MR doesn't apply to the target branch, please reroll the code so that it can be reviewed by the automated testbot.

D10 version needed
At this time we would need a D10.1.x patch or MR for this issue.

careful reroll
The patch can be tricky to reroll and some code might get lost in the process. When rerolling this issue please make sure all the parts of the patch are kept (new files, new tests, all the changes to the different parts of the file, changes to es6 files ported to .js files, etc.)

Here is a reroll of #143 for Drupal 9.4.10.

Reroll for 10.1.x
Please review
Thanks

Patch #151 worked for me:
Drupal: 10.1.1
PHP: 8.1.14

Before Patch

Views Configuration

HTML

After Patch

Views Configuration

HTML with config enabled

HTML with config disabled

It is not entirely clear why the last patch in #151 failed because the Drupal CI job output is miles long. This needs to be converted to an MR, with "careful reroll" as pointed out in the issue tags, to get things over to GitLab CI.

Creating a patch file from the MR and uploading it here.

Here is a patch just for 10.4