Problem/Motivation

Sorry for the probably dumb question Scott, but after reading through the issues and code and seeing #3347343: Add Views EntityReference filter to support better UX for exposed filters I'm not totally sure if this module already supports base fields?

As written in the related documentation issue, my concrete case is from Drupal Commerce Product Variations:

    // The product backreference, populated by Product::postSave().
    $fields['product_id'] = BaseFieldDefinition::create('entity_reference')
      ->setLabel(t('Product'))
      ->setDescription(t('The parent product.'))
      ->setSetting('target_type', 'commerce_product')
      ->setReadOnly(TRUE)
      ->setDisplayConfigurable('view', TRUE);

With this module and the patch the filter still doesn't change.
Maybe the (non-)support for base fields should also be documented on the project page?

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork views_core_entity_reference-3481422

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

anybody created an issue. See original summary.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented
Issue summary: View changes
anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Or is this a very special case that needs custom implementation in Drupal Commerce?

scott_euser’s picture

scott_euser commented

At the moment its just finding field configs: https://git.drupalcode.org/project/views_core_entity_reference/-/blob/1....

But if you could add some way to load up the various entity types available in a site, check their definitions for entity reference fields, similar auto-opting in could be made for base fields that are entity references.

scott_euser’s picture

scott_euser commented

Just to note base fields can be a bit more dangerous as its possible Core has replaced some base field filter handlers (e.g. language) with purpose-built filter handlers. So it may be that you'd want to opt-in to specific fields (see example on module homepage) rather than a blanket opt-in of base fields.

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

psf_’s picture

psf_ commented
Assigned: Unassigned » psf_

Hi, I will try to add base fields support. : )

psf_ opened merge request !10

psf_’s picture

psf_ commented

I have it working in D10.4.3 : )

psf_’s picture

psf_ commented
Assigned: psf_ » Unassigned
Status: Active » Needs work

I think that only need tests.

psf_’s picture

psf_ commented

Hi, I tried my patch in D11.1, and it didn't work. I see that the field data is in the <entity>_field_data table, but in D10.4, it is in the <entity> table.

Is it accurate?