Views doesn't recognize relationship to host

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. I can't find a rule for this problem Anyone else seing this problem?

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 issue 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 🐛 Views doesn't recognize relationship to host Needs work outlines the need for update_hook as well as #125: Who's Online and Chatbox →

This breaks old views when applied.

I am also having an issue.
My slideshow view
relationship
paragraph referenced by slideshow_paragraph_ref

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

I 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

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

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

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.

So, how can I fix this MR?

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

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

Drupal\Core\Config\Schema\SchemaIncompleteException: 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.

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

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!