Problem/Motivation
If you have paragraphs that are no longer being referenced by the default revision of their parent, then nothing is shown at all.
This is extremely confusing because in extreme cases, it is possible that you see usages on the overview, but then the detail page shows nothing.
The problem is that getParentEntity() returns the default revision, and that might no longer use the paragraph. But it still makes sense to show it.
The only case when it should be shown as an actual orphan is when the parent entity no longer exists.
Proposed resolution
Remove the field values check.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Comments
Comment #2
berdirSo this basically removes a lot of code and it also ensures that it always shows the label of the initial paragraph (e.g if you have a paragraph container and that container is no longer referenced).
I think the current behavior is worse than showing paragraph orphans that might not be shown anymore, it will at least show a "(previous revision)" suffix.
And instead of the referenced issue to improve handling *if* there are orphans, we are working on the ability to clean up & delete orphans, which will not just solve the problem on the list page but also the total count. Just like my proposal for #3002332: Track composite (e.g. paragraph) entities directly and only as their host would, but that's another one of those things that I don't know if/when I'll find time for it.
Comment #3
berdirAs an alternative, it would be possible to build a query that covers all revisions to make sure that there is still at least one revision of the parent using that paragraph. But again, IMHO we need to solve this by getting rid of orphans and not handling them better.
Comment #5
berdirOk, I do remember a bit more now. These workarounds exist because the current labels of paragraphs are indeed *really* bad.
I updated #2954039: Fix ::label() logic and add a ParagraphInterface::getOrphanStatus() helper and I improved the labels a lot, so we should postpone this on that I guess.
Comment #6
marcoscanoFor visibility, we might end up marking this as won't-fix in the 2.x branch, since in a theoretical 3.x branch being cooked in #3060802: Refactor module architecture in a simpler, opinionated and more performant approach this wouldn't be an issue anymore.
Comment #7
berdirReroll for latest beta. While there's still plenty of room for improvements, this is IMHO a considerable improvement and the referenced paragraphs issue has been committed and released a while ago.
Comment #8
berdirUpdated the test assertion with what is now shown, which I think shows nicely how this is better instead of just ignoring this as the usage *is* still recorded and counted, which is very confusing to users.
Comment #10
marcoscanoI agree that the workaround is no longer needed. Thanks for working on this!
Committed to dev.