Contrib.social

Enabling tvi is difficult with many or re-labeled views

Open on Drupal.org →
Created on 25 October 2021, about 3 years ago
Updated 5 March 2024, 10 months ago

Problem/Motivation

When selecting a view to integrate in the taxonomy vocabulary edit page (/admin/structure/taxonomy/manage/your_vocabulary) the select list can get super duper long:

This is difficult to use, and if you're in the unfortunate group of people that happened to rename one of their view's visible labels to not match the view name, much more difficulter :-\

My request is twofold with a cherry on top:

1) Sort visible options by label instead of view_id

Example:

2) Append the view_id to the end of the label

Example:

... and the cherry.

3) If Select2 is installed, use that instead of a stock <select>

Example:

There you are... I knew I named the view support!

Here's the hook_form_alter code that's generating the above examples. 


function your_module_form_alter(&$form, FormStateInterface &$form_state, $form_id) {

  switch ($form_id) {

    case 'taxonomy_vocabulary_form':
      $options =& $form['tvi']['tvi_view']['#options'];
      $sorted = [];
      // format option labels to include view id
      foreach ($options as $key => $option) {
        // place the view id inside parans after the view label 
        $label = ($key) ? sprintf('%s (%s)',$option,$key) : $option;
        $sorted[$key] = $label;
      }
      // sort the options by their label instead of the key
      $did = sort($sorted);
      if ($did) {
        $form['tvi']['tvi_view']['#options'] = $sorted;
      }
      // if select2 (https://www.drupal.org/project/select2) is installed 
      // then swap out the super 1998 <select> with a fancy searchable control
      $moduleHandler = \Drupal::service('module_handler');
      $have_select2 = $moduleHandler->moduleExists('select2');
      if ($have_select2) {
        $form['tvi']['tvi_view']['#type'] = 'select2';
      }
    break;

  }

}

Steps to reproduce

Have more views than you should.

Proposed resolution

See hook_form_alter() in Problem/Motivation

Remaining tasks

Work in something similar to what I've provided above into the tvi codebase in the proper place ... maybe: tvi/src/Form/TaxonomyViewsIntegratorSettingsForm.php @ getViewDisplayOptions() && buildForm()?

User interface changes

See #3 in Problem/Motivation

API changes

None.

Data model changes

None.

✨ Feature request
Status

Needs work

Version

2.0

Component

User interface

Created by

🇺🇸United States perfectcu.be

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

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

  • Comment almost 2 years ago →
    🇨🇦Canada mikeohara Moncton, NB
  • @mikeohara opened merge request.
  • Comment almost 2 years ago →
    🇨🇦Canada mikeohara Moncton, NB

    So I finally had a moment to work on this. Keeping with the concept I had of not introducing additional 3rd party dependencies outside core, I converted the select list into an autocomplete Ajax field.

    This appears to solve the issue of making the selection of views more streamlined and easier to parse:

    1: Initial Display

    2: Search behaviour

    3: Selection

    Additional enhancements could include filtering out views that do not act on taxonomies/vocabularies, but I am not entirely sure if that is useful or not, and was not initially able to find a way to easily filter that.

    Otherwise, any feedback, contributions to this work is appreciated.

  • Comment almost 2 years ago →
    🇺🇸United States richgerdes New Jersey, USA

    I have mixed opinions on this. I personally have a preference for the select list over the auto complete. I see the desire when a site has a lot of views, but I don't think it should be the default. Ideally for a simple site the select list is a better user experience. I think that auto complete here is unnecessary in most use cases and feels like a less stable implementation. Generally when I've run into an issue like this, I've used a module such as chosen → to switch to an auto complete interface leveraging the front-end instead of requiring the ajax call to load options. Is there a particular reason why you think that the auto complete is a better UX here?

  • Comment over 1 year ago →
    🇨🇦Canada mikeohara Moncton, NB

    It's really around trying to keep this to core behaviour if I can. There are plenty of times when the select list will be too long to effectively parse. Even on moderately complex sites. We could have it so that if the list of views is beyond a certain size it uses autocomplete, but I think adding that logic, or even making it a user choice, adds complexity which could be necessary.

    I am fine with leaving it either way. But I can see where OP was struggling, and it does make some sense to introduce this as an improvement.

  • First commit to issue fork.
  • Status changed to Needs work 10 months ago
  • Comment 10 months ago →
    🇺🇸United States kevinquillen

    I pushed a small change that at least gets Views options ordered alphabetically by their label and not by their ID.

    One way to control and or cut down the list would be to only show Views that have an administrative label of tvi, making those Views the only possible options. Although that would require an update hook to tag Views that are in use by TVI. Alternatively, the autocomplete would need a re-roll.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024