What about a feature to move fields from one entity to another? Use case example -- fields were created on nodes using content profile in D6, I want to move them to either the user or a Profile 2 entity in D7. The field data is migrated fine and ends up on a D7 node, just need a way to switch the entity the fields are associated to (see http://drupal.org/node/560324#comment-4817254).
Another use case -- I have a bunch of populated image nodes and now would like to use media module and move the field data to a media entity from a node entity.
No code to provide at this point, but it should be possible.
Comments
Comment #1
KarenS CreditAttribution: KarenS commentedThis never got assigned a version, so fixing that. I may need this to upgrade D6 Content Profile to D7 Profile 2, using the method I suggested in http://drupal.org/node/560324#comment-4817254 and http://drupal.org/node/560324#comment-5278166, i.e. do the normal D6 to D7 upgrade which will leave me with my profile fields on nodes, then move those fields to a Profile 2 profile.
I can't be sure I will get to this, but a feature like this could be very useful for this and other use cases.
Comment #2
KarenS CreditAttribution: KarenS commentedActually this would also make it possible to move the Content Profile fields to either the User entity or a Profile 2 entity. Something like:
1) Upgrade normally. You will end up with content profile fields on nodes.
2) Use Field tools to clone the fields from the old profile node to either the profile 2 entity or the user entity to create a place for the data to go.
3) If the entities don't already exist (like Profile 2 entities), create them, using the old values, in a batch process.
4) If the entities already exist (like the User), identify the field on the source that maps to the id of the new entity, load the entity, add the values, and save it, also in a batch process.
So this functionality needs a way to identify the source entity/bundle, the new entity bundle, the field on the source that maps to the new entity, if the entity already exists, or an indication that a new entity should be created from the source. Then a batch process to do the actual update.
Comment #3
joachim CreditAttribution: joachim commentedThis was discussed at a recent Party/CRM code sprint, and I forgot this issue had been filed.
I wrote a spec here of how this might work: #1602696: field mover module. Creating new entities on the fly is something I hadn't thought of, which certainly has a use case :)
I think it perhaps should be its own module rather than live here.
Comment #4
q0rban CreditAttribution: q0rban commentedHmm, I guess that makes this "won't fix".
Comment #4.0
q0rban CreditAttribution: q0rban commentedSpelling mistake.
Comment #5
frobI am switching this back to active, more than one module can live in a project and I think even though this feature should be its own module it should be in the field_tools project.
Comment #6
nwoodland CreditAttribution: nwoodland commentedIn case anyone comes across this thread like did and finds this useful, I had a need to move a bunch of fields from a paragraph type to a node type in Drupal 8, and I used this quick and dirty code to accomplish that (only caveat is I needed to manually set the form and display configs for these fields, though I'm sure that could've been automated as well):
Comment #7
colanNew features go into HEAD, and can then be backported if there's interest.
Comment #8
AnybodyStill makes sense to either disallow to copy a field from one entity type to another OR (even better) copy it over correctly.
Comment #9
joachim CreditAttribution: joachim at Factorial GmbH commentedThis is getting confusing -- the IS is talking about moving DATA, but the code in #6 is showing moving FIELD DEFINITIONS.
For moving data -- use Migrate. Out of scope for this module.
For moving field definitions -- I'll take a patch :)
Comment #10
Anybody@joachim: Would you agree with my point in #8?
It's quite dangerous, if someone clones a field across entity types currently, isn't it?
I suggest only showing current entities fields, until this is properly implemented
If you agree, I'll provide a patch for that until someone has the time to fully implement support for that.
Comment #11
AnybodyUpdate: I created a separate issue for that now: #3345004: Cloning to other entity type bundles should not be allowed, until it's supported would appreciate a short feedback @joachim before I start with the implementation.
Comment #12
joachim CreditAttribution: joachim at Factorial GmbH commented> It's quite dangerous, if someone clones a field across entity types currently, isn't it?
I suggest only showing current entities fields, until this is properly implemented
It should be fine, but you have to:
a. check the field name isn't already used on the destination entity type
b. clone the field storage as well as the instances
Comment #13
AnybodyThanks @joachim!! :) So this issue can still be used to implement the full support!
Comment #14
joachim CreditAttribution: joachim at Factorial GmbH commentedOk.
I'm going to put this issue to wontfix, since you're working on the new one, and this issue's summary is about field data, which Field Tools isn't going to support.