Problem/Motivation

in views_ui/js/ajax.js

  Drupal.AjaxCommands.prototype.viewsHighlight = function (ajax, response, status) {
    $('.hilited').removeClass('hilited');
    $(response.selector).addClass('hilited');
  };

but no css styling is defined and 'hilited' is not inline with command name

Proposed resolution

1) Use "hilighted" class
2) add styling

Remaining tasks

tbd

User interface changes

proper highlighting of contend

API changes

no

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Lendude’s picture

Category: Bug report » Task
Issue tags: +Bug Smash Initiative

I took a little dive into this, and completely unclear why we have this. Didn't dive deeper into the git blame then 2009 when Views 3 was created and this already existed. It is unclear to me what this is supposed to do, but I assume it should highlight the section of the Views UI that just got updated after adding/rearranging handlers.

This has zero test coverage and has been broken since before 8.0.0 was released, it's also broken in D7. My proposal would be to remove this.

Todo:
* Remove adding the Command from \Drupal\views_ui\Form\Ajax\ViewsFormBase::ajaxFormWrapper
* Remove \Drupal\views\Ajax\HighlightCommand
* Remove Drupal.AjaxCommands.viewsHighlight from core/modules/views_ui/js/ajax.es6.js

Lendude’s picture

Title: Views viewsHighlight AJAX command uses undefined selector » Remove Views viewsHighlight AJAX command because it has never worked
Status: Active » Needs review
FileSize
3.77 KB

So something like this....

Lendude’s picture

Oops something snuck into #10, ignore that one

longwave’s picture

Status: Needs review » Needs work

Patch fails to apply.

But +1 to removing this. I did a bit more archaeology and found that the "hilite" feature was first added to Views 6.x-2.x prior to alpha1 in 2008 in https://git.drupalcode.org/project/views/-/commit/999b2e5390c04fb8ef442e... and then the "hilited" CSS was removed in 2010 when the Views admin CSS was overhauled, and never added back again, but the JS still lives on.

andypost’s picture

Looks removal is blocked on deprecation for plugins but ++ remove

I found no usages in contrib

Lendude’s picture

Version: 8.9.x-dev » 9.2.x-dev

Ah yeah, rolled this against 9.2, not 8.9

Nice digging @longwave :)

Not sure if this needs to wait for plugin deprecations? It's an Ajax Command that we are taking out, couldn't we just follow the deprecation guidelines for classes if we want deprecations at all? Seems a bit silly really, it's just dead code, but ¯\_(ツ)_/¯

Lendude’s picture

Status: Needs work » Needs review
FileSize
537 bytes
3.61 KB

Removed the unused use

longwave’s picture

This is not used in contrib: http://grep.xnddx.ru/search?text=HighlightCommand&filename=

Previously we have just removed unused and entirely broken bits of code without going down the deprecation route, maybe we can just do that here?

catch’s picture

I think this is fine to remove as dead and never-working code.

andypost’s picture

Status: Needs review » Reviewed & tested by the community

As everyone agree to remove as deadcode

alexpott’s picture

Issue tags: +Needs change record

What does worked mean in this context? As far as I can see the JS and Ajax class work as described. It's only that in core we don't have .hilited class defined and, importantly, #section is not used as a class name.

Yes this is probably safe to remove as someone relying on it is unlikely. But I'm not sure it is dead code - code that is unreachable and not working. I think we should consider deprecating the class and the JS and removing core usage and then removing in Drupal 10 - just in case someone is using this in custom code.

catch’s picture

Hmm #19 is a good point. We can remove the usage because markup changes are allowed, but given it's used that means it 'works' in the sense of being runnable code, so it should go through deprecation even though we're 99.9% sure no-one is relying on it.

catch’s picture

Status: Reviewed & tested by the community » Needs work

Back to needs work.

longwave’s picture

I was also suspicious of this:

+++ b/core/modules/views_ui/src/Form/Ajax/ViewsFormBase.php
@@ -256,10 +255,6 @@ protected function ajaxFormWrapper($form_class, FormStateInterface &$form_state)
-      if ($section = $form_state->get('#section')) {

The only place #section is referred to in form state is ViewUI::getStandardButtons():

    // Compatibility, to be removed later: // TODO: When is "later"?
    // We used to set these items on the form, but now we want them on the $form_state:
...
    if (isset($form['#section'])) {
      $form_state->set('#section', $form['#section']);
    }

But then does that mean all the other $form['#section'] stuff is redundant as well?

        // We're changing which display these values apply to.
        // Update the #section so it knows what to mark changed.
        $form['#section'] = str_replace('default-', $form_state->get('display_id') . '-', $form['#section']);

Is this "mark changed" also referring to the highlighting feature?

Also, if we add some CSS rules for the class, does this actually do something useful in the Views UI that we might want to keep?

longwave’s picture

FileSize
10.94 KB

I added this CSS rule:

.hilited {
  background-color: red;
}

Then in Views UI if I click "Reorder displays", after closing the modal and reopening the menu, the background is highlighted in red:

This works for some, but by no means all, of the dropdowns in Views UI. For example it looks like it is supposed to work when rearranging filters:

    $form['#section'] = $display_id . 'rearrange-item';

But the class name here is entirely wrong and so the highlighting isn't applied properly.

I don't think this feature is very useful and it seems like we can deprecate this now and then remove all the #section related code in Drupal 10.

andypost’s picture

@longwave thank you for hint!

There's more usages in core

core9$ git grep -F "'#section'"
core/modules/views/src/Plugin/views/HandlerBase.php:331:    $form['#section'] = $display_id . '-' . $type . '-' . $id;
core/modules/views/src/Plugin/views/display/DisplayPluginBase.php:1390:      $form['#section'] = 'default-' . $section;
core/modules/views/src/Plugin/views/display/DisplayPluginBase.php:1393:      $form['#section'] = $this->display['id'] . '-' . $section;
core/modules/views_ui/src/Form/Ajax/AddHandler.php:77:    $form['#section'] = $display_id . 'add-handler';
core/modules/views_ui/src/Form/Ajax/Analyze.php:36:    $form['#section'] = 'analyze';
core/modules/views_ui/src/Form/Ajax/ConfigHandler.php:164:        $form['#section'] = $display_id . '-' . $type . '-' . $id;
core/modules/views_ui/src/Form/Ajax/ConfigHandlerExtra.php:81:        $form['#section'] = $display_id . '-' . $type . '-' . $id;
core/modules/views_ui/src/Form/Ajax/EditDetails.php:36:    $form['#section'] = 'details';
core/modules/views_ui/src/Form/Ajax/Rearrange.php:64:    $form['#section'] = $display_id . 'rearrange-item';
core/modules/views_ui/src/Form/Ajax/RearrangeFilter.php:54:    $form['#section'] = $display_id . 'rearrange-item';
core/modules/views_ui/src/Form/Ajax/ReorderDisplays.php:39:    $form['#section'] = 'reorder';
core/modules/views_ui/src/Form/Ajax/ViewsFormBase.php:259:      if ($section = $form_state->get('#section')) {
core/modules/views_ui/src/ViewUI.php:339:    if (isset($form['#section'])) {
core/modules/views_ui/src/ViewUI.php:340:      $form_state->set('#section', $form['#section']);
core/modules/views_ui/src/ViewUI.php:359:      if ($was_defaulted !== $is_defaulted && isset($form['#section'])) {
core/modules/views_ui/src/ViewUI.php:362:        $form['#section'] = str_replace('default-', $form_state->get('display_id') . '-', $form['#section']);
core/modules/views_ui/views_ui.module:148:          '#section' => $section,

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.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.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.