Add View filter plugin to improve experience for content editor

Fix patch to viewing exposed filters not all filters.

Patch only showing exposed filters based on #7

This would be a really nice feature to have. I tested the patch in #10 and my view is not getting filtered.

The id of the taxonomy term is getting captured in the data for the field in the DB, but the views query is not effected by the filters. Am I missing any configuration?

A few nice-to-haves:

• The filters should use the label given to them in Views UI, not machine names.
• The options listed should be Labels, not keys. For example, a filter by content type has the option of "article" instead of "News".

FWIW, I think it makes the most sense to only show the exposed filters to the author. Exposed filters do not get rendered on the front end anyway.

This feature is very useful, thanks for the patch but I got the same result as #11 the view is not getting filtered. I made some adjustments to make it work. I also updated the validation to only show the exposed filters.

Hope this helps, please update the issue if someone find another issue.

Hi all. This is indeed a nice-to-have functionality, as using the current Argument plugin is pretty impossible for standard content editors (not skilled with Drupal or Views conventions).

However I believe if we change the approach a bit, current implementation and future improvements will be much easier. Specifically:

1. OK with AJAX triggered on selecting the display too
2. Implementation on #12 for "filters" looks like only covering taxonomy terms? This is probably not accettable as a base functionality because if there are not-taxonomy exposed filters the form becomes messy and confusing. Why don't we either:
   a) Use handlers' form element, instead of forcing this to be a dropdown.
   b) (better!) We use arguments rather than filters, and we provide ViewReferenceSettings plugins for basic field types? For example this issue can provide the plugins for entity_reference, list_string and list_integer which I'm sure will cover a good 75% of filtering cases?
3. Current implementation is complex - IMHO - because ViewsReferenceSettingInterface::alterFormField() can't access the current view and the form_state. I think if we pass both to the plugins we'll reduce complexity as delegating plugins to have their own logic.

Thoughts?

Working on this. Using arguments is too complex, because Views doesn't handle them as fields/widgets but simply as tables relationship. Using exposed filters provides at least a UI to the (views) editor to select the form element and some more details.

I've got a solution which is really simple and hopefully covers most of scenarios. I'll clean up and post it in here soon.

Here we go. On this patch I'm providing the editor with View's (display's) exposed filters. The form element are handled by each filter plugin, so it should work with pretty much any exposed filter.

I've also tested it with some weird libraries providing filters widgets, in order to cover most scenarios possible.

There is still space for improvement, but I'm technically changing 10-15 lines of code (half being due a change in the interface) + one new plugin, so should have really few if no disruption.

Please test and review.

UPDATE: there is no interdiff as I started pretty much from scratch.

I have the patch in #15 installed, but it doesn't seem to filter the view. It's a basic taxonomy term filter, works as expected in the Views preview, but when the field it rendered I see all results.

When I save the node with the Views Reference, I see an error in the log:

Warning: Creating default object from empty value in Drupal\viewsreference\Plugin\ViewsReferenceSetting\ViewsReferenceExposedFilters->alterView() (line 90 ...

If more information from the log would be helpful in debugging, please let me know.

@scottsawyer can you provide the view config yaml file?

I'm using this either with single or multiple filters, all of them being taxonomy term filters, and I didn't get your error.

@gambry, thank you for looking. I posted on pastebin: https://pastebin.com/2prGAUXS, I removed all of the displays except Master and the one that throws the error.

@scottsawyer I don't see any problem, other than in the default display (and the extended one) the filter for the taxonomy field is not exposed.

Also the warning you posted is on assigning the value to the filter, saying the order of the filters in the exposed form in the content edit page is not the same order of the filters when the view is executed. Can you investigate a bit more?

I can't replicate it locally. And as I said locally I have 3 exposed filters, so likely to mess-up with ordering.

@gambry, I forgot that I removed the exposed filter when creating the new displays.
Here I expose the filter:

Then I set the filter on my node:

When I save, the filter is not applied ( I get all results, not just "Hats" ), and I get 2 PHP warnings in the log, both the same message:

Warning: Creating default object from empty value in Drupal\viewsreference\Plugin\ViewsReferenceSetting\ViewsReferenceExposedFilters->alterView() (line 90 of /public/web/modules/contrib/viewsreference/src/Plugin/ViewsReferenceSetting/ViewsReferenceExposedFilters.php) #0 /public/web/core/includes/bootstrap.inc(587): _drupal_error_handler_real(2, 'Creating defaul...', '/public/web/...', 90

In a different display with no exposed filter, it filters properly.

Hey... this is a feature that we would really appreciate to have so I would like to support you in implementing it.

I installed the module and applied the patch and got the same errors as described above.

I solved it by changing alterView() to

  /**
   * {@inheritdoc}
   */
  public function alterView(ViewExecutable $view, $values) {
    if (!empty($values) && is_array($values)) {
      $view_filters = $view->display_handler->getOption('filters');
      foreach ($values as $index => $value) {
        if (!empty($value) && isset($view_filters[$index])) {
          $filters[$index] = $value;
        }
      }
      $view->setExposedInput($filters);
    }

    // Force exposed filters form to not display when rendering the view.
    $view->display_handler->setOption('exposed_block', TRUE);
  }

See the $view->setExposedInput($filters) which makes the magic

But what I realized: when I first choose a view the options field is not filled with the exposed filters available. I need to save the entity with the views reference field first (after choosing a view), when I edit the entity after that again I see the exposed filters from the referenced view. Additionally the values I choose for the exposed filters are not saved - they disappear when I save the entity. This only appears to be an issue with the autosuggest field widget.

Another issue with the patch: when I add an autosuggest term reference field with multiple values allowed ViewsReferenceExposedFilters->alterFormField() in line 73 $current_values[$info['value']] will be an array. This leads to the following error:

Notice: Array to string conversion in Drupal\Core\Template\AttributeArray->__toString() (Zeile 73 in C:\wamp64\www\awdrupal8\httpdocs\core\lib\Drupal\Core\Template\AttributeArray.php).

Additionally in the filter field there is just the word "Array" instead of the terms.

Ok, let's wrap-up current issues and make some progress:

1. From #21:
   

   See the `$view->setExposedInput($filters) which makes the magic`

   I like this. Let's have this is if it fixes issues on #20

2. From #22:
   

   when I first choose a view the options field is not filled with the exposed filters available. I need to save the entity with the views reference field first (after choosing a view), when I edit the entity after that again I see the exposed filters from the referenced view. Additionally the values I choose for the exposed filters are not saved - they disappear when I save the entity. This only appears to be an issue with the autosuggest field widget.

   . Can you describe this more? Any error in the console or watchdog? Do you think this is only an AJAX handler issue, or a conflict between what we currently do and "autosuggest"?

3. From #23
   

   Another issue with the patch: when I add an autosuggest term reference field with multiple values allowed ViewsReferenceExposedFilters->alterFormField() in line 73 $current_values[$info['value']] will be an array

   Not sure what to do in here, we may have to re-think the way we are doing the form_field... but if this issue only manifests with a single form field type it's tricky to judge the refactoring workload with the values it may bring?

This issue needs work because at least 1. should be applied to current work, and 2. should get some investigation. Thanks @tobiberlin !

Great work being done here, thanks! Here is a quick first review on the overall approach.

1. +++ b/src/Plugin/Field/FieldWidget/ViewsReferenceTrait.php
   @@ -125,6 +125,16 @@ trait ViewsReferenceTrait {
   +    $element['display_id']['#ajax'] = [
   +      'callback' => [$class, 'itemAjaxRefresh'],
   

   I needed this for a project recently as well, makes a lot of sense!

2. +++ b/src/Plugin/Field/FieldWidget/ViewsReferenceTrait.php
   @@ -161,7 +180,7 @@ trait ViewsReferenceTrait {
   +        $plugin_instance->alterFormField($element['options'][$plugin_definition['id']], $view);
   

   Maybe it would be better to pass the $field_value instead of a loaded view?

3. +++ b/src/Plugin/ViewsReferenceSetting/ViewsReferenceExposedFilters.php
   @@ -0,0 +1,99 @@
   +class ViewsReferenceExposedFilters extends PluginBase implements ViewsReferenceSettingInterface {
   

   Could we add this in a separate submodule to make it optional? I can see how this helps people, but personally I prefer to separate the exposed filters and the views reference settings. So it would be great to make this optional.

+++ b/src/Plugin/ViewsReferenceSettingInterface.php
@@ -15,8 +15,11 @@ interface ViewsReferenceSettingInterface extends PluginInspectionInterface {
+  public function alterFormField(&$form_field, ViewExecutable $view = NULL);

After reviewing a different issue I realised this breaks the API. Also see my comment in #3081979-2: Add $element and $form_state to interface method alterFormField. I do think we should solve this but we have to make sure it doesn't break existing sites. We should probably fix this specific thing in the other issue and base this patch on top of that one.

Ignore my previous comment. I just found #2957177: Pass view name and display id to alterFormField() method in ViewsReferenceSetting plugin which has a very creative solution to work around the BC issues.

After reviewing a different issue I realised this breaks the API

Ignore my previous comment. I just found #2957177: Pass view name and display id to alterFormField() method in ViewsReferenceSetting plugin which has a very creative solution to work around the BC issues.

Yep, it does break the API, but this way is consistent with the other method alterView() where we pass the view object. With #2957177: Pass view name and display id to alterFormField() method in ViewsReferenceSetting plugin not only we will have each plugin handling the - same - view in the two methods in two different ways, but there is no way of documenting the view is actually loadable from the config, unless you dig down ViewsReferenceTrait code until line 163.

Each plugin requiring the view in its alterFormField() will be forced to load the view in their own ways, which is a waste of memory as the same view will be loaded in multiple objects.

Yeah, solution in #15 breaks the API, but at:

• Adds consistency
• Ensure performances passing the view by reference and so memory usage is reduced (AFAIK)
• Self-document how to access the view

The config solution is nice too, but only if there was a base method - or a trait - doing something like:

protected function loadView() {
static $view;
if (!isset($view) && $view = Views::getView($field_value['target_id'])) {
  $view->setDisplay($field_value['display_id']);
  $view->initHandlers();
}

return $view;
}

Which - again - won't be immediate to developers trying to use the plugin type by just reading the interface, but at least we reuse the same $view object, and there is a helper which avoid the far-west of everyone loading the view on own ways. Thoughts?
(I'll cross-post this last bit in there)

One option could be to improve #2957177: Pass view name and display id to alterFormField() method in ViewsReferenceSetting plugin with a trait, and doing the API change in a follow up for next major version.

Response to comment #24

I did not go deeper into the Ajax problem with autosuggest field widget for choosing a view yet but hopefully will find some time for that later.

Regarding the problem that I described about multiple entity autocomplete fields with already two or more entity defined I found out that the EntityAutocomplete widget would do the work of turning the array of entities into a string with titles in EntityAutocomplete ->valueCallback(). But there are two problems with the current $form_field:

1. The autocomplete field array ($form_field) needs to get #process_default_value = true. It seems that $handler->buildExposedForm($form_field, $form_state); does not properly build the field widget array with all needed information for autocomplete handling into $form_field. Usually these values are set EntityAutocomplete->getInfo() but this method does not get called when you build the $form_field
2. The #default_value needs to be an array of entities, not an array of target_id

I wonder if there would be a more secure way to render the exposed filter form fields to assure that any kind of field widget may work as expected. Maybe we could simply render the exposed form directly into the options instead of building every filter widget on its own?! I will test some other filters and field widgets for exposed filters later - maybe I will find some other issues. If not it may be easier to simply work around the autocomplete issue.

First of all I have to say I like the idea here.

Secondly, I tend to agree with #30 - for safety - but also to note that perhaps by rendering the complete exposed form we could make use of modules altering it, like BEF.

However I haven't (yet anyway) had time to look into how we could approach this suggestion. That would require that I take a deeper look in the code not only in this patch but also the module in general and perhaps some other modules leveraging the exposed form (if there are any).

@Abdelrahman_Amer can you describe what values your patches are bringing? Otherwise people won't follow, nor review.
Also is a good habit to add an interdiff file to better explain what has been changed. I'm hiding those files while waiting for a description, at least for the latest one.

Unless anything is provided, current patch is #15 with work needed as per comments on #24, #25, understanding and maybe including (waiting!) changes from #2957177: Pass view name and display id to alterFormField() method in ViewsReferenceSetting plugin and probably feedback from #30.

This patch only adds $view->setExposedInput($filters) change as per #24.1 . Nothing more.

Also #24.2 can be ignored until more info about the bug (see #30) and #24.3 change request are covered by #30.

So currently this issue Needs Work as per

• comment #25
• understanding and maybe including (waiting!) changes from #2957177: Pass view name and display id to alterFormField() method in ViewsReferenceSetting plugin
• feedback from #30

About latest point RE feedback from #30 and specifically:

Maybe we could simply render the exposed form directly into the options instead of building every filter widget on its own?!

I did a bit of research and we could potentially replace ALL code in ViewsReferenceExposedFilters::alterFormField() with simply

    if (!$view) {
      $form_field = [];
      return;
    }

    $current_values = $form_field['#default_value'];
    unset($form_field['#default_value']);
    $form_field['#type'] = 'container';
    $form_field['#tree'] = TRUE;

    // Some plugin may look into current exposed input to change some behaviour,
    // i.e. setting a default value (see SHS for an example). So set current
    // values as exposed input.
    $view->setExposedInput($current_values);
   
   $exposed_form = $this->display_handler->getPlugin('exposed_form');
   $form = $exposed_form->renderExposedForm();

   // ...transform $form to be nice applicable to $form_field

We only need to clean up $form - i.e. from 'actions' item - , and restore the bit of logic we are currently doing re-enabling form items titles, but technically this should use Views' way of building exposed form opening to all sort of altering. I haven't tried, but should work.

+++ b/src/Plugin/ViewsReferenceSetting/ViewsReferenceExposedFilters.php
@@ -0,0 +1,103 @@
+        if (!empty($value) && isset($view_filters[$index])) {

This line of code causes an issue when the site-builder changes filters identifiers to anything other than the default one. I believe skipping this logic entirely and just using $view->setExposedInput($values) with a cleanup similar to \Drupal\views_ui::renderPreview() on line 551 should work.

The last patch, #37, works for me. But we require that the exposed filter remain visible, I think that we should add a "show filter" checkbox in each exposed filter in ViewsReferenceExposedFilters::alterFormField, but I don't know where storage that settings.

But we require that the exposed filter remain visible, I think that we should add a "show filter" checkbox in each exposed filter

I'm not sure what do you mean? To have the exposed filters showing up in the frontend as well, rather than only available to editors?

This issue is specifically to improve editor experience, if you want exposed filters I believe you can set them up in the view and by just exposing them they should show in the FE? So without passing from this plugin?

I mean that the editor should decide if he set the settings to a default value in exposed filters or if he wants to fix the filter to the values that he selects (how works now with the patch). This way a final user sees the exposed filter if the editor allows it.

I think that this add a bit more flexibility.

I created a patch with the functionality that I explain before.

I'm sorry, but I can't build an interdiff.txt, but I'll explain my changes.

I'm not sure what do you mean? To have the exposed filters showing up in the frontend as well, rather than only available to editors?

When the editor is editing the views reference field, in the options area, get a "Show exposed filters" checkbox with FALSE by default:

$form_field['#tree'] = TRUE;
    $form_field['vr_exposed_filters_visible'] = [
      '#type' => 'checkbox',
      '#title' => $this->t('Show exposed filters'),
      '#default_value' => (isset($current_values['vr_exposed_filters_visible']) && $current_values['vr_exposed_filters_visible']),
    ];

    // Some plugin may look into current exposed input to change some behaviour,

This configuration will be saved with the configurations of the filter.

In #38:

This line of code causes an issue when the site-builder changes filters identifiers to anything other than the default one.

I get this problem too. I see your referenced code, but I think that it's no applicable directly. I created an alias list configuration to get the right filter ID later:

if (isset($form_field[$info['value']])) {
              // @todo: We need to verify when views use the alias or the ID,
              // I need sometimes the ID how key and others the alias.
              $vrExposedFiltersAlias[$id] = $info['value'];
              $vrExposedFiltersAlias[$info['value']] = $id;
              // Method buildExposedForm() gets rid of element titles, unless

}
    // Set filters alias paths.
    $form_field['vr_exposed_filters_alias'] = [
      '#type' => 'hidden',
      '#default_value' => serialize($vrExposedFiltersAlias),
    ];
  }

Then, while we preload the filters I use that alias list to get the right ID:

if (!empty($value) && isset($view_filters[$vrExposedFiltersAlias[$index]])) {

The complete method code:

/**
   * {@inheritdoc}
   */
  public function alterView(ViewExecutable $view, $values) {
    // Get exposed filter visibility, and remove configuration.
    $vrExposedFiltersVisible = FALSE;
    if (isset($values['vr_exposed_filters_visible'])) {
      $vrExposedFiltersVisible = $values['vr_exposed_filters_visible'];
      unset($values['vr_exposed_filters_visible']);
    }
    // Get exposed filters alias and names, and remove.
    $vrExposedFiltersAlias = [];
    if (isset($values['vr_exposed_filters_alias'])) {
      $vrExposedFiltersAlias = unserialize($values['vr_exposed_filters_alias']);
      unset($values['vr_exposed_filters_alias']);
    }
    // Populate default filter's value.
    if (!empty($values) && is_array($values)) {
      $view_filters = $view->display_handler->getOption('filters');
      $filters = [];
      foreach ($values as $index => $value) {
        if (!empty($value) && isset($view_filters[$vrExposedFiltersAlias[$index]])) {
          $filters[$index] = $value;
        }
      }
      if ($filters) {
        $view->setExposedInput($filters);
      }
    }

    if (!$vrExposedFiltersVisible) {
      // Force exposed filters form to not display when rendering the view.
      $view->display_handler->setOption('exposed_block', TRUE);
    }
  }

How you can see, I remove my custom configurations before all, to not modify your logic.

I hope this patch help.

Do i understand this correctly? This exposed filters will only apear in nodes and not if you place a block(that uses viewsreference field) using the layout manager?

We are using this how a block in a panopoly layout :_ D

Works like any other field type. You can see this functionality if you enable "Exposed Filters - editor view" in the field edit form.

Ah yes, you are right. Thank you.
If i now edit the block in the block ui i can set the values.
If i edit the block using the Layout-Manager (pen symbol, then edit) the fields do NOT show up. Sholdnt they?
Btw if i "add a new custom" block through the layoutmanagers right sidebar(blocklist) then the fields will show up but only half of them.

I exposed the content type and published status here.

Create block from layout manager: http://www.root.artwaves.de/sharex/05-03-20--15-36-16.jpg
Create Block from block admin ui(/block/6?destination=/admin/structure/block/block-content): http://www.root.artwaves.de/sharex/05-03-20--15-37-09.jpg

Btw. This functionality is extremely useful! Especially if you like add a lot of blocks that like show last 5 pages, articles, gallerys etc using views. Otherwise you have to replicate a gazillion of blocks in views.

testing patch #43

The patch is to the option in this image:

Yes i understand, that is in the field options for "exposing" it as a form inside the block edit form. I can see that exposed filter then if i edit a block in the block ui. Do you see that option in the block if you add a block using the layout manager?

layout manager is layout builder? I used this only with panopoly, and I see the options when I add a new block to the layout: I select a view, then a display, and in the options fieldset I see the exposed filters.

I know Panopoly, i like it. As Panopoly uses panels i tried that with a panel page. Here it shows the exposed filters! Meaning clicking the "pencil icon" will show that exposed filter.

Yes i meant the layout-builder. Here when you click the edit pencil there is none of the filers avaliable.

Layout-Builder looks like this: http://www.root.artwaves.de/sharex/05-03-20--18-36-59.jpg
Panels looks like this: http://www.root.artwaves.de/sharex/05-03-20--18-39-45.jpg

BUT in panels the selection(in my case the content type i select) will not be saved and i also get an error "An illegal choice has been detected. Please contact the site administrator."

The error log says

Type form
Date Thursday, March 5, 2020 - 17:39
User admin
Location http://dev.demo5.com/admin/panels_ipe/variant/page_manager/testpanel-pan...
Referrer http://dev.demo5.com/testpanel
Message Illegal choice in status element.
Severity Error
Hostname 127.0.0.1
Operations

I found that when the filters are visible, they don't allow change the selected option.

I updated ViewsReferenceExposedFilters::alterView to set the preference to user selection over editor defaults.

foreach ($values as $index => $value) {
        // User selection must have preference.
        if ($selected = $view->getRequest()->get($index)) {
          $filters[$index] = $selected;
        }
        // Else set the editor preference.
        elseif (!empty($value) && isset($view_filters[$vrExposedFiltersAlias[$index]])) {
          $filters[$index] = $value;
        }
      }

Ok i applied it and took a look at the code with a debugger. The conditions are never met. I triggered this by editing the block on the panel page using the pencil icon.

Debugger: http://www.root.artwaves.de/sharex/06-03-20--19-43-48.jpg

As you can see the $values is empty so the conition is never met. Used the same field as in the screenshots i used in this issue. Exposed the contenttype.

I found another issue. When i edit the fieldsettinsg inside the block like here: /admin/structure/block/block-content/manage/customblocka/fields/block_content.customblocka.field_view_ref

And select something like this: http://www.root.artwaves.de/sharex/06-03-20--19-51-09.jpg
and hit save. Nothing will be saved at all. Edit again, nothing saved.

Some more Info.
It seems $enabled_settings never contains the settings selected. In my case it always only has one value 'exposed_filters'. Doesnt matter if i select multiple exposed filters. Because of this values are never saved.
Debugger: http://www.root.artwaves.de/sharex/07-03-20--20-48-32.jpg

Also completely uninstalled the module and reinstalled. Settinsg not beeing saved. All above leads to the settings not beeing saved by the code. But i am not firm enough with the api here to patch this. I hope the analysis helps.

Confirming this again. I selected all checkboxes avaliable.
Pagination and results, Items per page are saved. The custom exposed filters are not beeing saved and i can not find the code that is supposed to do that.
I dont get how that works with panopoly. Did yoz patch the 2.x version of viewsreference?
Also tested #15 same. Exposed filter setting not beeing saved.
I use Drupal 8.8.3 and newest panels 8.x-4.4

I mean that the editor should decide if he set the settings to a default value in exposed filters or if he wants to fix the filter to the values that he selects (how works now with the patch). This way a final user sees the exposed filter if the editor allows it.

I think that this add a bit more flexibility.

Yeah, I got what you mean. What I'm trying to say is this patch is already complex per-se, and it's specifically targeting Editors. No users.
By extending the functionality we increase the complexity and open to new problems, without actually fixing existing one.

I suggest we start back from #37 and we address the current issues (thanks for tackling already some).
@psf_ I believe you can achieve exactly the same by using this patch locally and creating your own plugin extending ViewsReferenceExposedFilters ?

Again: these are just my thoughts. This is a nice-to-have functionality, but if we add complexity at this point we will never see it committed.
Let's get the core of this feature stable, committing and then we can talk about extending it.

Same for patch #37
Add a block to a panels page and the content type(exposed views filter) is never saved at all.
http://www.root.artwaves.de/sharex/18-03-20--20-47-40.jpg

I can debug this if i get any hints. I have phpstorm and xdebug running but could not figure it out by now.

I would have to agree with gambry in #53. The reason we created the plugin based approach in the first place was to prevent adding a lot of complexity and maintenance burden to the base module. Exposed filters were never added to the module because exposed filters are pretty complex compared to the other settings. Some of the things seen in this thread alone:

• Which filters should be show or not.
• What are default values for the filters.
• Prevent some filters from showing up in some cases.

I'm slowly starting to think someone who is willing to maintain this should create a separate module for the plugin. In the viewsreference module we should make sure we add all the changes the plugin needs. Other complex features would also benefit from improving the API for the plugins. Is there anyone that would be willing to maintain the plugin?