Steps to reproduce:

There's many ways to reveal this bug. For example a view of nodes related to paragraphs, or a view of paragraphs related to the parent entity like so:

  • Set up a node with a paragraph field (field_x) and a paragraph in it with some content.
  • Create a view page that displays paragraphs.
  • Add a relationship on "Content using field_x", set it to required.
  • View the page for the view, observe that it has no entries.

The paragraph should appear on the view page since it is referenced by "Content using field_x". You can set up something similar with 2 different node types and a regular entity reference field and see that it does display the referenced entity.

There's probably many other combinations of view of X related to Y that will reveal this bug.

Remaining tasks

  • Write a hook_update_N() to migrate views' relationships (and fields/filters/sorts/arguments that use those relationships) to the new format. see #124 for details
  • There's some reports of broken filters due to this patch. #151
  • There's some reports of old revisions showing in views due to this patch.
  • There's some reports of missing paragraphs in views for a multi-value ERR Paragraphs field due to this patch.
  • There's some reports of duplicate rows when having a delta field due to this patch. #134 and others
  • There's some reports of "Content revision: Is Latest Revision" filter causes an error that "Base table or view not found" due to this patch #111
  • This patch causes some UX confusion because there's now multiple ways to connect a paragraph to its parent entity in Views. #151
  • ...Could be more bugs, I only read back the last year's worth of comments on this issue...

How to apply patches

If you need to know how to use a patch, please take a look at
please don't muddy this issue with questions about how to apply a patch.

#158 interdiff_155_158.txt2.59 KBnikita_tt
#158 entity_reference_2799479-158-no-tests.patch17.51 KBnikita_tt
#155 entity_reference_2799479-155-no-tests.patch17.2 KBadinac
#151 Screen Shot 2021-01-06 at 10.38.18 PM.png135.05 KBdalin
#146 interdiff.2799479.103-146.txt1.43 KBsuper_romeo
#146 2799479-146.entity_reference_revisions.Views-doesnt-recognize-relationship-to-host.patch30.12 KBsuper_romeo
#113 2799479-108-no-tests.patch17.18 KBmarcaddeo
#108 2799479.90_108.rawdiff.txt514 bytesdww
#108 2799479-108.patch30.12 KBdww
#99 2799479-99.patch30.26 KByechaozheng
#98 2799479-98.patch30.13 KByechaozheng
#91 2799479-91-DO_NOT_COMMIT.patch29.52 KBeiriksm
#90 2799479-90.patch30.17 KBeiriksm
#65 2799479-65-views-rel-fix.patch30.19 KBdiamondsea
#55 2799479-55-views-rel-fix.patch31.19 KBidebr
#55 2799479-55-test-only.patch12.98 KBidebr
#55 interdiff-52-55.txt2.29 KBidebr
#52 2799479-52-views-rel-fix.patch30.11 KBidebr
#52 2799479-52-test-only.patch11.9 KBidebr
#52 interdiff-34-52.txt22.32 KBidebr
#34 2799479-21-34-views-rel-fix--interdiff.txt6.89 KBvasike
#34 2799479-34-views-rel-fix.patch16.88 KBvasike
#21 2799479-21-views-rel-fix.patch10.35 KBtacituseu
#20 2799479-20-views-rel-fix.patch10.44 KBtacituseu
#17 core-views-reverse-revisioned-relationship-do-not-test.patch752 bytestacituseu
#17 2799479-17-views-rel-fix.patch6.82 KBtacituseu
#16 2799479-16-views-rel-fix.patch6.78 KBtacituseu
#13 2799479-13-views-rel-fix.patch6.7 KBtacituseu
#8 2799479-8-relationship-host-id.patch878 bytesstmh
#2 2799479-1-relationship-host-id.patch745 bytesHydra
Support from Acquia helps fund testing for Drupal Acquia logo


jmuzz created an issue. See original summary.

Hydra’s picture

Status: Active » Needs review
745 bytes

I think I ran into the same issue - except that I had an entry from the relationship, wich was false so I could track down the problem. The problem is, that the relationship checks the vid vs the entity_id, which will break as soon as you use revisions.

Attached patch uses the right base field to do the check.

dawehner’s picture

+++ b/
@@ -55,7 +55,7 @@ function entity_reference_revisions_field_views_data(FieldStorageConfigInterface
       'base' => $entity_type->getDataTable() ?: $entity_type->getBaseTable(),

As we see here, this particular join joins to the data/base table of an entity. Given that the right key to join is the entity ID. On top of that there is the valid feature request to provide a join from the dedicated revision field tables to the revision data table, but that's a different battle to fight.

Ideally we would have tests here which actually work properly.

miro_dietiker’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

Ideally we would have tests here

Yes and no:

I rarely commit bugfixes without tests. You need a very solid excuse for that. So are we living in an almost ideal world? ;-)

dawehner’s picture

Fair point :)

dawehner’s picture

To continue though, I doubt we can know in which world we are living in .

Hydra’s picture

+++ b/
@@ -55,7 +55,7 @@ function entity_reference_revisions_field_views_data(FieldStorageConfigInterface
       'field field' => $field_name . '_target_revision_id',

Looks like this needs to be $field_name . '_target_id', too then :/ The view stops working when the revision id no longer ist the same as the id itself.

stmh’s picture


attached is a new patch combining #2 and #7 into one. This fixed a similar problem on our end.

D34dMan’s picture

The patch in #8 makes it behave like normal "entity_reference" field. Means revision specific referencing will not be available if we apply that. Thus defeating the purpose of using "Entity Reference Revisions" field in the first place.

Having said that, it is common requirement that we might need the latest revision only, where a behaviour like normal "entity_reference" is expected. So I suppose we expose two reverse reference field,

1. A reverse reference that behave like normal refrence field
2. A reverse reference that acts on revisions

At the moment, it looks like the reverse reference field doesn't behave like either. That is, we can't load a reference content at all.


ABaier’s picture

#8 solved it for me temporarily. Hopefully this could be fixed. I was scratching my head why some paragraphs did not show up. So, it was because I deleted them from a node and added some new ones. Without a required relationship to the host all the revisions were shown, even those which were deleted.

Seems to be kind of similar to this issue:

jpoesen’s picture

Confirming that the patch in #8 did the job for me.

My scenario: a view (block display) of paragraphs showing titles for a given node, to render alongside a node.
Created a required relationship to the paragraph reference field and a contextual filter to Paragraph: Parent ID

Before the patch, all paragraph titles were shown, even the ones of paragraphs that had been removed from the node.
After the patch only the paragraph titles of the remaining paragraphs are shown -- for me this was the expected behaviour all along.

ABaier’s picture

This problem does still exist in 8.x-1.2. Any news on this?

Thanks in advance!

tacituseu’s picture

Status: Needs work » Needs review
6.7 KB

@D34dMan: attached pretty much what you described.

My use case is a view with some of the fields from referenced parent showing values at the time the reference was created, and some from latest revision.

Sorry for no tests :), attaching here instead of new issue with feature request because #8 isn't a proper solution, and it looks like there is an interest for it here.

I can't spend too much time on it right now, so feel free to improve.

tacituseu’s picture

Status: Needs review » Needs work

Reverse relationship needs some work.

D34dMan’s picture

@tacituseu, thanks for pushing this, will do testing during weekends. busy schedule :(

tacituseu’s picture

tacituseu’s picture

Looks like it all boils down to hardcoded 'entity_id' in Drupal\views\Plugin\views\relationship\EntityReverse::query(), unfortunately couldn't find a way around it, so core patch attached (patch is green on 8.4.x, see results here

Leaving at needs work as it needs a look from someone more familiar with views, not sure if I'm not abusing 'revision' definition key, couldn't find any docs about it.

Berdir’s picture

We could always subclass that and use our own plugin for our field? And if we are going to fix it in core, then it will require an actual issue.

I'll try to have a closer look at this soon.

tacituseu’s picture

@Berdir: yes, subclassing looks perfectly doable.

tacituseu’s picture

Here it is, went with the 'entity_reference_revisions' as id and EntityReferenceRevisions as class to stay consistent with other ERR views plugins.
Extended from Drupal\views\Plugin\views\relationship\RelationshipPluginBase because Drupal\views\Plugin\views\relationship\EntityReverse is pretty much only overriding the same method.

tacituseu’s picture

Might as well leave 'revision' alone.

Note to potential testers: it changes id's of the relationship fields so it will "Broken/missing handler" existing relationships and fields relying on them.

D34dMan’s picture

I have tested it by apply patch and creating a new view. I am able to add two new relationship types now. Namely "Entity_XXX referenced from Entity_YYY" and "Entity_XXX revisions referenced from Entity_YYY". I have checked by trying to display revision id and it works. Good job.

drikc’s picture

Thank you, could successfully do a relationship to content entity from a paragraph view.

John Pitcairn’s picture

The patch at #21:

  • Applies successfully to 8.x-1.2 or 8.x-dev
  • Allows me to follow the relationship chain upwards from a media entity via 2 nested paragraphs to the parent content node.


The category labelling when I get to field selection on the content node is possibly a little obscure. It's not clear what the difference is between "Content (historical data)" and "Content revision".

John Pitcairn’s picture

Um ... hang on ... does this break relationships to relationships? I have a (now broken) view that uses a custom menu link > content >paragraph > paragraph > field relationship chain. That gets broken handlers with this patch (expected), but there doesn't now seem to be any way when adding a new ERR relationship to specify the relationship that it depends on. So you can't chain downward relationships?

tacituseu’s picture

@John Pitcairn: I'm not using it with paragraphs, but I do use it for chained relationships, both forward and reverse, there is a problem with current patch, this part:

  foreach ($data as $table_name => $table_data) {
    foreach (['id' => 'id', 'revision' => 'revision_id'] as $key => $column) { }

the second foreach might be redundant and just results in relationships with identical name but based on different tables
as core\modules\views\ already does:

  $table_mapping = $storage->getTableMapping();
  $field_tables = array(
    EntityStorageInterface::FIELD_LOAD_CURRENT => array(
      'table' => $table_mapping->getDedicatedDataTableName($field_storage),
      'alias' => "{$entity_type_id}__{$field_name}",
  if ($supports_revisions) {
    $field_tables[EntityStorageInterface::FIELD_LOAD_REVISION] = array(
      'table' => $table_mapping->getDedicatedRevisionTableName($field_storage),
      'alias' => "{$entity_type_id}_revision__{$field_name}",

So it could be that you picked the wrong combination, or there is something about paragraphs that isn't taken into account, will look more into it and the interaction with custom ContentEntity in a week or two.

Found the group/category confusing too, "Content (historical data)" comes from core, so not likely to change, and changing ERR to start using it instead of "Content revision" might be even more confusing, 'group' label definition should vary too if it is a revision and doesn't in current patch.

John Pitcairn’s picture

So it could be that you picked the wrong combination

Yes, I had to re-create the relationship/field chain and missed one of the initial relationships. The handler is working as expected.

John Pitcairn’s picture

the second foreach might be redundant and just results in relationships with identical name but based on different tables

I'm not familiar enough with the code but I do note that there are 2 very similar relationships available: I think one is a relationship to (or from) the entity without revision, while the other is a relationship to (or from) the specifically referenced revision?

If so, they are both useful. For example for my admins I might have a "media usage" view that displays media used only in current revisions of content, with another embedded view with aggregation that counts usage in any revision of each content item. Both relationships would be required to do that.

imclean’s picture

Thanks. The patch in #21 applies cleanly to dev and allows displaying fields from the referenced paragraph's host entity. I haven't tried anything more complex yet.

John Pitcairn’s picture

Patch no longer applies to latest dev.

tacituseu’s picture

$ git clone --branch 8.x-1.x
$ git apply -v /b/2799479-21-views-rel-fix.patch
Checking patch
Checking patch src/Plugin/views/relationship/EntityReferenceRevisions.php...
Applied patch cleanly.
Applied patch src/Plugin/views/relationship/EntityReferenceRevisions.php cleanly.
tacituseu’s picture

Status: Needs work » Needs review

Triggering tests to check.

vasike’s picture

Status: Needs work » Needs review
16.88 KB
6.89 KB

It seems something still missing: relationship for Base fields

Ex: Drupal commerce uses this field as basefields for Billing profile
issue: #2819603: Can't add a views relationship to the billing profile

And here is an updated patch that includes the base fields (single and multiple valued)
Diff included.

Still needs tests - (Needs review temporary)

John Pitcairn’s picture

Hmm ... I'm patching via composer and cweagans/composer-patches and that was failing. I'll take another look. Thanks @tacituseu.

tacituseu’s picture

@vasike: Thanks for base fields integration, will take a closer look soon.

Also, for those having Error "Column 'langcode' in field list is ambiguous" thrown in TranslationLanguageRenderer with this patch, see #2896381-30: "TranslationLanguageRenderer" uses the wrong table for the "langcode" column with entity revision views.

tacituseu’s picture

stevieb’s picture

the patch in #34 worked for me ...

s427’s picture

Patch #34 works for me too, as far as I can tell.

Coufu’s picture

Patch #34 wins

miro_dietiker’s picture

Status: Needs review » Needs work

Sorry, this is simply too much code for a blind commit. Supporting comments won't help here: We need tests.

cbrasfield’s picture

Trying out #34 with views REST and I'm not sure the field names are friendly (field_image-revision_id, field_image-revision_id_1). Don't know if there's anything that can be done with that.

maxplus’s picture

jantoine’s picture

I've run into an issue where a reference to a parent node from a paragraph is successful but a reference to a grandparent node from the parent node still has the same issue as the original.

tisteegz’s picture

#34 worked for me also.

lamp5’s picture

#34 works perfect! Thanks

csedax90’s picture

#34 is working fine

tacituseu’s picture

nicobot’s picture

#34 Works great for me! Thanks!

idebr’s picture

- Added a test that checks a View result set for a node title based on a relationship from the entity_test_composite entity. This should fix #41
- Fixed Code sniffer warnings in the patch

The last submitted patch, 52: 2799479-52-test-only.patch, failed testing. View results

miro_dietiker’s picture

As we had issues with revision duplication and joining on the proper field, we should write multiple revisions on the Paragraph and the host entity and check that there are no duplicate result rows.

idebr’s picture

#54 Added revisions to the composite and host entity. Added assertion for a single result with the updated data.

The last submitted patch, 55: 2799479-55-test-only.patch, failed testing. View results

miro_dietiker’s picture

Quickly reviewing the code a bit, not tested yet.

  1. +++ b/
    @@ -5,68 +5,216 @@
    +use Drupal\Core\Entity\FieldableEntityInterface;
    +      foreach (['id' => 'id', 'revision' => 'revision_id'] as $key => $column) {
    +    foreach (['id' => 'id', 'revision' => 'revision_id'] as $key => $column) {

    I count below 8 $key inline conditions and twice a 6 row if base on $key. It makes me feel like we should maybe simply cover these two cases one after the other?

    Hm... Same above... Not sure what's better. What do you think?

  2. +++ b/
    @@ -5,68 +5,216 @@
    +        if ($field->getCardinality() == 1) {

    Needs special test coverage for cardinality 1.

  3. +++ b/
    @@ -5,68 +5,216 @@
    +      if ($key == 'id' || !$target_entity_type->isRevisionable()) {
    +      if ($key == 'id' || !$entity_type->isRevisionable()) {

    Are we really supporting an ERR to a target entity type that is not revisionable? What's the purpose of an ERR then?

    And yeah, didn't recently think about the case where the host entity type may not be revisionable.
    That would need a test case as well..

  4. +++ b/tests/modules/entity_composite_relationship_test/config/install/views.view.composite_entities.yml
    @@ -0,0 +1,249 @@
    +          required: false
    +          required: false

    I would guess that without putting these relations as required, if you delete the host entity, you still have ghost results without host?

miro_dietiker’s picture

Identified a Views use case: Sometimes i like to see a count of Paragraphs per node in a view. And when i work with unpublished Paragraphs to hide incomplete items, i would like to see a dedicated unpublished Paragraphs counter. Both numbers though need recursion in the current situation or would only count the top level items.

Should we create a parent meta issue to identify and discuss views use cases?

scott.whittaker’s picture

It's almost like Entity Reference should be linking content Relationship entities rather than directly referencing entities. That way you could have different Relationship types where you could configure the desired behaviour for cascaded deletes and so on.

miro_dietiker’s picture

@scott.whittaker There are multiple issues about garbage collection and it's a hard problem. It's on our #2954487: New Roadmap as one of our top priorities.

Berdir’s picture

> And yeah, didn't recently think about the case where the host entity type may not be revisionable. That would need a test case as well..

We don't allow to create that in the UI: \Drupal\entity_reference_revisions\Plugin\Field\FieldType\EntityReferenceRevisionsItem::storageSettingsForm()

Probably not strictly validated somewhere, so you could theoretically work around it, but not sure it's even worth to add more checks and obviously also can't be tested then.

charginghawk’s picture

Having trouble applying the #55 patch through composer. May be a versioning issue (I'm using Paragraphs which uses entity_reference_revisions 1.3). #34 applies, so using that for now.

hgupta28’s picture

Tested #55, working as expected.

miro_dietiker’s picture

Status: Needs review » Needs work

At least we want to have separate test coverage for cardinality 1.

diamondsea’s picture

Updated #55 to patch format (removed headers) so it can be used with Composer.

el1_1el’s picture

As mentioned in comment #21, patches break all existing err/paragraph relationships so hopefully a dbup is included if committed

pfrenssen’s picture

I think the patch is hard to read because of the heavy use of ternary operators in it. Example:

+        $data[$target_table][$pseudo_field_name]['relationship'] = [
+          'title' => $key == 'id' ? t('@entity using @field_name', $args) : t('@entity revision using @field_name', $args),
+          'label' => $key == 'id' ? t('@field_name', ['@field_name' => $field_name]) : t('@field_name revision', ['@field_name' => $field_name]),
+          'group' => $target_entity_type->getLabel(),
+          'help' => $key == 'id' ? t('Relate each @entity with a @field_name set to the @label.', $args) : t('Relate each @entity revision with a @field_name set to the @label.', $args),
+          'base' => $base_table,
+        ] + $field_data;

If this was rewritten to handle the base relation first, and the revisions second, then there would be a little bit of code duplication, but much easier to read. It would also be more consistent with the rest of the file which prefers duplication over ternaries.

Jax’s picture

I agree with Pieter, that is not readable. It is the fewest possible amount of lines though.

Just writing it twice would make it more readable and adds an if and else. For such things I prefer this approach:

$settings = [
  'id' => [
    'title' => t('@entity using @field_name', $args),
    'label' => t('@field_name', ['@field_name' => $field_name]),
    'help' => t('Relate each @entity with a @field_name set to the @label.', $args),
  'vid' => [
    'title' => t('@entity revision using @field_name', $args),
    'label' => t('@field_name revision', ['@field_name' => $field_name]),
    'help' => t('Relate each @entity revision with a @field_name set to the @label.', $args),
$settings = $key == 'id' ? $settings['id'] : $settings['vid'];
$data[$target_table][$pseudo_field_name]['relationship'] = [
  'title' => $settings['title'],
  'label' => $settings['label'],
  'group' => $target_entity_type->getLabel(),
  'help' => $settings['help'],
  'base' => $base_table,
] + field_data;
miro_dietiker’s picture

I really do not care about "fewest possible amount of lines". Readability and simplicity of code first.

So let's convert this please to a straight forward non-ternary-overloaded version.

sjancich’s picture

#65 doesn't apply for me via Composer (I'm using D8.16, and the 1.6 release of ERR).

dieuwe’s picture

Patch #65 applies with composer when using the latest dev version (but not 1.3 or 1.4, only #34 applies against those).

I don't have time to investigate, but I am seeing the following notice on a view with a paragraphs relation after applying this patch:

Notice: Undefined index: base in Drupal\views\Plugin\views\query\QueryPluginBase->getEntityTableInfo() (line 292 of core/modules/views/src/Plugin/views/query/QueryPluginBase.php).

And also getting a MySQL syntax error when using an exposed text search filter that uses the relation. Can anyone else verify?

John Pitcairn’s picture

#34 will also apply against current dev using composer.

littlepixiez’s picture

Just a note that #34 worked for me against 8.x-1.6 using composer and fixed issue for me (whether that be temporarily or not!). Had to reapply relationship. :) Thanks.

opi’s picture

#34 works for my on entity_reference_revisions 8.x-1.6, thanks !

ñull’s picture

I agree that this still needs work. I applied patch 2799479-34-views-rel-fix.patch and it does not fix the related (duplicate) issue #2941499-7: Duplicate nodes when using Views relationships. I still see duplicates when I add a paragraph relationship.

miro_dietiker’s picture

@ñull Are you multilingual?

ñull’s picture

@miro_dietiker I guess it is not relevant here that I am multilingual, but the site is not.

handkerchief’s picture

Same result for me as #74

ñull’s picture

I now installed dev version and patch #65. Still does not fix the supposedly duplicate issue #2941499-7: Duplicate nodes when using Views relationships. I keep seeing duplicates when I add a paragraph relationship.

kienan’s picture

I tried the patch from #65, and it didn't seem to do what I expected. I still encountered duplicates from views (even after replacing the relationship)

Furthermore, any views with relationships configured caused whitescreens, with errors similar to:

"No entity type for field field_custom_field_name on view view_machine_name"

These errors continued until the views were manually fixed by replacing the relationships.

aleksip’s picture

So, my understanding is that this issue means that Views integration of Paragraphs is effectively completely broken? I have tried the latest patch and it does not fix all problems (some of which have been described in other issues marked as duplicates).

This issue is currently over two years old and has 92 followers. Any chance the priority could be bumped to Critical, or at least Major?

miro_dietiker’s picture

Priority: Normal » Major

I have put this issue on the bigger Paragraphs Roadmap for more visibility a while ago.
Let's promote it to Major for now. We can only promote it to Critical if someone takes ownership over this issue and will push it forward because it is critical to him.

There are clear statements above how to improve this issue and hopefully make it ready.
We can also cover missing use cases in tests in follow-ups. But keep in mind that we will then need to update views in case we change definitions that would lead to broken handlers in existing views.

demonde’s picture

Is there any workaround?

E.g. I could print out the "Paragraph: Parent ID" as views field and use the Views field formatter project to render it. That is not a nice way but should work.

Does anybody know a better way until the issue is solved?

markdc’s picture

Could you please explain in detail your method? I'm pretty desperate at this point; I'll take the not nice way.

demonde’s picture

@fatmarker: Ok but I have not tested this yet.

You could use

( or as alternative )

an send with one of these modules the value of the views field "Paragraph: Parent ID" to another view.

It is obvious that this way is all but performant because for each row you have to render one view and it might be tricky to get good markup.

piggito’s picture

About this comment in #72

Patch #65 applies with composer when using the latest dev version (but not 1.3 or 1.4, only #34 applies against those).
+++ b/tests/modules/entity_composite_relationship_test/
@@ -5,5 +5,7 @@ package: Testing
 core: 8.x
- - entity_reference_revisions
- - entity_test
\ No newline at end of file
+ - drupal:node


\No newline at end of file

line is preventing the patches at #55 and #65from applying to release versions.
Drupal script adds an extra section to info file like

 - entity_reference_revisions
 - entity_test
# Information added by packaging script on 2018-10-15
version: '8.x-1.6'
core: '8.x'
project: 'entity_reference_revisions'
datestamp: 1539588784

then we have a line break instead of

\No newline at end of file

which invalidates the patch.

rajveergang’s picture

#8 Worked for me... Thanks

igonzalez’s picture

#8 Worked for me... Thanks

eiriksm’s picture

Status: Needs work » Needs review
30.17 KB

Reroll (the only change is getLowercaseLabel => getSingularLabel (which was the last commit on the branch, and the base for release).

eiriksm’s picture

Just uploading a patch that can be applied with composer on the stable branch. Probably fails testing, since I removed some changes to an .info.yml file that would not apply

arsn’s picture


2799479-91-DO_NOT_COMMIT.patch from #91 works for me. Many thanks!

I've finally managed to fix "Paragraphs in Views shows all revisions" thanks to explanations in #2999730#comment-12775116.

I had to update drupal to 8.7.8, paragraphs to 1.9 & entity_reference_revisions to 1.7 (their latest stable release to date), apply the patch from #2799479#comment-12620465, reconfigure the whole view, and get rid of a nasty hook_views_query_alter() which was quietly corrupting my results.

Best regards

ikit-claw’s picture

Why have you called it do not commit? It is going to get many questions when the deployment is reviewed....

smaz’s picture

Why have you called it do not commit? It is going to get many questions when the deployment is reviewed....

That patch is just one that will apply to the stable branch without errors, so people can use it now & apply it via composer without having to use the dev branch of the module. 2799479-90.patch is the one that should be being committed - the only change between the 2 is that the DO-NO-COMMIT one doesn't attempt to patch tests/modules/entity_composite_relationship_test/ as when applied to stable it results in:

patching file
patching file src/Plugin/views/relationship/EntityReferenceRevisions.php
patching file tests/modules/entity_composite_relationship_test/config/install/views.view.composite_entities.yml
patching file tests/modules/entity_composite_relationship_test/
Hunk #1 FAILED at 5.
1 out of 1 hunk FAILED -- saving rejects to file tests/modules/entity_composite_relationship_test/
patching file tests/modules/entity_composite_relationship_test/src/Entity/EntityTestCompositeRelationship.php
patching file tests/src/Kernel/EntityReferenceRevisionsViewsTest.php
ikit-claw’s picture

Thanks @smaz but 2799479-90.patch will not apply DO-NO-COMMIT does.

smaz’s picture

2799479-90.patch applies cleanly to the dev branch, where it will get committed:

$ git clone --branch 8.x-1.x
$ patch -p1 < 2799479-90.patch 
patching file
patching file src/Plugin/views/relationship/EntityReferenceRevisions.php
patching file tests/modules/entity_composite_relationship_test/config/install/views.view.composite_entities.yml
patching file tests/modules/entity_composite_relationship_test/
patching file tests/modules/entity_composite_relationship_test/src/Entity/EntityTestCompositeRelationship.php
patching file tests/src/Kernel/EntityReferenceRevisionsViewsTest.php

I'll try and get a proper review in later to help get this RTBC!

ikit-claw’s picture


yechaozheng’s picture

Please ignore this comment

yechaozheng’s picture

Cannot apply the patch 2799479-90.patch from #90 with below error. So I just correct the patch for this file patching failed (tests/modules/entity_composite_relationship_test/

patching file
patching file src/Plugin/views/relationship/EntityReferenceRevisions.php
patching file tests/modules/entity_composite_relationship_test/config/install/views.view.composite_entities.yml
patching file tests/modules/entity_composite_relationship_test/
Hunk #1 FAILED at 5.
1 out of 1 hunk FAILED -- saving rejects to file tests/modules/entity_composite_relationship_test/
patching file tests/modules/entity_composite_relationship_test/src/Entity/EntityTestCompositeRelationship.php
patching file tests/src/Kernel/EntityReferenceRevisionsViewsTest.php
DuneBL’s picture

I confirm #99 solve my issue
=>don't forget to check "Require this relationship" checkbox.

arsn’s picture

I confirm too #99 fixes the issue. Thanks

J-Lee’s picture

#99 works for me too. Thank you.
Maybe RTBC?

J-Lee’s picture

Hmm. There is an issue if you add the field delta for sorting. Then the results shows multiple times.

SQL query before setting the field delta sorting:

SELECT AS id, paragraphs_item_field_data.langcode AS paragraphs_item_field_data_langcode, field_paragraph_paragraphs_item_field_data.nid AS field_paragraph_paragraphs_item_field_data_nid
{paragraphs_item_field_data} paragraphs_item_field_data
INNER JOIN {node__field_paragraph} node__field_paragraph ON = node__field_paragraph.field_paragraph_target_id AND node__field_paragraph.deleted = '0'
INNER JOIN {node_field_data} field_paragraph_paragraphs_item_field_data ON node__field_paragraph.entity_id = field_paragraph_paragraphs_item_field_data.nid
WHERE (paragraphs_item_field_data.parent_id = '87') AND (paragraphs_item_field_data.status = '1')


LANG = paragraphs_item_field_data_langcode
NID = field_paragraph_paragraphs_item_field_data_nid
|  id | LANG | NID |
|  69 | de   |  87 |
|  73 | de   |  87 |
|  93 | de   |  87 |
| 105 | de   |  87 |
4 rows in set (0.01 sec)

After adding the field delta for sorting:

SELECT AS field_paragraph_paragraphs_item_field_data__node__field_para, AS id, paragraphs_item_field_data.langcode AS paragraphs_item_field_data_langcode, field_paragraph_paragraphs_item_field_data.nid AS field_paragraph_paragraphs_item_field_data_nid
{paragraphs_item_field_data} paragraphs_item_field_data
INNER JOIN {node__field_paragraph} node__field_paragraph ON = node__field_paragraph.field_paragraph_target_id AND node__field_paragraph.deleted = '0'
INNER JOIN {node_field_data} field_paragraph_paragraphs_item_field_data ON node__field_paragraph.entity_id = field_paragraph_paragraphs_item_field_data.nid
LEFT JOIN {node__field_paragraph} field_paragraph_paragraphs_item_field_data__node__field_paragraph ON field_paragraph_paragraphs_item_field_data.nid = field_paragraph_paragraphs_item_field_data__node__field_paragraph.entity_id AND field_paragraph_paragraphs_item_field_data__node__field_paragraph.deleted = '0'
WHERE (paragraphs_item_field_data.parent_id = '87') AND (paragraphs_item_field_data.status = '1')
ORDER BY field_paragraph_paragraphs_item_field_data__node__field_para ASC


DELTA = field_paragraph_paragraphs_item_field_data__node__field_para
LANG = paragraphs_item_field_data_langcode
NID = field_paragraph_paragraphs_item_field_data_nid
| DELTA |  id | LANG | NID |
|     0 |  69 | de   |  87 |
|     0 |  93 | de   |  87 |
|     0 |  73 | de   |  87 |
|     0 | 105 | de   |  87 |
|     1 |  73 | de   |  87 |
|     1 | 105 | de   |  87 |
|     1 |  69 | de   |  87 |
|     1 |  93 | de   |  87 |
|     2 |  73 | de   |  87 |
|     2 | 105 | de   |  87 |
|     2 |  69 | de   |  87 |
|     2 |  93 | de   |  87 |
|     3 |  73 | de   |  87 |
|     3 | 105 | de   |  87 |
|     3 |  69 | de   |  87 |
|     3 |  93 | de   |  87 |
16 rows in set (0.00 sec)
J-Lee’s picture

I've been investigating a little more....
The patch works as expected. The problem was a wrongly configured view where I had to configure the relationships before the context filters.
The delta sorting criteria are not required because the view shows the paragraphs within the right order.

katyrose’s picture

Is there a version of this patch that will work for the 8.x-1.7 branch? Tried applying the one in . and wound up with some nasty PHP errors

eiriksm’s picture

trondsenjd’s picture

Confirming #91 works for me on 1.7. Thank you @eiriksm!

dww’s picture

#90 no longer applies to 8.x-1.x branch due to conflicts from #3100140: Mark as compatible with Drupal 9, so I rerolled it. Since #90 no longer applies, interdiff isn't possible, so here's a raw diff of the 2 patch files.

dww’s picture

p.s. Thanks to the patch conflict, I noticed this bug in #90:

+++ b/tests/modules/entity_composite_relationship_test/
@@ -5,5 +5,7 @@ package: Testing
+ - drupal:entity_reference_revisions

This is wrong. entity_reference_revisions isn't (yet) part of core. ;) This needs to be entity_reference_revisions:entity_reference_revisions instead. ;) Already fixed in #108. Just calling it out here so folks know it was an intentional part of the diff between #90 and #108.


arcaic’s picture

Just adding this in case its of use to anyone...

We are experiencing this issue with views with paragraph relationships returning wrong/inconsistent results and while the patches do fix the issue, as has been noted, they break existing views which need to be rebuilt.

As we have 50+ views with multiple displays its a major effort for us to rebuild them so I came up with the following bodge as a workaround until an update mechanism for the patches is available.

For any view with a relationship of 'paragraphs_item_field_data_node__field_paragraphs' I unset it and replace it with a version that works (for me). It probably is not a universal fix for all use cases and has had limited testing by us so far (not in production yet) but is much less disruptive as a work around.

You may/will need to adjust this for your use case and please test thoroughly. Do not use in your production site.

Add the following in a custom module in the module file....

 * Implements hook_views_query_alter().
function my_module_views_query_alter(\Drupal\views\ViewExecutable $view, \Drupal\views\Plugin\views\query\QueryPluginBase $query) {

  if (!empty($query->relationships['paragraphs_item_field_data_node__field_paragraphs'])) {


    $definition = [
      'left_table' => 'node__field_paragraphs',
      'left_field' => 'field_paragraphs_target_id',
      'table'      => 'paragraphs_item_field_data',
      'field'      => 'id',
      'type'       => 'inner',

    $join = \Drupal\views\Views::pluginManager('join')->createInstance('standard', $definition);

    $query->addRelationship('paragraphs_item_field_data_node__field_paragraphs', $join, 'paragraphs_item_field_data');

If anyone can see major issues in this approach as a temporary fix then please let me know.


pianomansam’s picture

I'm using #91 to patch my 1.7 install. The report of duplicated rows when sorting by delta, which J-Lee reported, is a bug I'm observing. J-Lee reported they got around it because they didn't need it, but I do.

In an attempt to remove the duplicates, I added the "Content revision: Is Latest Revision" filter, as I will only need the latest paragraphs and their revisions. This, in turn, causes an error that "Base table or view not found".

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'dwell_digital.field_steps_paragraphs_item_revision_field_data' doesn't exist: SELECT AS field_steps_paragraphs_item_revision_field_data__node_revisi, AS id, field_steps_paragraphs_item_revision_field_data.vid AS field_steps_paragraphs_item_revision_field_data_vid FROM {paragraphs_item_field_data} paragraphs_item_field_data INNER JOIN {paragraphs_item_revision_field_data} paragraphs_item_revision_field_data ON paragraphs_item_field_data.revision_id = paragraphs_item_revision_field_data.revision_id INNER JOIN {node_revision__field_steps} node_revision__field_steps ON paragraphs_item_revision_field_data.revision_id = node_revision__field_steps.field_steps_target_revision_id AND node_revision__field_steps.deleted = :views_join_condition_0 INNER JOIN {node_field_revision} field_steps_paragraphs_item_revision_field_data ON node_revision__field_steps.revision_id = field_steps_paragraphs_item_revision_field_data.vid LEFT JOIN {field_steps_paragraphs_item_revision_field_data} field_steps_paragraphs_item_revision_field_data__field_steps_paragraphs_item_revision_field_data ON field_steps_paragraphs_item_revision_field_data.nid = field_steps_paragraphs_item_revision_field_data__field_steps_paragraphs_item_revision_field_data.nid AND field_steps_paragraphs_item_revision_field_data__field_steps_paragraphs_item_revision_field_data.vid > field_steps_paragraphs_item_revision_field_data.vid LEFT JOIN {node_revision__field_steps} field_steps_paragraphs_item_revision_field_data__node_revision__field_steps ON field_steps_paragraphs_item_revision_field_data.vid = field_steps_paragraphs_item_revision_field_data__node_revision__field_steps.revision_id AND field_steps_paragraphs_item_revision_field_data__node_revision__field_steps.deleted = :views_join_condition_2 WHERE ((field_steps_paragraphs_item_revision_field_data.nid = :node_field_revision_nid)) AND ((paragraphs_item_field_data.status = :db_condition_placeholder_3) AND (paragraphs_item_field_data.type IN (:db_condition_placeholder_4)) AND (field_steps_paragraphs_item_revision_field_data__field_steps_paragraphs_item_revision_field_data.nid IS NULL)) ORDER BY field_steps_paragraphs_item_revision_field_data__node_revisi ASC LIMIT 11 OFFSET 0; Array ( [:node_field_revision_nid] => 2085 [:db_condition_placeholder_3] => 1 [:db_condition_placeholder_4] => segment [:views_join_condition_0] => 0 [:views_join_condition_2] => 0 )

The field I'm attempting to connect via a reference in "field_steps".

wombatbuddy’s picture

I tried to apply #108 on Drupal 8.8.0 and got:
error: patch failed: tests/modules/entity_composite_relationship_test/
error: tests/modules/entity_composite_relationship_test/ patch does not apply

If remove the code related with "tests/modules" the patch does the job.

marcaddeo’s picture

Rerolled #108 without tests

liquidcms’s picture

fixed my issue of views reverse relationship not working.

dww’s picture

@marcaddeo re: #113: Why would you do that? ;) We want tests for this to be committed...

alisonjo315’s picture

#108 applied cleanly for me *after* I updated ERR from 8.x-1.7 to 8.x-1.x-dev. (I've got core 8.8.1.)

(If (if 😁) my experience accurately represents the situation, folks can just consider #113 a "band-aid" for people who are using 1.7 but still want the fixes provided by this patch, ya? ...And if not, never mind!)

alisonjo315’s picture

Status: Needs review » Reviewed & tested by the community

Oops sorry, forgot to say -- #108 worked great for me, fixed the problem!

Re: applying the patch: I didn't have the dev version before, so/but, for composer folks, in case it helps anyone...

  • It didn't work for me when I did composer require drupal/entity_reference_revisions:1.x-dev, then added the patch to composer.patches.json, then ran composer update drupal/entity_reference_revisions to apply the patch -- weirdly, when I did the last step (composer update on ERR), it simply removed the module, it didn't reinstall with the patch. (If I simply run composer update on ERR one more time, everything ends up correct, but it was weird, y'know?)
  • But, this worked:
    Add patch to composer.patches.json
    Run composer require drupal/entity_reference_revisions:1.x-dev
John Pitcairn’s picture

#108 working here, tests passing, agree it's RTBC.

The composer-patches failure to apply then deleting the module is a fairly well known bug, you can just run composer update again so it will reinstall and patch.

stopopol’s picture

I just applied #108 on the latest dev and running Drupal 8.8.3.
It did break the pre-set filters and relationships in my view, but after I re-created the filters and relationships, everything worked.

superlolo95’s picture

#108 worked for me

The last submitted patch, 108: 2799479-108.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

The last submitted patch, 108: 2799479-108.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

arthur_lorenz’s picture

#108 also worked for me, thx!

arthur_lorenz’s picture

Status: Reviewed & tested by the community » Needs work

After further testing I have to revoke my statement a bit: Patch works fine for newly created realtionship in views. Already existing views might break due to change of field name change in relationship (e.g. instead of field: field_paragraphs it's now field: field_paragraphs_target_id. So we need an update script here, that updates field names i guess.

el1_1el’s picture

+1 to #124, which has also been mentioned in #21 and #66

John Pitcairn’s picture

Agreed on #124, the patch at #113 that was passing tests had the tests removed. #108 is not passing.

gthibert’s picture

With patch #108, when using Rewrite Results, I just have access to {{field_name-revision_id}} and {{field_name-revision_id__target_id}} as Replacement Patterns, not to the field value (a string in my case).

studio-days’s picture

#108 worked for me in Drupal 8.8.5. Because it was my first time using Composer to patch a module I thought I'd write out the steps I've just learnt. Maybe it'll help someone:

Install to declare patches:

composer require cweagans/composer-patches

Change to the dev version of the module:

composer require 'drupal/entity_reference_revisions:1.x-dev'

Add patch under "extra" in composer.json:

"extra": {
        "patches": {
            "drupal/entity_reference_revisions": {
              "2799479: Views doesn't recognize relationship to host": ""

Apply the patch:

composer update drupal/entity_reference_revisions

Look out for this message:

- Applying patches for drupal/entity_reference_revisions (2799479: Views doesn't recognize relationship to host)

Flush the damn cache:

drush cr

oldspot’s picture

I can confirm as well that patch #108 works with core '8.8.5' and entity_reference_revisions '1.x-dev'.

dercheffe’s picture

Hmm okay how "save" is it to use the patch in #108 ? Is it only affecting the displaying of views or is it changing data in the database permanently? Imo a real major issue.

alisonjo315’s picture

@dercheffe My understanding is that the patches on this thread provide a redo/rework of the views relationship, effectively adding a new views relationship -- there are no effects on ERR data.

Great point in #124 about existing relationships -- btw, I was skimming through the entire thread, and this side-effect was mentioned by @tacituseu three years ago back in #21. Any chance "it doesn't matter" because the relationships are broken now, so theoretically no one's using them anyway...? Just kidding...mostly! :D (I'm afraid I don't know how to write an appropriate update hook, so my purpose here is to offer an explanation of what the patch does, share a fun historical fact, and make a hilarious joke.)

bubu’s picture

Thanks for #108, it worked for me. I came here after Upgrading D7 to Drupal 8.8.5 with migrating from Field collection to Paragraphs (8.x-1.11) and Entity Reference Revisions (8.x-1.8). Migrating was successfully with a Paragraphs patch, contents displayed well, but with views I experienced this issue. I followed instructions in #128. Updating to dev and #108 helps me. After installing I have broken old relationship, but it was easy to recreate them. Thanks!

Rob230’s picture

#108 working great for me for Drupal Commerce orders or payments being related to billing profiles.

nsciacca’s picture

I can confirm that the patch fixes the relationship but does not work with the core delta field. The issue is that adding the "delta" field, whether for display or sorting, is defined in and is designed to work for multiple fields - which it does by adding the table again and joining on the entity_id instead of the target_id to display the field. It could just pull the delta from the already joined table but it doesn't seem to know about that. So instead it joins the table again with a new alias on the wrong parameters and therefore creates duplicate rows so every child reference is listed with every existing delta.

I'm wondering if the fix is to have entity_reference_revisions define its own delta field so it can use the same base table already added. I'm looking into this but asking for anyone's help who maybe has more experience with views data hooks/alters.

Update: I fixed my delta sorting by using the following code in a custom module:

 * Implements hook_views_query_alter().
function mymodule_views_query_alter(ViewExecutable $view, QueryPluginBase $query) {
  // Add OrderBy for paragraph deltas - can't do through Views UI
  // because entity_reference_revisions doesn't work with core delta field.
  if ($view->id() == 'your_view_id') {
    $query->addOrderBy('field_segments_node_field_data__node__field_segment_groups', 'delta', 'ASC');
    $query->addOrderBy('paragraph__field_segments', 'delta', 'ASC');

My example above is sorting on 2 different levels of paragraphs, so likely you may only need 1. I got the paragraph table aliases from the Views query display. It's not perfect but does the trick for now. Hope this helps someone else.

bmcclure’s picture

#108 applies for me on the latest version using git apply, but it for some reason fails whenever I try to apply it via composer.json. I even tried re-rolling it, but the resulting patch file still doesn't apply with composer. Is anyone else experiencing this?

Update: The no-tests version from #113 actually applies correctly, so it seems to just be the tests that cweagans/composer-patches can't seem to apply. While #113 is certainly not an ideal solution, I'm glad it exists for now.

jenniferaube’s picture

#108 patch not working for me.
Used #128 to install patch with composer.
View is still broken when trying to use filter 'Is latest revision'.
Using with Drupal 8.9

eigentor’s picture

The patch does not apply anymore to version 8.1.8 of entity_reference_revisions
Strangely it is only the small bit where the two dependencies

 - drupal:node
 - drupal:views

are added to

Weird how that can be a problem.
Needs a quick reroll, should be easy to do.
For all people trying to apply the patch:
e.g. when using the trusty old

patch -p1 < [patchfile]

command to manually apply patches:
remove the .orig and .rej files created in tests/modules/entity_composite_relationship_test, manually add the two lines shown above to the named .info.yml file and you are good to go.
The functionality still works.

For those that are looking for the right relationship in Views relationships after applying the patch: they all sound so similar!
It is named:
"Content revision using [name-of-paragraphs-reference-field].
Category: Paragraph
Description text reads as follows:
"Relate each content revision with a [name-of-paragraphs-reference-field] set to the paragraph.

aanjaneyam’s picture

I have been following this issue for a long time but now I feel if it would be ever solved.

Also, I am a bit confused here with so many responses and this bug has literally stopped one of the site development where landing pages are to be built upon on views based on paragraphs in content types thus requiring a relationship to the content. Is there a workaround other than the patch or do we just have to use the patch above? I was wondering if there is any other module which can help address this issue.

I shall be highly grateful for any help or clues explained in plain words as I am still trying to grapple with the Drupal 8 composer based workflow.

Rob230’s picture

Hi aanjaneyam,

It depends on how you have your composer.json set up.

If you are using the standard Drupal composer then you should already have cweagans/composer-patches set up and you just need to add the patch to the extras section like this:

"require": {
    "cweagans/composer-patches": "~1.0",
"extra": {
    "patchLevel": {
        "drupal/core": "-p2"
    "enable-patching": true,
    "patches": {
        "drupal/entity_reference_revisions": {
            "Views doesn't recognize relationship to host": ""
aanjaneyam’s picture

I am using varbase distribution. There is a composer.joson in project root but it does not list ERR module. It appears they are using any sub composer.json hidden somewhere in the codebase (maybe install profile). I will have to dig a bit more to find the location of the composer.json used. Or, I am not sure, if I can just blindly follow #128 above and include the patches statement in the main JSON file at the project root. I am running entity_reference_revision version 1.8 (released 11 March 2020), so do I really need to update to dev version first before applying the patch.

Below is the main composer.json in project root

    "name": "vardot/varbase-project",
    "require": {
        "composer/installers": "~1.0",
        "cweagans/composer-patches": "~1.0",
        "drupal/config_readonly": "^1.0",
        "drupal/config_split": "^1.4",
        "drupal/core-composer-scaffold": "^8.8.0",
        "drupal/core-project-message": "^8.8.0",
        "drupal/drupal-library-installer-plugin": "^0.3",
        "drupal/recreate_block_content": "2.x-dev",
        "drush/drush": "^10.2",
        "oomphinc/composer-installers-extender": "~1.0",
        "vardot/varbase": "~8.8.5",
        "vardot/varbase-updater": "~1.0",
        "webflo/drupal-finder": "~1.0",
        "webmozart/path-util": "~2.0",
        "drupal/responsive_menu": "^4.0",
        "drupal/fontawesome": "^2.17",
        "drupal/fontawesome_menu_icons": "^1.8"
    "conflict": {
        "drupal/drupal": "*"
    "replace": {
        "ajaxorg/ace-builds": "*"
    "type": "project",
    "extra": {
        "drupal-scaffold": {
            "allowed-packages": [
            "file-mapping": {
                "[web-root]/.htaccess": false
            "locations": {
                "web-root": "docroot/"
        "drupal-core-project-message": {
            "include-keys": [
            "post-create-project-cmd-message": [
                "<bg=blue;fg=white>                                                         </>",
                "<bg=blue;fg=white>  Congratulations, you’ve installed the Varbase codebase </>",
                "<bg=blue;fg=white>  from the vardot/varbase-project template!              </>",
                "<bg=blue;fg=white>                                                         </>",
                "<bg=yellow;fg=black>Next steps</>:",
                "  * Install the site:",
                "  * Read the user guide:",
                "  * Get support:",
                "  * Join Our Slack Team for Feedback and Support:",
                "  * Remove the plugin that prints this message:",
                "      composer remove drupal/core-project-message"
        "_readme": [
            "NOTICE: We're now using composer patches from Vardot repository to suggest",
            "several fixes and better handling of patches in your Drupal project.",
            "You'll notice that we have included (",
            "in this composer.json repositories. This will replace the original",
            "library (cweagans/composer-patches) with our own from (vardot/composer-patches).",
            "See and more details",
            "on our changes on the composer-patches package. Once our changes get merged,",
            "we will revert to using (cweagans/composer-patches) without this override."
        "branch-alias": {
            "dev-8.x-8.x": "8.8.x-dev"
        "installer-types": [
        "installer-paths": {
            "docroot/core": [
            "docroot/profiles/{$name}": [
            "docroot/modules/contrib/{$name}": [
            "docroot/themes/contrib/{$name}": [
            "docroot/libraries/slick": [
            "docroot/libraries/ace": [
            "docroot/libraries/masonry": [
            "docroot/modules/custom/{$name}": [
            "docroot/themes/custom/{$name}": [
            "drush/contrib/{$name}": [
            "docroot/libraries/{$name}": [
        "drupal-libraries": {
            "library-directory": "docroot/libraries",
            "libraries": [
                    "name": "dropzone",
                    "package": "npm-asset/dropzone"
                    "name": "blazy",
                    "package": "npm-asset/blazy"
                    "name": "slick",
                    "package": "npm-asset/slick-carousel"
                    "name": "ace",
                    "package": "npm-asset/ace-builds"
                    "name": "chartjs",
                    "package": "bower-asset/chartjs"
                    "name": "c3",
                    "package": "bower-asset/c3"
                    "name": "d3",
                    "package": "bower-asset/d3"
                    "name": "masonry",
                    "package": "npm-asset/masonry-layout"
                    "name": "imagesloaded",
                    "package": "npm-asset/imagesloaded"
                    "name": "swagger-ui",
                    "package": "swagger-api/swagger-ui"
        "enable-patching": "1",
        "composer-exit-on-patch-failure": false,
        "patchLevel": {
            "drupal/core": "-p2"
    "scripts": {
        "post-install-cmd": [
        "post-update-cmd": [
        "post-drupal-scaffold-cmd": [
    "license": [
    "authors": [
            "name": "Vardot",
            "homepage": "",
            "role": "Maintainer"
    "description": "Project template for Varbase distribution.",
    "repositories": {
        "drupal": {
            "type": "composer",
            "url": ""
        "assets": {
            "type": "composer",
            "url": ""
        "composer-patches": {
            "type": "vcs",
            "url": ""
    "support": {
        "issues": "",
        "source": ""
    "minimum-stability": "dev",
    "prefer-stable": true
aanjaneyam’s picture

Cannot apply the patch on version 1.8 (the release date for the same as the dev version). I am not sure if version is the reason

composer update drupal/entity_reference_revisions
Gathering patches for root package.
Removing package drupal/entity_reference_revisions so that it can be re-installed and re-patched.
  - Removing drupal/entity_reference_revisions (1.8.0)
Deleting docroot/modules/contrib/entity_reference_revisions - deleted
Loading composer repositories with package information
Updating dependencies (including require-dev)         
Package operations: 1 install, 0 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Installing drupal/entity_reference_revisions (1.8.0): Downloading (100%)         
  - Applying patches for drupal/entity_reference_revisions (Issue #2799479: Views doesn't recognize relationship to host)
   Could not apply patch! Skipping. The error was: Cannot apply patch

Package container-interop/container-interop is abandoned, you should avoid using it. Use psr/container instead.
Writing lock file
Generating autoload files
38 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Scaffolding files for drupal/core:
  - Skip [web-root]/.htaccess: overridden in vardot/varbase-project
  - Copy [web-root]/sites/ from assets/scaffold/files/
> Varbase\composer\ScriptHandler::postDrupalScaffoldProcedure
> Varbase\composer\ScriptHandler::createRequiredFiles
> Varbase\composer\ScriptHandler::removeGitDirectories

aanjaneyam’s picture

Do we need to upgrade the module form 1.8 to 1.x-dev in order to be able to successfully apply the patch.

John Pitcairn’s picture

@aanjaneyam: Yes, 8.x-1.x-dev is required to apply the patch.

tibezh’s picture

The patches from #108 and #113 work. But it breaks already existing relationships.

gustavowal’s picture

In our case the patch from #108 seems to resolve the broken relationships that showed after Core + Commerce Updates.

super_romeo’s picture

EntityType::getSingularLabel() now handles lower-casing the entity type label; getLowercaseLabel() deprecated.

tbsiqueira’s picture

I tested patch #108 and #146, both are not working for me, I still can see old paragraphs in my view.

realgt’s picture

#146 worked for me

stopopol’s picture

#146 can be applied on the latest dev, but breaks all pre-existing relationships.
Also it only seems to partially fix the problem as in my case now more nodes are recognised to have a particular paragraph as a filter criteria but not all of them.

DuneBL’s picture

#146 can be applied on the latest dev, but the relationship to the host entity (a node in my case) does not work with multiple values...
I have used this relationship:
Relate each Content with a field_my_parag set to the Paragraph.
Edit to add: I have clicked on the "Require this relationship" checkbox of the RELATIONSHIPS settings

After adding the (required) relationship, I can add the 'title' field of the node (using this relation) but the column is empty
Edit to add: This is not working at 100% because I can only see one paragraph for a given node/field but this field is a multi-value field and contains 2 items (paragraphs)

Before clicking on the "Require this relationship" checkbox of the RELATIONSHIPS settings I could see my 2 items/paragraphs for this node/field.
Clicking on this checkbox make disapears one of my 2 paragraph items

Here is the query generated by that views that should display all paragraphs (only one type=my_parag_type) added to a node through the field field_my_parag. It display only one paragraph but the field contains 2 paragraphs

SELECT paragraphs_item_field_data.langcode AS paragraphs_item_field_data_langcode, field_my_parag_paragraphs_item_field_data.langcode AS field_my_parag_paragraphs_item_field_data_langcode, AS id, field_my_parag_paragraphs_item_field_data.nid AS field_my_parag_paragraphs_item_field_data_nid
{paragraphs_item_field_data} paragraphs_item_field_data
INNER JOIN {node__field_my_parag} node__field_my_parag ON = node__field_my_parag.field_my_parag_target_id AND node__field_my_parag.deleted = '0'
INNER JOIN {node_field_data} field_my_parag_paragraphs_item_field_data ON node__field_my_parag.entity_id = field_my_parag_paragraphs_item_field_data.nid
WHERE (paragraphs_item_field_data.status = '1') AND (paragraphs_item_field_data.type IN ('my_parag_type'))
dalin’s picture

Issue summary: View changes
135.05 KB

For me the patch in #146 is working well enough.

Until there's an update hook to fix existing views, here's a quick way to find all the views that need to be manually fixed: Search your config folder for paragraphs_item_field_data. FWIW, I think the technique described in #110 isn't great because the views will still be broken when you edit them in the UI.

This patch does add some UX issues though. There are now two options for adding a relationship from a host entity to a paragraph. I'm not sure what the practical difference is. AFAICT they work the same.

However, this patch does seem to break some filters: I have a view of nodes, with a relationship to a paragraph, and an exposed filter of a field on that paragraph. Before this patch the exposed filter worked fine (other than the bug that this patch is fixing). Now I get an error in the Views UI:

The filter criterion Paragraph: My Field (field_my_field) uses a relationship that has been removed.

This is despite that the filter is using the relationship, and no amount of clicking on things in the UI can fix it.

dalin’s picture

Issue summary: View changes
dalin’s picture

Issue summary: View changes
Fernly’s picture

Confirming that patch #146 works with the current dev version.
Creating a view from scratch is recommended if not required for this to work.

adinac’s picture

This is the patch from #108 (the one with no tests, because the patch from #146 didn't apply) with the fix for: EntityType::getSingularLabel() now handles lower-casing the entity type label; getLowercaseLabel() deprecated (

superlolo95’s picture

+1 for #155

with entity_reference_revisions version: '8.x-1.9'

yfma’s picture

#155 can apply on 8.x-1.9. But the relationship is not working properly. Once add relationship and set it as required, some items disappeared from the view. Our situation is having multiple paragraph items on paragraph field.

nikita_tt’s picture

The attached patch is mostly a copy of the #155 but some lines of the removed code were returned. They are needed for keeping already existing relationships not broken. I didn't test it properly but for the first view it works and might be useful for someone as a fast workaround solution.

bjcooper’s picture

#158 works for me for adding the content revision relationship, but if I attempt to filter the content revisions by "Is Latest Revision" I get the following error:

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'mysite.field_myfield_paragraphs_item_revision_field_data' doesn't exist

The table it's trying to find there looks pretty bizarre (I confirmed that the "Content revision" is selected as the relationship to use for the "Is Latest Revision" filter).

SocialNicheGuru’s picture

in my install, the contextual filter is applied at the start.

Once I use the "Filter criteria", the contextual filter cannot be reset. This might be new behavior of views in D8.9+. However states something different

The contextual filter, parent: Paragraph ID, can only have "Display all results for the specified field". None of the other options work. In addition no other validation worked. I tested with no filter criteria to see if the contextual filters would work.

The "Contextual filters" and "Filter criteria" do not have overlapping filter values. For example the contextual filter has "Parent: Paragraph id" and the "Filter criteria" has taxonomy terms.

hudri’s picture

We are using #158 successfully on multiple projects using a standard "Content using field..." relationship. The basic functionality is given, and works as expected with any cardinality (but we also did not use it with obscure setups with revisions or contextual filters).