Views doesn't recognize relationship to host

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.

+++ b/entity_reference_revisions.views.inc
@@ -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.

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? ;-)

Fair point :)

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

+++ b/entity_reference_revisions.views.inc
@@ -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.

Hi,

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

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.

Thoughts?

#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:
https://www.drupal.org/node/2741937

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.

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

Thanks in advance!

@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.

Reverse relationship needs some work.

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

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 https://www.drupal.org/pift-ci-job/610454).

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.

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.

@Berdir: yes, subclassing looks perfectly doable.

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.

Might as well leave 'revision' alone.

Edit:
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.

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.

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

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.

Thanks!

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".

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?

@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\views.views.inc::views_field_default_views_data() 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.

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.

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.

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.

Patch no longer applies to latest dev.

$ git clone --branch 8.x-1.x https://git.drupal.org/project/entity_reference_revisions.git
...
$ git apply -v /b/2799479-21-views-rel-fix.patch
Checking patch entity_reference_revisions.views.inc...
Checking patch src/Plugin/views/relationship/EntityReferenceRevisions.php...
Applied patch entity_reference_revisions.views.inc cleanly.
Applied patch src/Plugin/views/relationship/EntityReferenceRevisions.php cleanly.

Triggering tests to check.

Back to needs work for tests.

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)

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

@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.

the patch in #34 worked for me ...

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

Patch #34 wins

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

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.

@cbrasfield check #2831233: Field tokens for "historical data" fields (revisions) contain a hyphen, breaking twig templates and throwing an assertion error

#34 solved this issue for me https://www.drupal.org/node/2819603

Thanks!

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.

#34 worked for me also.

#34 works perfect! Thanks

#34 is working fine

#34 Works great for me! Thanks!

- 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

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.

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

Quickly reviewing the code a bit, not tested yet.

1. +++ b/entity_reference_revisions.views.inc
   @@ -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/entity_reference_revisions.views.inc
   @@ -5,68 +5,216 @@
   +        if ($field->getCardinality() == 1) {
   

   Needs special test coverage for cardinality 1.

3. +++ b/entity_reference_revisions.views.inc
   @@ -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?

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?

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.

@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.

> 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.

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.

Tested #55, working as expected.

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

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

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

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 views.views.inc file which prefers duplication over ternaries.

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;

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.

Personally I'm waiting for the following core issues before committing more time: #2706431: provide Views reverse relationships automatically for entity base fields, #2795455: Views does not add relationship data for entity_reference fields not defined in configuration and are multiple, #2895578: Views does not add reverse relationship data for entity_reference fields not defined in configuration.

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

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?

#34 will also apply against current dev using composer.

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.

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

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.

@ñull Are you multilingual?

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

Same result for me as #74

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.

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.

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?

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.

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?

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

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

You could use

https://www.drupal.org/project/views_field_formatter

( or as alternative https://www.drupal.org/project/views_field_view )

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.

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/entity_composite_relationship_test.info.yml
@@ -5,5 +5,7 @@ package: Testing
 core: 8.x
 
 dependencies:
- - entity_reference_revisions
- - entity_test
\ No newline at end of file
+ - drupal:node

The

\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

dependencies:
 - entity_reference_revisions
 - entity_test
# Information added by Drupal.org 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.

#8 Worked for me... Thanks

#8 Worked for me... Thanks

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

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

Hello,

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

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

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/entity_composite_relationship_test.info.yml as when applied to stable it results in:

patching file entity_reference_revisions.views.inc
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/entity_composite_relationship_test.info.yml
Hunk #1 FAILED at 5.
1 out of 1 hunk FAILED -- saving rejects to file tests/modules/entity_composite_relationship_test/entity_composite_relationship_test.info.yml.rej
patching file tests/modules/entity_composite_relationship_test/src/Entity/EntityTestCompositeRelationship.php
patching file tests/src/Kernel/EntityReferenceRevisionsViewsTest.php

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

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

$ git clone --branch 8.x-1.x https://git.drupalcode.org/project/entity_reference_revisions.git
...
$ patch -p1 < 2799479-90.patch 
patching file entity_reference_revisions.views.inc
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/entity_composite_relationship_test.info.yml
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!

Thanks

Please ignore this comment

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/entity_composite_relationship_test.info.yml).

patching file entity_reference_revisions.views.inc
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/entity_composite_relationship_test.info.yml
Hunk #1 FAILED at 5.
1 out of 1 hunk FAILED -- saving rejects to file tests/modules/entity_composite_relationship_test/entity_composite_relationship_test.info.yml.rej
patching file tests/modules/entity_composite_relationship_test/src/Entity/EntityTestCompositeRelationship.php
patching file tests/src/Kernel/EntityReferenceRevisionsViewsTest.php

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

I confirm too #99 fixes the issue. Thanks

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

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 paragraphs_item_field_data.id 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
FROM
{paragraphs_item_field_data} paragraphs_item_field_data
INNER JOIN {node__field_paragraph} node__field_paragraph ON paragraphs_item_field_data.id = 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')

Result:

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 field_paragraph_paragraphs_item_field_data__node__field_paragraph.delta AS field_paragraph_paragraphs_item_field_data__node__field_para, paragraphs_item_field_data.id 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
FROM
{paragraphs_item_field_data} paragraphs_item_field_data
INNER JOIN {node__field_paragraph} node__field_paragraph ON paragraphs_item_field_data.id = 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

Result:

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)

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.

Is there a version of this patch that will work for the 8.x-1.7 branch? Tried applying the one in . https://www.drupal.org/project/entity_reference_revisions/issues/2799479... and wound up with some nasty PHP errors

The patch in 91 (https://www.drupal.org/files/issues/2019-10-07/2799479-91-DO_NOT_COMMIT....) should apply to 1.7

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

#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.

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

+++ b/tests/modules/entity_composite_relationship_test/entity_composite_relationship_test.info.yml
@@ -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.

Cheers,
-Derek

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'])) {

    unset($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.

Andy

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 field_steps_paragraphs_item_revision_field_data__node_revision__field_steps.delta AS field_steps_paragraphs_item_revision_field_data__node_revisi, paragraphs_item_field_data.id 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".

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

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

Rerolled #108 without tests

fixed my issue of views reverse relationship not working.

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

#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!)

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

#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.

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.

#108 worked for me

#108 also worked for me, thx!

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.

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

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

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).

#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": "https://www.drupal.org/files/issues/2019-12-10/2799479-108.patch"
            }
        },

Apply the patch:

composer update drupal/entity_reference_revisions

Look out for this message:

- Applying patches for drupal/entity_reference_revisions
    https://www.drupal.org/files/issues/2019-12-10/2799479-108.patch (2799479: Views doesn't recognize relationship to host)

Flush the damn cache:

drush cr

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

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.

@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.)

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!

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

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 views.view.inc 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.

#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.

#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

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 entity_composite_relationship_test.info.yml

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.

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.

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": "https://www.drupal.org/files/issues/2019-12-10/2799479-108.patch"
        },
    }
}

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": [
                "drupal/core"
            ],
            "file-mapping": {
                "[web-root]/.htaccess": false
            },
            "locations": {
                "web-root": "docroot/"
            }
        },
        "drupal-core-project-message": {
            "include-keys": [
                "homepage",
                "support"
            ],
            "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: https://www.drupal.org/docs/8/install",
                "  * Read the user guide: https://docs.varbase.vardot.com",
                "  * Get support: https://www.vardot.com/en/form/get-support-varbase",
                "  * Join Our Slack Team for Feedback and Support:",
                "      http://slack.varbase.vardot.com",
                "  * 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 (https://github.com/vardot/composer-patches)",
            "in this composer.json repositories. This will replace the original",
            "library (cweagans/composer-patches) with our own from (vardot/composer-patches).",
            "See https://github.com/cweagans/composer-patches/pull/243 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": [
            "bower-asset",
            "npm-asset"
        ],
        "installer-paths": {
            "docroot/core": [
                "type:drupal-core"
            ],
            "docroot/profiles/{$name}": [
                "type:drupal-profile"
            ],
            "docroot/modules/contrib/{$name}": [
                "type:drupal-module"
            ],
            "docroot/themes/contrib/{$name}": [
                "type:drupal-theme"
            ],
            "docroot/libraries/slick": [
                "npm-asset/slick-carousel"
            ],
            "docroot/libraries/ace": [
                "npm-asset/ace-builds"
            ],
            "docroot/libraries/masonry": [
                "npm-asset/masonry-layout"
            ],
            "docroot/modules/custom/{$name}": [
                "type:drupal-custom-module"
            ],
            "docroot/themes/custom/{$name}": [
                "type:drupal-custom-theme"
            ],
            "drush/contrib/{$name}": [
                "type:drupal-drush"
            ],
            "docroot/libraries/{$name}": [
                "type:drupal-library",
                "type:bower-asset",
                "type:npm-asset"
            ]
        },
        "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": [
            "Varbase\\composer\\ScriptHandler::createRequiredFiles",
            "Varbase\\composer\\ScriptHandler::removeGitDirectories"
        ],
        "post-update-cmd": [
            "Varbase\\composer\\ScriptHandler::createRequiredFiles",
            "Varbase\\composer\\ScriptHandler::removeGitDirectories"
        ],
        "post-drupal-scaffold-cmd": [
            "Varbase\\composer\\ScriptHandler::postDrupalScaffoldProcedure"
        ]
    },
    "license": [
        "GPL-2.0-or-later"
    ],
    "authors": [
        {
            "name": "Vardot",
            "homepage": "https://github.com/vardot",
            "role": "Maintainer"
        }
    ],
    "description": "Project template for Varbase distribution.",
    "repositories": {
        "drupal": {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        "assets": {
            "type": "composer",
            "url": "https://asset-packagist.org"
        },
        "composer-patches": {
            "type": "vcs",
            "url": "https://github.com/vardot/composer-patches"
        }
    },
    "support": {
        "issues": "http://drupal.org/project/issues/varbase",
        "source": "http://cgit.drupalcode.org/varbase"
    },
    "minimum-stability": "dev",
    "prefer-stable": true
}

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
    https://www.drupal.org/files/issues/2019-12-10/2799479-108.patch (Issue #2799479: Views doesn't recognize relationship to host)
   Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2019-12-10/2799479-108.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/development.services.yml from assets/scaffold/files/development.services.yml
> Varbase\composer\ScriptHandler::postDrupalScaffoldProcedure
> Varbase\composer\ScriptHandler::createRequiredFiles
> Varbase\composer\ScriptHandler::removeGitDirectories

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

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

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

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

EntityType::getSingularLabel() now handles lower-casing the entity type label; getLowercaseLabel() deprecated.
https://www.drupal.org/node/3075567

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

#146 worked for me

#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.

#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, paragraphs_item_field_data.id AS id, field_my_parag_paragraphs_item_field_data.nid AS field_my_parag_paragraphs_item_field_data_nid
FROM
{paragraphs_item_field_data} paragraphs_item_field_data
INNER JOIN {node__field_my_parag} node__field_my_parag ON paragraphs_item_field_data.id = 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'))

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.

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

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 (https://www.drupal.org/node/3075567).

+1 for #155

with entity_reference_revisions version: '8.x-1.9'

#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.

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.

#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).

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 http://drupal.org/project/filter_harmonizer 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.

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).

I add the functionality which checks the entity id, not revision. It helps me when I work with paragraphs.

Minor fix for the previous patch.

Tested
I created a view of paragraphs and added a relationship with content having fields which references the current paragraph type.

#158 doesn't works for me.. !

But, #163 works for me.. !

#163 also worked for me after I had cleared the cache!

#163 works great

#163 fixed this issue for me too on a simple paragraph view with a relationship to it's parent node.

Patch #163 saved my day using Drupal 8.9.20, Paragraphs 8.x-1.2 and Entity Reference 8.x-1.9

Here is my use case:

• a 'company' node has a 'departments' multi-valued field which is a reference to a 'department' paragraph
• the 'department' paragraph has an 'employees' multi-valued field which is a reference to user accounts
• that way, I can create a company with several departments, each of them having a bunch of users
• and then, display a directory of all companies, linked to their detailed page where employees are grouped by departments

The next step is to add to the core /admin/people views the company the user is related to by adding 2 relationships: user to paragraph and paragraph to node (and this is where relationship on "Content using field_x" fails).

That second relationship now works with patch #163 applied.
Thanks

Can we apply both patches #158 and
#163 together as they serve different purpose and functionality. Also do we need version 1.9 or 1.x-dev as they both appear to be released on the same day.

I'm curious if a fix has been rolled into any version of the nodule for D9?
Unless I am mistaken, this bug means that there is effectively no paragraphs/views integration right now. At least not that involves fields from both a paragraph and its 'host' node. I wish I was more of a developer, and able to help wit the solution. In the absence of that, I'll risk being annoying and asking - isn't this kind of a big deal and something that should be applied to the next dev version at least?

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

I also encountered this issue today, but without this patch. Removing it from the issue description since it is unrelated.
I created a core issue: #3276456: Latest revision views filter causes 'Base table or view not found'

Hey folks! Thanks for working on this one.

I'm using #172 in a D 9.3 project with success.

Here also the patch generated from the merge request.

#176 worked for me on D 9.4.0 and ERR 1.9

Thank you!

#176 worked for me on D 9.4.0 and ERR 1.9

My problem is that only admin could see paragraphs field.
How can I solve it?

@kazah

My problem is that only admin could see paragraphs field.
How can I solve it?

That sounds unrelated. It sounds like either you have a permissions problem, and/or a caching problem. Can you search through other tickets, and if you don't find anything open a _new_ ticket so that this one doesn't get muddied?

Yes, I think it's related to paragraph module.

Permission problem with unpublished paragraphs.

#176 It works great. There is a phpsc code standard issue, it should be merged with the development version and we will fix all latter

Here is the output of #176 applied to last version (1.10)

patching file entity_reference_revisions.views.inc
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 195 with fuzz 1.

#176 worked for me on version 1.10, though applying the patch returned the same output that DuneBL mentioned. However, the relationship now works as expected.

6 years and running to get one of most popular Drupal modules to work properly with views?

Sorry to sound like a hater, this issue killed my day and I'm shit posting. #176 doesn't work under certain circumstances, like with workflows when the content isn't published. I wish I could contribute, but as a lowly front-end guy there's probably not much I can do. I will contribute monetarily though if there's a transparent way for me to do that.

For me applying patch from #176 duplicates the paragraphs in some cases. It seems that using content translation + adding a node translation causes this problem. I already added a paragraph language specific filter to my views display.
Update: I were able to fix this problem by adding an additional language filter for the parent node (content) entity within the views display.

I'm a bit confused with the state of the different patches in here, but #158 works on 9.5.3.

However, when adding a relationship I have a duplication for "Content using [field_name]" and one of them works, while the other doesn't.

Setting this to "Needs work" according to comment 185.

I've rebased the issue fork and it seems to work for me. I've not sure how the issue fork has diverged from the latest patch though.

+1 for the MR 5.

Just tested MR5 from #187 and it fixed this issue for me.

Thanks,

Is a patch available for comment number #187? thx

I use composer, so, I use this link to patch -> https://git.drupalcode.org/project/entity_reference_revisions/-/merge_re...

Thanks, abx. Seems to be working for me.

Setting NR for #187

Will update hooks be added to this issue or will that be another issue?

@SocialNicheGuru what update hooks are you referring to? It's been a while since I looked at this issue, but I didn't think it needed an update hook.

Comment #124 outlines the need for update_hook as well as comment #125

This breaks old views when applied. I am experiencing this too.

Update 6-21-23:
When I goto admin/structure/paragraphs_type the paragraphs are there. I can edit them and save them, etc.

But suddenly they are not visible by views. None of my paragraphs are. Not even paragraphs created by other modules.

In #124 an update hook was referenced. I guess it might have been referring to content types not the views themselves.

The paragraphs can't be read by them.

We created a new paragraph to copy the content of the old paragraph and voila, the new paragraph is readable by views.

I tried opening and saving the old paragraph type. They still are not readable by views.

We are going to try deleting paragraph types and re-importing.

---
Drupal 9.5.9
MR 5 applied
php8.1
paragraphs 1.5
err 1.10

I am also having an issue.
My slideshow view has a relationship:

"paragraph referenced by slideshow_paragraph_ref"

slideshow_paragraph_ref is in my slideshow content type and points to slideshow paragraph type

I can add the new relationships fine.
When I try to then add fields from my specific paragraph the fields are not there. There is no reference to the specific paragraph type.

I do have access to generic paragraph fields:

Admin title (admin_title)	Paragraph	The admin title is used to help identify paragraphs when using them as blocks.
Update Authored on (created)
Authored on (created)	Paragraph	The time that the Paragraph was created.
Update Behavior settings (behavior_settings)
Behavior settings (behavior_settings)	Paragraph	The behavior plugin settings
Update Default translation (default_langcode)
Default translation (default_langcode)	Paragraph	A flag indicating whether this is the default translation.
Update ID (id)
ID (id)	Paragraph	
Update Link to Paragraph (view_paragraph)
Link to Paragraph (view_paragraph)	Paragraph	Provide a view link to the Paragraph.
Update Original language (langcode)
Original language (langcode)	Paragraph	The paragraphs entity language code.
Update Paragraph type (type)
Paragraph type (type)	Paragraph	
Update Parent field name (parent_field_name)
Parent field name (parent_field_name)	Paragraph	The entity parent field name to which this entity is referenced.
Update Parent ID (parent_id)
Parent ID (parent_id)	Paragraph	The ID of the parent entity of which this entity is referenced.
Update Parent type (parent_type)
Parent type (parent_type)	Paragraph	The entity parent type to which this entity is referenced.
Update Publish on (publish_on)
Publish on (publish_on)	Paragraph	
Update Published (status)
Published (status)	Paragraph	
Update Rendered entity (rendered_entity)
Rendered entity (rendered_entity)	Paragraph	Renders an entity in a view mode.
Update Revision ID (revision_id)
Revision ID (revision_id)	Paragraph	
Update Revision translation affected (revision_translation_affected)
Revision translation affected (revision_translation_affected)	Paragraph	Indicates if the last edit of a translation belongs to current revision.
Update Translation language (langcode)
Translation language (langcode)	Paragraph	The paragraphs entity language code.
Update Unpublish on (unpublish_on)
Unpublish on (unpublish_on)	Paragraph	
Update UUID (uuid)
UUID (uuid)	Paragraph

Update:
I did have to do that in order for the view fields and relationships to not be broken.
i also had to recreate my paragraphs.
The ones that i had are not seen.

---
Thank you #124
I had to goto my effected view
do a search and replace and add "_target_id" to ERR in my view
so field_paragraph became field_paragraph_target_id
I deleted the view
I had mine in a feature/config so did a drush features-import feature name you can do a config-import.
And all is good in the world again.

I've pushed the missing filter plugin and tests to the MR.

To keep this issue sane and in any hope of getting committed, please do not post any more reroll patches of previous patches without tests, etc.

To generate a patch from the MR, you can do a wget https://git.drupalcode.org/project/entity_reference_revisions/-/merge_requests/5.diff

And commit the patch locally, you can reference a local patch in composer using "my patch": "./path/to/file.patch"

Unfortunately with the latest changes MR5 is causing problems and is not being applied correctly.

@google01 the MR !5 does not apply to a released version because entity_composite_relationship_test.info.yml is changed by drupal.org release packaging.

As a solution you could switch to a git checkout of entity_reference_revisions like this:

composer reinstall --prefer-source drupal/entity_reference_revisions

Better use

composer update --prefer-source drupal/entity_reference_revisions

@luenemann I run your first composer reinstall command, but the MR !5 still doesn't apply.

The second one (the update) works.

The MR !5 patch works locally using the @luenemann advice, but it doesn't work in my CI/CD pipeline because we use the standard --prefer-dist flag in composer install command.

Temporarily I install the dev-1.x version of the module.

Although not my first choice to use "dev" modules in production, you can apply the patch by replacing the stable version of the module in composer.json with:

"drupal/entity_reference_revisions": "1.x-dev",

For those of us who use modules like "paragraph" the integrity of this module is essential.

But it is always appreciated the tasks to improve the features of the contributed modules.

@robertoperuzzo You can set preferred-intall in composer.json config (https://getcomposer.org/doc/06-config.md#preferred-install) . Use

composer config preferred-install.drupal/entity_reference_revisions source

In case someone needs fix-only patch, which does not touch the info file. -> #3371284: Patches - entity_reference_revisions ;-)

Back to NW as of the failing tests in #201

Note: All failing tests boil down to:

Exception: Exception when installing config for module entity_composite_relationship_test, message was: No schema for views.view.composite_entities

Any idea how to fix this and move this forward? It it's in the comments or the IS, i did not see it.

That's because these tests don't have the views module enabled. Moving the config to config/optional should be enough to fix that.

Fixes the compatibility with PHP 8.2

There are 2 version, on declaring the property, the other creating a simple variable. The last version seems more logical, as the property is not used anywhere so it seems useless.

The patch uses the second variant.

Here is the correct patch, the previous is invalid.

This is not my day... Here is the correct patch, I hope.

This still not closed, after all these years ... hmm

Updated the MR to make it green
Used @Berdir #211 suggestion about the some errors.
+ Some new PHP issues that add errors for tests.
Also merged the latest dev version of module.

What else is needed here?

p.s. i think we need to use the MR, instead of patches - to join our efforts ... and maybe hide the patches.

I agree, the patches should be hidden and work should continue in the MR. Hiding patches.

There are several Remaining tasks in the IS that need to be reviewed. If they're already fixed, then the IS should be updated.

Sorry, patches are still helpful for some people.

Patch applied cleanly to latest dev.

I can now add reverse relationships to parent entities as expected.

If the Gitlab Ci is green, and the tests pass seems like we should be close?

Any word on what is needed still to get this added into a release?

MR patch that is compatible with 1.10 module version. Works for me.

I tried patch #176 and patch #219 and they both solved the issue so the referenced content showing up in views (#176 with an older, stable release of the module, and #219 with the latest dev release).

However, I'm not able to remove a paragraph from a view with either version/patch.

If I edit a node and remove a paragraph, the view still includes the removed paragraph. As a contextual filter I tested both "Paragraph revision: Parent ID" and "Paragraph: Parent ID" and added also tested with the filter criteria "Paragraph revision: Is Latest Revision", to see whether it makes a difference.

Unfortunately it didn't help and now I'm left with a "ghost paragraph".

EDIT 17.5.2024: After digging a bit deeper I realised I simply hadn't configure the relationship properly. The view has to be set up correctly so paragraphs from old node revisions don't show up anymore. Turns out my comment is unrelated and not a bug, but everything works as designed.

I personally think that this last comment is not related to the issue tackled here unfortunately.

Your issue seems to be that the there are still paragraph entities having as parent ID your host entity which - from a query perspective - is correct. Maybe your solutions lies on the functionality of paragraphs to remove orphaned paragraphs.

Individuals can generate patches from Merge Requests. Having both patches and MRs in the queue, especially in an 8 year old issue with over 200 comments, will slow down progress.

For example, there's no MR (or interdiff) for #220 so changes are no longer being tracked, which makes it more difficult for someone to decide what to test. If the patch in #220 is different from the patch in #219, then the MR needs to be updated.

Hmm, you might be right @vensires, it could simply be related to the Paragraphs module. There are still some bug reports and forum posts about orphaned paragraphs, so that seems to be a thing.

I thought it might have to do with this issue since the node edit form doesn't list the (not anymore) referenced paragraph anymore (so the paragraph shouldn't be "related" to the host anymore) and "Delete orphaned composite entities" on /admin/config/system/delete-orphans didn't remove any paragraphs.

Tested #220 and works as intended.

After switching from D9.5 to D10.2 I updated patch from #158 to #220 and it works well again.

This needed a rebase for me.

Happy that this is close, I posted a review with a few things that should be fairly easy to address.

Did some manual testing and this is quite challenging. I know a huge number of people use this and I wanted to get this merged, but it's a lot and complex.

Right now, the MR *attempts* to define a by-id and a by-revision-id relationship, both direct and reverse.

However, they have the same keys on the views data definitions, so in practice, only by-id is defined. By-id uses the "By id: " prefix in the label, which is really confusing to users IMHO, it certainly confused me and took me quite a long time to figure this out.

Additionally, it also defines by-id and by-target-and-host-revision-i references in a loop, which in practice results in _another relationship that does exactly the same and those really are visible duplicates, because they're defined on the respective column for views and not the field name.

My guess is that over time, things conflicted, were refactored and got copy pasted and merged resulting in this duplicated definition.

The problem is that both current by-id and the overwritten by-reference-id relationships from the base/data table are kind of wrong. If you have a situation where a default revision of a host entity references a non-default revision of a target entity, both relationships will always show the default revision, because by-revision-id really just joins through the revision table implicitly and will still use the default unless you specifically use fields of the revision relationship:

SELECT "paragraphs_item_field_data"."id" AS "id", "paragraphs_item_field_data"."langcode" AS "paragraphs_item_field_data_langcode", "field_paragraphs_demo_paragraphs_item_revision_field_data"."vid" AS "field_paragraphs_demo_paragraphs_item_revision_field_data_vi"
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_paragraphs_demo} "node_revision__field_paragraphs_demo" ON paragraphs_item_revision_field_data.revision_id = node_revision__field_paragraphs_demo.field_paragraphs_demo_target_revision_id AND node_revision__field_paragraphs_demo.deleted = '0'
INNER JOIN {node_field_revision} "field_paragraphs_demo_paragraphs_item_revision_field_data" ON node_revision__field_paragraphs_demo.revision_id = field_paragraphs_demo_paragraphs_item_revision_field_data.vid
WHERE "paragraphs_item_field_data"."status" = '1'
LIMIT 11 OFFSET 0

In practice, this should currently rarely happen, because ERR attempts to keep the default revision in sync for entities like paragraphs.

Still not entirely sure what to do with this. Possibly something like this:

* Regular reference to the target entity, replacing the current by-id relationship label
* New regular reference to the target entity *revision*, this will replace the currently overwritten one and will always be the correct data/revision, but revisions are a bit limited in views, you can for example apparently not render them.
* A single reverse relationship for both the default and the revision table. The default table will only show the host entity and the revision table will only show the host entity revision option. So the current "HostEntity revision using FIELD" relationship will go away when you have a view of TargetEntity (e.g. paragraphs) and not revisions, since per the query above, it's the same, just an doing an extra join.

This means that existing views relying on the patch might be broken as some relationships will no longer exist, not under their current identifiers anyway.

The MR diff cannot be applied to a stable tag (i.e. 8.x-1.12) due to the changes in tests/modules/entity_composite_relationship_test/entity_composite_relationship_test.info.yml. The attached patch does not include any tests changes so that it can be used in a composer build.

hi
i confirm the issue mentioned by @recrit . And it's provided patch #231 solve the issue for me

Thanks

I have tested the patch from #231 on a site with Drupal Core 10.3.8, Entity Reference Revisions 8.x-1.12 and Paragraphs 1.18 installed. I can confirm that this is fixed when I have added the "Articles with a field_paragraphs set to the Paragraph." relationship.

I just added a Paragraph field(field_paragraphs) to the Article content type and created a simple view showing Paragraphs with a Relationship and Contextual filter of "Parent ID (Paragraph)".

Thank you very much!

When generating a views report involving paragraphs after upgrading to PHP8.3, I get the following error:

Deprecated function: Creation of dynamic property Drupal\entity_reference_revisions\Plugin\views\relationship\EntityReferenceRevisions::$first_alias is deprecated in Drupal\entity_reference_revisions\Plugin\views\relationship\EntityReferenceRevisions->query() (line 88 of /var/www/html/web/modules/contrib/entity_reference_revisions/src/Plugin/views/relationship/EntityReferenceRevisions.php)

Convert the dynamic property "$this->first_alias" into a standard PHP variable "$first_alias", as it is not used anywhere else.

I have updated the existing merge request with this change.

Just to clarify, @jlscott's comment above is not out of scope; it's an issue introduced directly from the code of this MR as he described in #3492736-3: Deprecated function: Creation of dynamic property. It's not clear to me though - just be reading the comments at least - whether the points noted in #230 are addressed or not. Checking the code, I think it's still well set as "Needs work".

This patch in Comment #231 solved the problem for me as well.

I didn't manage to apply the patch (5.diff or other) via composer with Drupal 11.1.1, but I did it manually (incorporating the changes in 6e180912) and my view seems to work just fine. Fetches fields from the referencing node and filters using those fields.

Patch in Comment #231 solved the problem for me as well

I confirm patch from comment #231 worked for me as well. Module version is 8.x-1.12.

The patch from #231 is working for me as well. @berdir are there outstanding issues that still need to be addressed here?

Patch from #231 is working for me as well.

I was going to RTBC this but there seems to be a failing test... I will echo people above, #231 patch totally fixes the reverse relationship to the host. I was wondering why it thought vid was reasonable to match entity ids.