Migrate File Entities to Media Entities

[der-On]

With the planned webbuilder all image fields are implemented as media fields. The media Library allows users to reuse media and allows a better collaboration for multiple users.

It would be good to migrate existing image file fields to media fields in the legacy content types.

Information about that can be found here: https://www.drupal.org/project/migrate_file_to_media

[der-On]

@FlxAlbroscheit I would like your opinion about this.

[FlxAlbroscheit]

Great idea, thanks! In the next days I will try to give "migrate file to media" a try on our demo-system to check if it is compatible!

[FlxAlbroscheit]

Hi @der-On, I have contributed a custom module that provides a migration script for turning the following image-fields into media-(image-)fields:

• le_event.field_le_event_image
• le_akteur.field_le_akteur_image

The full documentation can be found in the README.

If I have overseen any fields in the other content- or taxonomy-types, please let me know! You can find the result of the migrated fields on our staging-system as well.

I guess that it is too early to simply delete the "old" image fields from the configuration as we will need them until the migration has succeeded on the live-system. Nevertheless should/can we already remove these fields from display in forms and views! I have not done that (yet) as my next goal was to sync the master- and develop-branch first.

If I saw it right did you already attach a generic "field_main_image" field to some content-types (e.g. events and blog-articles). Unfortunately have I not found a way to directly map the "old" fieldle*_image-values directly into that new field_main_image; that is why the new field-names are still namespaced (e.g. field_le_event_image_media). If you find a better way, feel free to modify the le_migrate_media module!

Best regards and thanks for your nice work :+1:

[der-On]

Thanks. Will look into it asap. Hiding the old image fields is what I would do, yes.

[der-On]

@FlxAlbroscheit I'm getting [error] Message: Es konnte keine Verbindung zur Datenbank hergestellt werden. Der Server gibt die folgende Fehlermeldung zurück: /No database connection configured for source plugin variable/ when trying to execute step1. Do I need to set some config variables?

[der-On]

@FlxAlbroscheit got it working by adding another database configuration https://www.drupal.org/project/migrate_upgrade/issues/2551147#comment-10222255

[der-On]

@FlxAlbroscheit Now I hit another wall: AssertionError: Cannot load the "file" entity with NULL ID. when running step2

[der-On]

@FlxAlbroscheit I'm almost tempted to code a custom solution that also copies files over to the correct fields. My experience with migrate modules so far was very less then ideal and I actually did things manually instead.

[FlxAlbroscheit]

Hi @der-On, oh noes :( I am so sorry that you had to spent a lot of time for quick-fixing bugs related to the migrates-(upgrades-)module. Honestly speaking: I also felt a bit disappointed by this module when researching a solution for migrating our Drupal 7 non-entity-like contents into Drupal 8 entities/node-types some months ago. The migrate-module felt a bit "overloaded" at that time and none of the provided examples fitted into our use case. That is why I chose to write a custom solution as well; highly procedural, but doing the job well.

Hmm... So what do you think, how can we move on here? Is there any way I can support you? Should I maybe check a second approach to migrate the fields?

[der-On]

@FlxAlbroscheit I will write a custom module, shouldn't be too hard. In general I have the feeling that doing things from scratch in-code-only in Drupal mostly leads to a faster, more stable and performant solutions than doing it "the Drupal way".

[der-On]

@FlxAlbroscheit Please review and merge https://github.com/Leipziger-Ecken/drupal/pull/24

[der-On]

@FlxAlbroscheit as I was required to merge to continue work, I've merged the PR myself.