Problem/Motivation

Right now EntityReferenceItem hardcodes dependencies from the DefaultSelection selection handler. Concretely, is using the DefaultSelection handler target_bundles to build a list of dependencies, regardless of what effective handler is used by that field. But there are other selection handlers not extending DefaultSelection, like ViewsSelection (or even custom selection handlers) that have no target_bundles setting (that belongs only to DefaultSelection). Those selection handlers are exposing other settings that are creating dependencies. Such dependencies are ignored when EntityReferenceItem calculates the field configuration dependencies. For example an entity reference field that uses a ViewsSelection selection handler should depend on the view that is configured in the field configuration. But right now in HEAD is not adding that view as dependency.

Proposed resolution

  1. Allow EntityReferenceItem to ask their selection handler plugin for dependencies when they calculate the field dependencies.
  2. Move the DefaultSelection specific dependencies from EntityReferenceItem into DefaultSelection.
  3. Introduce a new interface DependencyRemovalPluginInterface having an onDependencyRemoval() method.
  4. Make SelectionPluginBase implement also DependencyRemovalPluginInterface interface.
  5. Implement a generic onDependencyRemoval() that only returns FALSE in SelectionPluginBase.
  6. Create PluginRemovedDependencyTrait and move EntityDisplayBase::getPluginRemovedDependencies() there. This can be reused now in other similar cases.
  7. Implement calculateDependencies() in ViewsSelection.
  8. In EntityReferenceItem set the selection handler to broken when the dependency is deleted and cannot be resolved.

Remaining tasks

None.

User interface changes

None.

API changes

  1. New interface DependencyRemovalPluginInterface having an onDependencyRemoval() method.
  2. SelectionPluginBase implements now also DependencyRemovalPluginInterface interface.
  3. New trait PluginRemovedDependencyTrait.

Data model changes

None.

Comments

claudiu.cristea created an issue. See original summary.

claudiu.cristea’s picture

Status: Active » Needs review
FileSize
36.17 KB
claudiu.cristea’s picture

Version: 8.3.x-dev » 8.2.x-dev
Issue summary: View changes
claudiu.cristea’s picture

Issue summary: View changes
claudiu.cristea’s picture

Issue summary: View changes

Status: Needs review » Needs work

The last submitted patch, 2: 2786841-2.patch, failed testing.

The last submitted patch, 2: 2786841-2.patch, failed testing.

claudiu.cristea’s picture

Status: Needs work » Needs review
FileSize
7.09 KB
37.53 KB

Fixed.

claudiu.cristea’s picture

FileSize
1.51 KB
37.53 KB

Nits.

Status: Needs review » Needs work

The last submitted patch, 9: 2786841-9.patch, failed testing.

claudiu.cristea’s picture

Status: Needs work » Needs review

Test from #9 passed.

claudiu.cristea’s picture

Issue summary: View changes
claudiu.cristea’s picture

amateescu’s picture

claudiu.cristea’s picture

@amateescu, thank you for pointing me to that. However, this issue seems a little bit different in terms of proposed solution. Here we're not only adding missed dependencies but we are introducing a mechanism that asks the plugin to provide its dependencies and we're also let the plugin react on dependency removal. If this issue gets committed, the other one becomes obsolete. For this reason and also because here we have a better, detailed IS I would prefer to keep this alive while marking the other as duplicate.

If you feel I'm wrong, please re-activate the other.

Updated also the IS after opened #2787873: Add a base class for entity reference selection handlers and fix the structure of their configuration.

jibran’s picture

Title: Entity reference fields should ask their selection handler plugin for dependencies » Entity reference fields should add selection handler config dependencies

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.