Problem/Motivation

There is no easy way to alter the view before render from the entity browser. While there are various view alter hooks, they do not have the contextual information from the entity browser.

Proposed resolution

Add an alter hook to alter the view executable before rendering the view within /src/Plugin/EntityBrowser/Widget/View.php.

Remaining tasks

- Review
- Changes?
- Add test

User interface changes

- None

API changes

- adds optional alter hook (api information to entity_browser.api.php)

Data model changes

- None

CommentFileSizeAuthor
#8 entity-browser-view-args-3038854-8.patch8.42 KBedysmp
#8 interdiff-7-8.txt834 bytesedysmp
#7 entity-browser-view-args-3038854-7.patch7.61 KBedysmp
#7 interdiff-2-7.txt5.43 KBedysmp
#2 entity-browser-view-args-3038854-2.patch6.32 KBoknate

Issue fork entity_browser-3038854

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

oknate created an issue. See original summary.

oknate’s picture

oknate
Location Greater New York City Area
commented
Issue summary: View changes
StatusFileSize
new entity-browser-view-args-3038854-2.patch6.32 KB

Moving this here from comment #47 on #2790951: Provide for contextual filter argument option on field widget

oknate’s picture

oknate
Location Greater New York City Area
commented
Status: Active » Needs review
oknate’s picture

oknate
Location Greater New York City Area
commented
Related issues: +#3038754: [META] Views Contextual Filtering Improvements
oknate’s picture

oknate
Location Greater New York City Area
commented
Status: Needs review » Needs work

while changes to the $view->arg are persistent from the hook,
changes to filters are not. When you start to interact with the exposed filters, the changes disappear.

I was able to get changes to existing type filter to work using patch #33 on #2865928: Provide method for views widget to filter based on context and the following code:

/**
 * Implements hook_views_pre_build().
 */
function mymodule_views_pre_build(ViewExecutable $view) {

  $current_request = \Drupal::requestStack()->getCurrentRequest();

  if ($current_request->query->has('uuid')) {
    $uuid = $current_request->query->get('uuid');
    if ($storage = \Drupal::service('entity_browser.selection_storage')->get($uuid)) {
      if (isset($storage['widget_context']) && !empty($storage['widget_context']['target_bundles'])) {
        if (!empty($view->filter['type'])) {
          $view->filter['type']->value = $storage['widget_context']['target_bundles'];

        }
      }
    }
  }
}

So I think what I'm trying to do is still possible, but maybe should be moved out of the View widget.

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented

OK Nate, nice to meet you here! In fact i have done similar custom things when i wanted to inherit a node's group to media (and alter the views filter). I see you did similar original_path guessing.

Hopefully soon we'll migrate to OG and i'll re-do this then with more knowledge. I think this approach to alter the view makes sense.
I think passing the context we can do better though. The entity browser maintains a persistent storage.

What if when we in \Drupal\entity_browser\Plugin\Field\FieldWidget\EntityReferenceBrowserWidget::getPersistentData or \Drupal\entity_browser\DisplayBase::displayEntityBrowser simply add $form_state to persistent data, then we can access all form values, the form, the entity, and more in the alter context.

(Bigger story: This is all about a cross-request equivalent of form_state, which is an issue for bojanz' IEF-2.x too.)

edysmp’s picture

edysmp
Primary language Spanish
Location Nicaragua
commented
StatusFileSize
new interdiff-2-7.txt5.43 KB
new entity-browser-view-args-3038854-7.patch7.61 KB

Hi guys! Thanks for working on this.
I needed upcasted parameters on my project for dynamic paramater type checking.
e.g:

    $entities = array_filter(iterator_to_array($original_route_match->getParameters()), static function ($parameter) {
      return $parameter instanceof ContentEntityInterface;
    });

I'm attaching a patch to support it. Code taked from:
https://git.drupalcode.org/project/drupal/-/blob/9.2.x/core/lib/Drupal/C...

edysmp’s picture

edysmp
Primary language Spanish
Location Nicaragua
commented
Status: Needs work » Needs review
StatusFileSize
new interdiff-7-8.txt834 bytes
new entity-browser-view-args-3038854-8.patch8.42 KB

Implemented the same logic for support when the Entity Browser is used as an embed button on the WYSIWYG editor wich works only with the iFrame display.

Status: Needs review » Needs work

The last submitted patch, 8: entity-browser-view-args-3038854-8.patch, failed testing. View results

heddn made their first commit to this issue’s fork.

heddn opened merge request !42

heddn’s picture

heddn
Primary language English
Location Illinois
commented
Status: Needs work » Needs review

Rebased patch into an MR.

heddn’s picture

heddn
Primary language English
Location Illinois
commented

Tests are mostly passing now on the MR. At least the same tests that aren't failing on HEAD are now passing. Hiding patches.

pfrenssen made their first commit to this issue’s fork.

pfrenssen’s picture

pfrenssen
Location Sofia
commented
Status: Needs review » Reviewed & tested by the community

This is looking good to me. I tried it out and it works brilliantly. The context data provided is very complete and helpful. One gotcha was that the Views display is not retained, so switching to another display cannot be done in the normal way (by calling ViewsExecutable::setDisplay('my_display')).

This is not a problem in practice since the widget configuration is also passed by reference in the alter hook, so it can be done by setting $configuration['view_display'] = 'my_display'.

anybody made their first commit to this issue’s fork.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Some very clever people involved here, all comments resolved. So let's merge this in finally.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Status: Reviewed & tested by the community » Fixed

  • anybody committed 2ec25804 on 8.x-2.x authored by heddn 
    Issue #3038854 by heddn, edysmp, pfrenssen, oknate, anybody, geek-merlin...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.