Problem/Motivation
The Paragraph::label()
logic tries to provide information if the parent entity is referring to the paragraph in a previous revision, but it doesn't work in some scenarios.
Steps to reproduce:
- Node A with a paragraphs field
- Create a node with a paragraph
- Create another revision of the node, where the paragraph item was removed
- Load the paragraph by code and call $paragraph->label()
You expect to see something like "Node title (previous revision)", but instead you have an empty string.
Proposed resolution
- Fix the logic to provide correct label in previous revisions
- Create an additional helper method ParagraphInterface::getOrphanStatus()
which will help, among other things, to make that logic cleaner
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#24 | 2954039-24.patch | 5.61 KB | Berdir |
| |||
#21 | 2954039-21.patch | 6.15 KB | neeravbm |
| |||
#20 | 2954039-18.patch | 6.14 KB | Dennis Cohn |
#17 | interdiff-16-17.patch | 406 bytes | seanB |
#17 | 2954039-17.patch | 12.75 KB | seanB |
|
Comments
Comment #2
marcoscanoFirst shot, just fixing the current logic without the helper method.
I've noticed that we are not using
t()
for the suffix added here. Is that intentional? (I did not change this).Also, the test could probably just be a kernel test, but I'm not sure if the setup code for that justifies the effort?
Comment #4
miro_dietikerThe missing t() is accidental.
Comment #5
BerdirWhile working on this, lets also make sure that we add an hasField() check. and mabe include the summary in the orphaned fallback label, like "Orphaned @type: @first_20_characters_of_summary" or so.
I would invert it and do an early return inside the foreach if have a match. Then you can drop the if/else and just return the fallback title if the foreach never matched.
And yes, both variants should use t() with placeholders and not just combine the strings together.
Can't we make this a kernel test, I don't think this contains anything that is UI relevant and a kernel test would be a lot faster.
Comment #6
Berdir1. On the other hand, 1) the orphaned stuff is hopefully temporary, so lets not do too much there, feel free to skip that.
Comment #7
marcoscano@Berdir thanks for reviewing!
I was quite far in the orphan helper stuff when I saw your review, so here it is... :/
But feel free to indicate if you think it's definitely not worth doing, I can go back to the previous approach if it's the case. IMHO though I have the feeling that even if we solve the garbage collection soon, it may still be useful to differentiate "used in default revision" vs "used in previous revisions" scenarios? or it could also be helpful in implementing the garbage collection itself i guess...
Will work on refactoring the test next.
Comment #8
BerdirTo be clear, I just meant that a better label for a completely orphaned label might not be needed, as the goal is to prevent that from happening, Non-default revision is still useful, as it knowing what the status is.
Comment #9
marcoscanoAnd here with the updated test.
Comment #11
marcoscanoComment #12
miro_dietikerThis is a wrong condition.
A Paragraph could be moved with drag & drop from one parent host to some other. A previous revision of a previous parent would point to the paragraphs entity, but the parent id would have changed.
Comment #13
miro_dietikerWohoo, the key problem here is that these base fields are not revisionable...
(And the parent pointer also doesn't point to the parent revision.)
That's where things fall apart.
This results in inability to simply query in revisions and figure out where the current paragraph is a child.
A workaround could be implemented (by looping and querying all paragraph fields) but that's not worth doing here.
Instead i would propose
Comment #14
marcoscano@miro_dietiker true, thanks! :)
I've created #2954512: Store information about a paragraph's parent revision and #2954513: [PP-1] Properly detect if a paragraph is orphan as follow-ups, and documented the limitation of the current implementation.
Comment #15
marcoscanoComment #16
askibinski CreditAttribution: askibinski as a volunteer and at ezCompany commentedHere is the same patch as #14 but against 1.3, for anyone who needs it.
Comment #17
seanB@askibinski You removed
use StringTranslationTrait;
which causes the patch to fail. Attached a new patch!Comment #19
seanBThat interdiff was supposed to be a .txt file obviously...
Comment #20
Dennis Cohn CreditAttribution: Dennis Cohn commentedHere is the same patch as #17 but against the latest 8.x-1.x, for anyone who needs it.
Comment #21
neeravbm CreditAttribution: neeravbm at Red Crackle commentedHere's the same patch as #18 re-rolled against the latest version of 8.x-1.x-dev.
Comment #22
miro_dietikerWe do not have a real guarantee that a parent is always set. See also below early exit for getOrphanStatus()
Comment #23
johnchqueOh what happened with the tests from #17?
Let's add it back.
Comment #24
BerdirRefactored this (more accurately, started from scratch, so no interdiff), dropped the orphan API and just inlined the the checks. Did readd the tests and refactored them to only test label().
Comment #25
miro_dietikerVery nice progress and clean test cases, thus committed.
Comment #27
chr.fritschFixing the status