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.

@ressa,

I'm reworking this currently for the source field to only be visible and applicable to 'entity_reference' AND/OR 'entity_reference_revisions' fields on the entity. The updater wasn't ever really supposed to include other field types in the source dropdown which is perhaps where some of the confusion is coming from. I'm interested in your feedback but conversing this way through comments is not real productive. If you are on slack, reach out to me (my handle is apmsooner) and we could do a screenshare and talk through your ideas. I'm going to keep the mappings separate as merging them together into a single form can get overly complicated to handle with ajax and introduce more bugs.

Thanks @apmsooner I really appreciate your openness to my suggestions. It sounds really great that you are reworking the UI, and only show the source field if it's relevant -- like you write, probably most likely for Paragraph or reference fields. That'll simplify the interface, and make it more immediately understandable. Sadly, I am not on Slack ... but I would be more than ready to try out a test MR (here or in another issue), check out a screenshot with Gimp/Photoshop scribblings on with suggestions, or just in text.

@ressa,

Thank you, I've made several revisions in the dev branch. Tried to revise the updater form with better labels and function to hopefully improve the user experience.

Primary fields to fill:

• Entity type
• Bundle
• Target field

Supplemental fields conditional on field definitions:

• If the selection entity includes a reference field (entity_reference OR entity_reference_revisions):
• Show a "Field mappings source" radios field
• If "Field mappings source" = 'Entity reference'
• Show "Entity reference" select field.
• When selection is made from "Entity reference" field
• Show "Entity reference bundle(s)" field

Drush command has been updated to prompt user to select an updater from list.

Updater logic:

1. If an entity reference field is NOT selected as the mapping source, all fields other than reference types from entity will be available to map. If target field is multi-valued, the updater service will track the highest delta from values of all mapped fields and return empty values for any fields that don't have the same delta match. For example, if field_a has 1 value and field_b has 5 values, the target field will result in 5 values with the mapping for field_a filled for the 1st value and remaining 4 empty. All 5 of field_b would be filled.
2. If an entity reference field IS selected, the field mappings will be comprised of all fields that exist on the target bundles. The updater logic will only take the first value of each field in this case as we are dealing with multiple entity instances at this point and can't account for multi-valued fields for each bundle.
3. If there are no entity reference fields to select from OR the fields mapping source is set to 'Entity', again the mapping fields available and updater logic would be the same as #1.

There were some additional updates also to redirect the form to the mappings on save and some extra validation and such. Let me know what you think?

Thanks for a fast update @apmsooner and keeping the momentum, it helps not having to try to backtrack, and attempt to understand what my ideas and thoughts were some time ago :)

The updates you made are great, even though I haven't yet looked into the more complicated Reference/Paragraphs scenarios.

It's a big improvement that the Paragraph/reference target drop-down is only displayed when it's relevant. That will prevent much confusion.

I suppose it's more or less impossible to reverse the general order, and define data source first, and only then data target, in the second step? (Note, not Paragraph source/target) Because that would logically make more sense, and align with for example rsync (source first, then target). But I assume there are good reasons for the current order, with defining data target first, and only then data source?

Mapping: Some fields seem to be missing

I always start with the simplest option first, from one plain text field to another, and ran into an oddity, where some fields were not available as options at the second step of Mapping, setting the source ... I think it's best to get this sorted out, before proceeding with the more complicated stuff.

So maybe you can try and create a few plain text fields (long and short), and verify if they all show up, as expected or not, in the two steps?

Reverse order on Field source Mapping?

Is it possible to reverse the order, and show "Fields" ("Body", "My field", etc.) first, and then "Default values" ("NULL", "Custom value") in the Mapping drop-down? Since the options under "Fields" are the most relevant ones, I think they should be listed first.

Feature request: Token support in "Value source" field?
A killer feature would be Token support in the "Field Source" > "Custom value" > "Value source" field, since the user could then string together multiple fields, and combine them into a single field. But perhaps that's best dealt with in another issue? I am just thinking , that maybe in this phase, it might be ideal to keep all options in one place, until the dust settles. What do you think?

I suppose it's more or less impossible to reverse the general order, and define data source first, and only then data target, in the second step? (Note, not Paragraph source/target) Because that would logically make more sense, and align with for example rsync (source first, then target). But I assume there are good reasons for the current order, with defining data target first, and only then data source?

Not sure exactly if you mean the main form or mappings. If main form, it's possible to reorder. I guess i put "Target field" first as its always required and the other stuff may not show depending on the fields setup. If you're adamant, i can reverse the order.

Mapping: Some fields seem to be missing

It depends on your field structure of the target and the other fields. The logic matches data types and schema properties to prevent someone from trying to fill a textfield that has a hard length of 255 with a blob of body text. Perhaps its too limiting and adding confusion but the intent was to only show available fields that could actually be properly mapped over and stored without error.

Reverse order on Field source Mapping?

Yes I can certainly make this change. (just pushed a commit for this if you want to refresh).

Feature request: Token support in "Value source" field?

Lets handle this in a separate feature request. I had actually already considered handling token support but just wasn't sure if the community found that useful or not... sounds like it maybe is. I would probably need to limit which target properties could allow this option (e.g. string, text) from source and perhaps do some extra validation during processing to ensure the token value still works with the expected schema. FYI, the custom value source inputs currently match to the targets currently. For instance if you have a boolean data type in a target, you would see a radios TRUE/FALSE widget for the custom value source. And for a textfield, it would have a maxlength property matching the target schema length, and so on. Thats why we would probably need to limit the token support. I alternatively could make an additional dropdown option "Token value" or something and just have a generic freeform input for everything. Again, i would definitely need to validate every value in that case during processing to make sure it can be stored or otherwise skip it and/or log an error. What do you think?

Clarification provided in comment around fields shown. Token support provided for custom value field types of text/textarea.

Sorry, I got side tracked.

Define source first, then target

What I mean is defining the data source in the first step, like right after you click the "Add field updater" button and start creating a field updater, and if you want for example to transfer some text from an integer field to a plain text field.

My suggestion is to first define the source (integer field) and then the target (plain text field) as the last step, on the second screen.

Limitations

It still seems to me that there are some limitations about available fields ... I understand the thought behind it, about being helpful, but I think it should be up to the user to take to not combine fields that don't match ... Perhaps the "limiting helper" can be an optional feature? Or there could be a third section at the bottom, with the fields currently not listed under a "Take care, may not work" header?

Token support

Great that Tokens support might happen, that would be an amazing tool, and could be really helpful, in so many scenarios.

Another thing I thought about, which would be great if token support got added (but maybe takes too much coding to create?) would be a "live preview" below, where a few fields are populated, giving a preview of the resulting text in the target field, according to the tokens, and how they are combined. This would of course probably only be relevant for simpler fields ... But let's maybe look at Token support in another issue, like you suggested :)

1. The source entity is first determined by the selected Entity type and Bundle
2. The Target field depends on step 1 as we need to fetch all fields that exist from those selections
3. The Field mapping source is always going to be assumed the source entity from step 1 UNLESS there are entity reference fields that also exist on that entity in which the user will be presented with that option. The option won't even be visible if there are no reference fields.
4. I made Target field selection happen before optional Field mapping source because the Target field is always required and it seemed more logical to make optional selections appear last to keep it a step by step selection.

Limitations
The available fields are specifically limited to prevent errors. Here's the thing, if a user is trying to map a body field to a boolean value, the updater would fail because a value of long text can't be saved into a column that only accepts 1/0. Yes, I could make it more freeform and just let anything be mapped but to your point of making it useful for non-developers, a site builder may not understand why their configuration is failing without having a deep understanding of the data storage requirements under the hood.

Token support
Token support has already been introduced in latest release. See screenshot: https://www.drupal.org/files/project-images/Screenshot%202025-06-30%20at... → of what this looks like. Token support is limited to string and text mappings for similar reasons around limitations and could technically fail still if too long of a value from the token is inserted into a string field that only allows 255 characters. But anyhow, it provides some additional flexibility to perhaps set some deep nested values from paragraphs or combine multiple values, etc...

There's room to enhance further with additional widgets and validation for the custom value option but the main focus for now was just being able to map like to like values over to a "custom field" and eliminate unnecessary tables, config, etc...

Thanks for the explanation about order of setting target first, then source . It's too bad that we can't define source first, then target as a logical second step, since that would make more sense to me. After all, a source is required in all scenarios, as well.

Though, I am still not sure, if we are talking about the same thing ...

Limitations
About the limitations, I get the thoughts behind. I still do think it's up to the end user, to make sure that moving the data makes sense in the first place, which is also why it would be awesome with an instant preview below.

In that case, the user could immediately see that entering values from a Body field into a Boolean field doesn't really work, whereas in other cases, the user might--for whatever reason--actually want to copy content from a Boolean field to a Body Field, or some other weird scenario we can't imagine.

And like I wrote, having the limiter could be optional, with a "Here be Dragons" warning.

Token support
Getting Token support is fantastic, and just made the module even better, so thanks for adding this! It should totally be mentioned on the project page, at the every top. I see there's an image with Tokens in it already, which is great. Perhaps the project intro text could be updated?:

Allows you to easily copy data from one field to another. With Token support, to rewrite and combine data from multiple fields into a single field.