Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When a block has paragraphs, those should be cloned as well because otherwise they point to the same internal id. Setting as a bug report because it's very confusing when editing those blocks.
Comment | File | Size | Author |
---|---|---|---|
#6 | 3077172-6.patch | 2.65 KB | swentel |
Comments
Comment #2
swentel CreditAttribution: swentel at eps & kaas for Dropsolid commentedComment #3
swentel CreditAttribution: swentel at eps & kaas for Dropsolid commentedComment #4
AndyThornton CreditAttribution: AndyThornton commentedThanks for raising this ticket and your contribution to this module.
Yes, you are right 'probably any entity reference'. While many people use Paragraphs, this issue is likely a problem in other Drupal architectures too. With Drupal 8 us developers/site builders are encouraged to make use of the Entity API, and with convenient tools like Drupal Console making the process easier, it is very feasible and desirable to create custom entities (i.e. particularly for more complex composite field scenario where the Field API strains). We do tend to fall back to Paragraphs for also doing the job that Field Collection helped with in Drupal 7, but, personally, I prefer creating custom entities as architecturally it just keeps things closer to the actual 'real world' that is being modeled (i.e. I can name thing what they are ... rather than thinking of them as a subtype of this thing that is called 'Paragraph').
This is no small task, I am sure - not least that there may be some entity reference that make no sense to clone. For example, if a Block has a reference off to a 'type' that had more info on it - concretely, imagine using a vocab to control a certain thing such as 'document type'. In that case one might only want to clone the reference, not the entity being referenced.
Perhaps they'd be a way to identify these based on their entity reference definition. I am not 100% sure, but maybe if the ER is 'translated' then it implies that it should be cloned, but if it is not translated then it should be cloned.
Another challenge, of course, is how deep do you go? It is not at all unfeasible to think of a Block containing a Paragraph and that Paragraph contain a Media entity ...
Comment #5
swentel CreditAttribution: swentel at eps & kaas for Dropsolid commentedYep, this is going to be challenging indeed.
To prepare for it, #3077352: Take over SetInlineBlockDependency is a first step since that helps paragraphs already too.
Comment #6
swentel CreditAttribution: swentel at eps & kaas for Dropsolid commentedFirst take. Fixes a bug too for inline usage.
This adds support for entity_reference_revisions (currently our major problem at a project)
Comment #8
swentel CreditAttribution: swentel at eps & kaas for Dropsolid commentedI've committed the patch already so we can use the dev release for further testing.
Still todo:
- add tests
- which other types are we going to support
- should there be a fallback? e.g. the cloning of the reference fails, so it's probably better to clear the values of the cloned parent
- recursive ?
Comment #9
swentel CreditAttribution: swentel at eps & kaas for Dropsolid commentedClosing this as this works fine for us right now. Adding tests is a bit complex at the moment, if weird things popup, I'll get to that then :)
I'll open new issues (or others can) if new cases come up too.