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 → .

reverting to active until another patch. xpete reported 📌 Automated Drupal 11 compatibility fixes for wordpress_migrate Needs review :
I tested the 8.x-3.x branch again with version Drupal 10.4.6 and Drupal CMS 1.1.0. It's fixed on version 10.4.6 but with Drupal CMS the Blog and Page fields are not visible on the body field picker so the body still can't be imported.
Drupal CMS don't use text_with_summary. It uses regular text fields. You can read a discussion about it here https://www.drupal.org/project/drupal/issues/3477043 📌 Change automatic body field creation to use formatted text field instead of text_with_summary Active
////
Therefore i would propose that the UI be revised with additional selectors for (text,formatted,long). I think the first dropdown should say it is for "content and excerpt/summary, essentially two fields in one" in the UI help. Then a second and third dropdown, which would select both (text,formatted,long) and (text, formatted, summary) - if selecting the latter no content would go in summary.

then the third dropdown allows selecting both (text,formatted,long) and (text, formatted, summary) fields as well.

The submit or validator should enforce each field selected is unique.

in processing the body fields, now the @_body/summary needs to be associated to that field and @_body/content to the selected one. it should be OK to leave one both or all unselected. (currently it is OK and processes OK i believe).

also i think it could be OK, but would take more trickery, to allow the first dropdown to put into (text, formatted, summary), AND allow the latter two fields to split off either / both body and summary into other text,formatted,long) and / or (text, formatted, summary) fields. in other words there would have to be more implementation to save in both, but i think it is OK to dupe stuff at migrate time that way.

Otherwise (not preferred), the field design could disable 2+3 if 1 is selected anything and vice versa at the front end, and enforcing similar at submit time.

Okay here is the WIP on MR 42. https://git.drupalcode.org/project/wordpress_migrate/-/merge_requests/42

The data is definitely not saving anymore (under any configuration!) but I think the wizard UI and form submit validator is pretty good. Back to the drawing board again later - some subtle improvement should get it working. (this was mainly generated by Claude AI).

I haven't tested MR42 and I am not sure if I understood your idea but I think you could do this with only 2 dropdown. The current dropdown could be changed to have fields of type text and when a field of that type is chosen another dropdown is shown to select the field where the summary is stored if there's any. Maybe the second field can be optional.

don't bother testing till the fields are saving imo.

the idea is that there is the combo field choice first (text_with_summary) that saves in the sub fields, or alternative, the options to split full body vs summary into two text fields (of both types, with and without summary). i see what you mean about showing a conditional field but this struck me as easier to execute.

re conditionals i am also wondering re the Text formats picker. as with some other steps in the wizard it doesn't check if that text format you picked is actually permitted on the text field you select. (likewise it doesn't check if the image field you pick is assigned to the node type). I don't want to treat this as a blocker because, with a little additional help text we can walk people thru it for now.

WIP latest: I found the logic errors on the isset (it needed to consider strings of length 0 - avoiding empty() ) however things are hanging now.

I think missing attachments can also make it hang but that is a separate issue. ✨ attachments / featured images not fault tolerant if missing Active . Something is still mixed up but made incremental progress anyway.

Thank You for working on this! Forgot to mention that the "Featured images" picker also does not shown the "field_featured_image" field.

Just tested your 3516531-add-body-field branch and the "Excerpt/summary only field" is not listing the "field_description"

The "field_description" type is "string_long" and the "field_featured_image" type is "entity_reference".
So you need to add the "string_long" to the summary picker field and the "entity_reference" type to the "Featured images" picker.

regarding entity reference for images, we need this one to be committed - ✨ Import as media Needs review - i did a bit of refactor and hit a small snag with the iterator being a little messy earlier this month.

on the plus side string_long isn't that bad to include. ref: https://www.drupal.org/docs/drupal-apis/entity-api/fieldtypes-fieldwidge... → - https://gist.github.com/cesarmiquel/48404d99c8f7d9f274705b7a601c5554