Feedback about the process and documentation

Thanks @ressa,

I'll check into the errors you're having on Drupal 11. I had only tested this on 10.4.x and didn't experience any issues like you're describing but nonetheless, i'll see if i can reproduce and patch it up quickly. Should be an easy thing to reconcile.

I added a 5th step to quick start linking to example update hook.

For more clarity: The module itself doesn't import anything. It uses the configuration settings including the defined mappings to copy data from 1 or more fields of same schema type to target field. The "Source field" is optional as its not needed normally unless you need to copy from a entity_reference_revisions field (ie; paragraphs) which in itself is composed of its own entity type/bundle that has its own fields. In your example, you can certainly set the other body field as a "Source field" or you can leave that field empty and that field along with any other (non entity_reference_revisions fields) would be available in the mappings. So you basically can pull data from multiple field properties to fill the target field. I will sort out this bug first and then add a video soon that covers all the steps including the update hook declaration which should hopefully simplify the explanation.

Again, no import is happening, when the update hook runs, it's querying for all entities of the defined entity_type/bundle and does a batch update to the target field from source(s).

Thanks for a fast reply, and for making the module @apmsooner. I am sorry that I collected so many, and disparate tasks in a single issue, and I have created an issue for each, to deal with them individually.

I tried in Drupal 10 as well, and also get the errors there ...

Thanks for explaining some more details about how the module works, like the schema thing. I did try to map and copy content from a "Body" field to a "Plain text", and got problems -- there were no fields under "Field source" in the "Mapping" page (only "None", "NULL" and "Custom value") ...

Different types of "Source" ...

Fundamentally, there is something about the naming of fields which seemed not intuitive to me ... A video would be all right, but I think it would be a better idea to make the elements in the GUI intuitively understandable.

New users, like myself, who jump into using the module wonder --

How can Source be optional? Or is the "Source" mentioned under "Add field updater" not the same "Source" as on the "Mappings" page?

And now, I went back and actually took the time to read the Quick start, and the penny dropped, and I experimented a bit more ...

If at all possible, I think the "Source field" should only be displayed on the "Add field updater" if it makes sense -- i.e. if the "Target field" is a Paragraph. For a "Plain text" field, it would never be relevant, I would think?

Thinking more about this, how about flipping the order from selecting Target first, to selecting Source first? Then, the allowed Target field schema types can also be limited to only be the same schema types as the Source.

In other words: If the user selects a "Plain text" field as Source, then only fields of type "Plain text" should be offered in the resulting Target drop-down. In the image below, the have already selected "Text1" and "Plain text" schema fields such as "Text2" were made available.

Similarly, if the user select a Paragraph field as Source, the drop-down should only offer Paragraph type fields. Also, where it's relevant a "sub drop-down" with extra value options should be presented as well, in this case, values such as target_id.

Would that be possible?

These aren't bad ideas but there's reasoning for the current setup.

1. The source field is optional. If no source field is selected, all fields on the entity are available for mapping.
2. The target field is required therefore logically put first.
3. I don't really want to combine the mappings into the same form as it would require alot of additional ajax and therefore make it way more cumbersome and error prone.

Maybe there's some opportunity for better labels and help text still. I would like to make it more intuitive, just not sure how to communicate best that the source field is really for targeting specific fields from a referenced entity (ie; paragraphs, blocks, etc...). Maybe we change the label to something like "Source from referenced entity" and limit the dropdown to those field types? The whole reasoning for the source field is basically that we have to associate the mappings to the entity with the fields. If the desire is to map from fields on a paragraphs entity, only the fields specific to the paragraph entity should be in the mappings.

Let me dig back into this and try to figure out some better solutions. It's been a while as I've been heads down on updates for the custom_field module but I have time now to get back into this one and make some improvements. I appreciate the suggestions and ideas.