Add body field picker w default to wizard & processing

The WIP is currently pretty close to what is needed (only tested on 11.1). inside function createContentMigration something similar to the comment set , work on $process['body_field'] . If anyone else wants to fiddle with the body field assignment in migrate entity set stage, I think that is the last major thing to resolve.

I think it is correctly auto selecting 'body' in Drupal 11.1 if that is the name of the body field.

Marking it as a major, I think we need this fixed to deal with Drupal CMS.

The form has a kind of warning message on it if the field is unselected. It should tolerate being unselected without killing the migration (which is the current case with 8.x-3.x HEAD) but we want to avoid this.

got welcome assistance from mikelutz and benjifisher on slack:: notes:

Even looking at MR 40, I am not sure what the issue is.
In the MR, I see a form where the user gets to select a field. From the help text, the idea is to migrate the main content from the WP post into that field.
What happens after that? Is the strategy to create a migrate_plus.migration.* config entity based on the choices made in that form?
Another option would be to use hook_migration_plugins_alter() to change the field based on the choices made in that form.

At a quick glance, I think you are on the right track. Here’s the fixes you need:
In the wordpress_content yml file, change
'body/value':
- plugin: get
source: content
'body/summary':
- plugin: get
source: excerpt
to
_content/value: content
_content/summary: excerpt

And in the generator change

$process['body_field'] = $this->configuration[$wordpress_type]['body_field'];
// @todo more body field
// body/summary = 'excerpt'
// body/value = 'content'

$process['body/format'] = [
'plugin' => 'default_value',
'default_value' => $this->configuration[$wordpress_type]['text_format'],
to
$process['_content/format'] = [
'plugin' => 'default_value',
'default_value' => $this->configuration[$wordpress_type]['text_format'],
$process[$this->configuration[$wordpress_type]['body_field']] = '@_content';

You may want some constraints or error checking around $this->configuration[$wordpress_type]['body_field'] to make sure you aren’t overwriting any other processes, I’m not sure, I don’t have a big picture of the module’s workings, but the above changes should do what you are trying to do from what I can see at a quick glance.

But that should work whether $this->configuration[$wordpress_type]['body_field'] ends up being ‘body’ or some other long format text field.

If you want to default to body if the configureation is null, you can add a default by changing $process[$this->configuration[$wordpress_type]['body_field']] = '@_content'; to $process[$this->configuration[$wordpress_type]['body_field'] ?? 'body'] = '@_content'; or something like that, but it looks like your from will return body if that’s where the destination should be. Looks like it has an option to not import it anywhere though, so wrap that generator section in an if (!empty($this->configuration[$wordpress_type]['body_field'])) check probably.

Ok tested on 11.1 and 10.4 I think this is ready to go. Includes UI improvements on form elements, BodyFieldSelectForm, static function getBundleFieldnameOptionsFromFieldmap on importwizard to make field selectors work better. changes to wordpress_content.yml, the migration generator body field handling. it was a lot of improvements. really solid.

It also became apparent that the /other/ steps do not force the field to be assigned to the content node - it lets you pick any field regardless of bundle. so to clarify that more UI messages added for now (could be enforced better later by tweaking the getBundleFieldnameOptionsFromFieldmap to cases there there is no "drupal_content_type" selected, that is fields which are being assigned for the entire migration group, not just one content type. or, they could be reorganized and split per content type (post/page) fully. body field does work this way now, in any case that pattern could be followed, or a second migration group created).

I think this covers our main D11 release blocker but would be great to get plugins migration extensions manager working as well.

hongpong → credited mikelutz → .