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.
Cloning a field from one entity type to another leaves the cloned field with a config dependency on the storage on the source entity type.
This is automatically updated and fixed on next config import.
Comment | File | Size | Author |
---|---|---|---|
#5 | 2849461-5.patch | 988 bytes | arthur_lorenz |
Comments
Comment #2
geek-merlinUps, ran into this. 'drush cim -y' seemed not to fix this here. Even worse, when i delete the source field storage, the cloned field (containing the dependency) is deleted. Raising prio thus.
Comment #3
arthur_lorenz CreditAttribution: arthur_lorenz at 1xINTERNET commentedI came across the same issue and had to manually remove the dependency from yml files and import it again. Very inconvinient.
Comment #4
joachim CreditAttribution: joachim as a volunteer commentedThis module only really gets attention from me when I'm using it for site building... if someone could work on a patch that would be great! :)
Comment #5
arthur_lorenz CreditAttribution: arthur_lorenz at 1xINTERNET commentedProblem was that when a new field storage was created the new field referred to the old storage. My patch fixes that.
Comment #6
joachim CreditAttribution: joachim as a volunteer commentedThanks for the patch!
Possibly just a nitpick, but:
when would it not be an instance of that?
Comment #7
arthur_lorenz CreditAttribution: arthur_lorenz at 1xINTERNET commentedIt's possible that this variable doesn't exist at this point, e.g. if no new storage needed to be created.
Comment #9
joachim CreditAttribution: joachim as a volunteer commentedAh ok.
I think in that case it makes more sense to say
because what we care about is whether the variable was set, not what type it is.
I've committed the patch with that change.
Thanks again!