🇫🇷France @erwangel

I tried the patch from #25 on D10.3.10. Patch applies but does not work.

Sorry to reopen this but I find this wording very confusing: To add a translation, you must modify the configuration. Which configuration ? I had to check all kind of settings/configurations, in structure (content type, content type field), in settings (region and languages, content language and translation, configuration translation), in module settings (I faced this problem while translating meta settings with metatag module) etc., before I realize that I just had to change something in a field of the present form!

So I suggest to change this message to To add a translation, you must modify at least a field on this form.

erwangel → created an issue.

erwangel → created an issue.

Don't worry about my previous (#7) message. Composer reacted this way because I had manually modified a file to resolve the "parent url not translated issue" ( https://www.drupal.org/project/media_parent_entity_link/issues/3316244 🐛 Generated URL of parent entity is not translated Postponed: needs info )

8x.1.3 works now with responsive images. Thank you for the quick fix!
I had some trouble with composer require 'drupal/media_parent_entity_link:^1.3' who asked to Discard changes [y,n,v,d,s,?]? especially when the composer help is nos so helpful: should I "discard changes and apply the update" or "stash changes and try to reapply them after the update" ? I answered yes to the first option but if such question may be useful with "composer update" I think we should avoid this question with "composer require" which is supposed to download the entire project over the old version.

erwangel → created an issue.

Tested #22 on Drupal 10.3.6. Patch applied and everything looks okay.

Thank you. I've seen you released a new version so I updated and everything looks good nnow.

erwangel → created an issue.

The error still occurs when formatting media entities with colorbox. In my case media field in views.

Warning: Undefined array key "#entity_type" in Drupal\colorbox\Plugin\Field\FieldFormatter\ColorboxEntityReferenceFormatter->settingsForm() (line 213 of /path_to_site/modules/contrib/colorbox/src/Plugin/Field/FieldFormatter/ColorboxEntityReferenceFormatter.php).

I'm still getting this error when editing remote video type (admin/structure/media/manage/remote_video)

Deprecated function: Calling static trait method Drupal\oembed_providers\Traits\HelperTrait::disabledProviderSecurityWarning is deprecated, it should only be called on a class using the trait in oembed_providers_form_media_type_edit_form_alter() (line 61 of /path_to_site/modules/contrib/oembed_providers/oembed_providers.module).

Using: oEmbed Providers 2.2.0, Drupal core 10.3.6 , php 8.3.12

erwangel → created an issue.

Sorry, in the above 1st case it was my fault, I had [view:total-rows] instead of [view:page-count]. So the problem is that [view:page-count] displays [view:current-page] + 1 instead of the 'The total page count'.

Other info that may be of interest: if I use Header > Global > Result summary tokens "@current_page -- the current page number" and "@page_count -- the total page count", they display correctly.

I applied the MR. [view:current-page] seems to be correct now. [view:page-count] gives inconsistent results.

- On a view with a total of two pages, it gives (mini pager)
It looks like there is a relation between the items/page setting and the displayed 'page-count'
[items per page 16]
first page 1/17 (1 + 16 ?)
second page 2 /26 (16+9 ?)
[items per page 10]
1st page: 1/11 (1 + 10)
2nd page: 2/21 (11+10)

- On another view with a total of 4 pages, it displays (full pager)
1st page: 1/2
2nd page: 2/3
3rd page: 3/4
and so on

- Same as previous with another view with 576 page (same behavior with full and mini pager)
1/2, 2/3, 3/4, ..., 574/575, 575/576

I agree with Vasike. I'm using this almost daily. Very useful to update nodes between development/stage/live sites, especially when one uses content nodes as landing pages with layout_builder and its settings accordingly.

No more have had this problem since 3.0.3

Patch worked for me.

erwangel → created an issue.

erwangel → created an issue.

erwangel → created an issue.

erwangel → created an issue.

I know this is an old tree but I think it's time to wake it up. As the patch is for 7.x which comes to end of life, I changed version to 2.0. Any chance to see this feature ported to views_infinite_scroll 2.0 (Drupal > 10) ? Combining infinite scroll and manual load link is a really useful feature especially for sites having a lot of pages and could complete the "Initially load all pages up to the requested page" option which can lead to page crash if the requested page is a high number.

erwangel → created an issue.

I came to the same error while uninstalling the deprecated module (in D10.3.1) layout_builder_expose_all_field_blocks with drush pm:uninstall.

TypeError: Cannot assign Drupal\mail_login\AuthDecorator to property Drupal\security_review\Plugin\SecurityCheck\NamePasswords::$userAuth of type Drupal\user\UserAuthInterface in Drupal\security_review\Plugin\SecurityCheck\NamePasswords::create() (line 67 of /path_to_site/web/modules/contrib/security_review/src/Plugin/SecurityCheck/NamePasswords.php) #0 /path_to_site/web/core/lib/Drupal/Core/Plugin/Factory/ContainerFactory.php(21): Drupal\security_review\Plugin\SecurityCheck\NamePasswords::create()

Then while accessing admin/config/security-review: WSOD with the following

TypeError: Cannot assign Drupal\mail_login\AuthDecorator to property Drupal\security_review\Plugin\SecurityCheck\NamePasswords::$userAuth of type Drupal\user\UserAuthInterface in Drupal\security_review\Plugin\SecurityCheck\NamePasswords::create() (line 67 of modules/contrib/security_review/src/Plugin/SecurityCheck/NamePasswords.php).

No problem to access admin/config/people/mail-login

Rules has now a 4.0 version.

I followed vselivanov way (#5 of Closed #3463528: cannot install 6.0.0-alpha8 on drupal 10.3.1) but Quiz is still blocking any module update with composer. I am on Drupal 10.3.1 and I had previously updated Rules to the 4.0 branch. Here is what I get:

  Problem 1
    - Root composer.json requires drupal/quiz dev-3463528-cannot-install-6.0.0-alpha8, it is satisfiable by drupal/quiz[dev-3463528-cannot-install-6.0.0-alpha8] from vcs repo (git https://git.drupalcode.org/issue/quiz-3463528.git) but drupal/quiz[dev-4.x, dev-5.x, dev-6.x, dev-6.0.x, dev-7.0.x, 4.x-dev (alias of dev-4.x), 5.x-dev (alias of dev-5.x), 6.0.0-alpha1, ..., 6.x-dev (alias of dev-6.x), 7.0.x-dev (alias of dev-7.0.x)] from composer repo (https://packages.drupal.org/8) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.

Same issue with "request_path" plugin after updating to D10.3.1. This is very blocking issue. We need a quick fix by the rules maintainer as downgrading to previous drupal version is not an option while this implies database looses, and moving to ECA not an option either when other modules rely on rules.

Patch doesn't apply on gin login 2.1.3. It was working before update.

Same problem here, with facet 3.0.0-beta1, search_api_solr 4.3.3 and drupal 10.2.6. Unable to save the form at admin/config/search/facets, getting wsod with the message above

Begging of the debug trace:
Drupal\facets\FacetListBuilder->submitForm()
call_user_func_array() (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 597)
Drupal\Core\Form\FormBuilder->processForm() (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 224)
Drupal\Core\Form\FormBuilder->getForm() (Line: 94)
Drupal\Core\Config\Entity\DraggableListBuilder->render() (Line: 23)
Drupal\Core\Entity\Controller\EntityListController->listing()
call_user_func_array() (Line: 123)

There are two sources relying to View Solr Search (page, and block), there is not so much to configure a part the Filter key. Fields are present by default in solr index but I see no way to add a facet block in block layer.

erwangel → created an issue.

The new dev looks fine. It works on all my media types. I had a look in your code and it seems the right approach. However it produces the default language links as pointed in issue 3316244 (url not translated) 🐛 Generated URL of parent entity is not translated Postponed: needs info . Have a look there; I commented it and proposed a working solution.

Also I noticed that $formatters are defined in InitialSettingsService as ['image', 'responsive_image']. I tested and it's okay with both of them, but what about other formatters that modules may add (I have blazy and colorbox, but also image_field_tokens, I don't know where the last comes from perhaps token module). I understand we can't plan ahead what formatters may be available there. Perhaps make it clear in documentation and presentation page that the module acts only on core 'image' and 'responsive_image'.

Blazy is widely used and it may be worth having some kind of compatibility. I tried to add 'blazy' in the $formatters array, the 'link to parent' option appeared in formatter's settings but it had no effect on display. I was not surprised as Blazy has it's own 'link to' called 'Media switcher' but it's mostly for switching to colorbox or other lightboxes supported by this module and anyhaw it lacks an option to 'link to the parent'.

I think we can consider the $sources issue fixed and if you think a solution to make the module compatible with other formaters is possible, perhaps open an other issue.

What about this ?

  // ------ Added line ( 45 of last dev - media_parent_entity_link_media_view() ) 
  //        to get the current language then set the right translated link
  $language = \Drupal::languageManager()->getCurrentLanguage();
  foreach ($components as $componentkey => $component) {
    if (!empty($component['third_party_settings']['media_parent_entity_link']['link_to_parent'])) {
      if ($entity->_referringItem) {
        if ($entity->_referringItem->getParent()) {
          if ($entity->_referringItem->getParent()->getParent()) {
            /* @var \Drupal\Core\Entity\EntityInterface $parententity */
            if ($parententity = $entity->_referringItem->getParent()
              ->getParent()
              ->getValue()) {
              if (!$parententity->isNew()) {
                try {
                  // ------ Set the right translated link here ------
                  //$url = $parententity->toUrl();
                  $url = $parententity->toUrl('canonical', ['language' => $language]);
                }
                catch (Exception $exception) {
                  $url = FALSE;
                }
                if ($url) {
                  ...

In some of my tests it gives the right links

No more warnings after applying #4 on ffs-2.0.x-dev and D10.2.6.

Confirmed working by me too.

"Private images" appeared as an extra media type in my settings after the upgrade from Drupal 7 to 9. And I think one has to create this type if he wants to store images in a Private file system path (see settings @ /admin/config/media/file-system). The image field (field_media_image) of media image type doesn't permit to chose the storage on uploading; you have to define it in settings (see @ /admin/structure/media/manage/image/fields/media.image.field_media_image). So if for some of your images you want a private storage (outside of site root) you have to define a new media type (p.e. private_images) and set the appropriate storage. You can still access private images for display through styles but not directly by their url.

I'll come back in a few days to test the new dev version. Thank you for making it.

Footnotes 4.0 works fine with no dependency to fakeobject. Not sure but, if I noticed well, it (or composer) even removes fakeobjects and Ckeditor 4 while updating from fn3 to 4

I tried MR 8 on a Drupal 10.2.6 which applied with no problem on ffs 2.0.x-dev. Using it on a media module image field (admin/content/media) as well as directly on a node with media field, the remote image is downloaded and listed in admin/content/files but when saving the media or the node I get:

Error: Object of class Drupal\media\Entity\MediaType could not be converted to string in Drupal\Component\Render\HtmlEscapedText->__construct() (line 31 of /path_to_site/web/core/lib/Drupal/Component/Render/HtmlEscapedText.php).

I can confirm #147: with smart_trim module enabled, try to format a body field in views using smart_trim formatter and you get the error.
The error also occurs with several other modules. I'm not using them but I landed on their issues while seeking a solution to this error message. I set some of them for reference in "relationships".

Thank you for the quick reply. So quick that I haven't seen the 3.0.4 was already up including the fix; I was trying to patch the 3.0.3 until composer shows me it was updating to 3.0.4! Everything is working perfectly now.

erwangel → created an issue.

erwangel → created an issue.

patch #30 worked for me (gin_login 2.0.4 on D core 10.2.5)

erwangel → created an issue.

erwangel → created an issue.

Although that's confusing for people wanting to install the module. You require it with composer as "front" but you have it to enable it with drush as "front_page". confusing and not very intuitive when drush tells you "Unable to install modules front due to missing modules front." I had to look in the modules's directory to realize that its "real" name was "front_page" and not "front". I think a quick fix will be useful so more people could install it and you could gain more feedback.

Still not working. With the suggested changes I was able to access the settings page but once I validated the form I got again a wsod and was logged out with a RuntimeException: Failed to start the session. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 173 of /path_to_site_root/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).
Cache rebuild didn't help, it just permit access to the login page but once the credentials validated, white scren again. I had to uninstall the module to get the site back.
In the php logs Maximum execution time of 40 seconds exceeded and Allowed memory size exhausted as well as Warning: session_start(): Failed to decode session object. Session has been destroyed in Drupal logs which just explains the symphony session failure.

#4 worked for me, especially after watching the video (it helps to place the two js lines). Thanks pradipmodh13

Sorry, this was due to a drush&devel issue as I had upgraded devel just before.
See issue and solution @ https://github.com/drush-ops/drush/issues/5941

erwangel → created an issue.

I tested patch from marco.aresu (#10) and it works but page attachments remain in http. For the moment I used hook_page_attachments_alter to correct this with a str_replace("http:", "https:", $url) looping through
$attachments['#attached']['html_head_link'][1][0]['href']
I suppose the other patches don't correct this either.

erwangel → created an issue.

Problem encountered with user account fields on Drupal 10.2.4.
- Sites's default language is "fr", and two other languages activated "en" + "el"
- In admin's profile Language settings: "Site language" is "fr", "Administration pages language" is "en".
- Field settings "Users may translate this field" is "off"

The problem doesn't occur on all custom fields, but on newly created fields.

Newly created custom fields take original language "en"
Example creating a new "text plain" field. I add translations for "en" and "el"
As all my other fields have original language "fr" (they come from a D7 migration, D7 site wasn't multilingual and had default language "fr"). Wanting to have coherence through languages, I set the newly created field to original "fr" by executing

drush cset field.field.user.user.field_test_text langcode fr
drush cset field.storage.user.field_test_text langcode fr

Result: I have language original "fr" but "en" translation disappeared while "el" is preserved and is still here. I click to add translation "en". The modal window opens but when I save the translation I get

Status message
English translation was not added. To add a translation, you must modify the configuration

I understand that I have to edit the field (supposed to be now in original "fr") and so do I. After saving it, apparently it has been saved in "en" instead of "fr" because I get

Warning message
The configuration objects have different language codes so they cannot be translated:
field.field.user.user.field_test_text: fr
field.storage.user.field_test_text: en

Similar issue with metatag field.

- My conclusion is that whatever the original language is, when the field settings page is saved, drupal reverts the original language to the admin's "Administration pages language". There is some logic there although I could expect save a "fr" version when I edit a "fr" version. But what happens when your site has two admins with different setting for "Administration pages language" in their profile ? Field's original language will be reverted in the admin's language each time one edits the field and such erasing the other admin's translation.
- My recommendation: drupal should respect the field's original language even when the admin's language is different. Perhaps we should have a language selector for the original/default field language at field level like in multilingual content types in case one wants to change the original language instead of the drush "cset" command.
- That said, I don't understand why this happens only to newly created fields and not on old ones (those coming from the D7 migration).

The Ajax issue is still present on 10.2.4. In a custom module I have a very simple form, I simplified the ajax response to jus say "Hello", I switched to the default Olivero theme to be sure there is no interference with any other jquery or ajax call. This form was working with no problem on 10.1.2.

What I noticed in the console display of he error is that whatever the context of my form is used (and so producing variable ajax responses), it always has a "settings"; nul' in the response text. This quote after nul sounds suspect to me.

message: '\nAn AJAX HTTP error occurred.\nHTTP Result Code: 200\nDebugging information follows.\nPath: /path_to_the_calling_page?ajax_form=1\nStatusText: parsererror\n

ResponseText: 

[

{"command":"update_build_id","old":"form-rjF70Nh6-v5uOijTmG0ZX6MHU8dDqTYYjLsJzf79Stk",
"new":"form-LHnajKIYq8szIGH0kkk-4vqtqzU_FsZmY2tLXUHqkqc"},

{
"command":"insert",
"method":"replaceWith",
"selector":"#my_ajax_form_element",
"data":"Hello",
"settings":nul'
​
name: "AjaxError"
​
stack: "@https://my_site.com/core/misc/ajax.js?v=10.2.4:196:32\n@https://my_site.com/core/misc/ajax.js?v=10.2.4:1916:3\n"
​
<prototype>: Error: 
ajax.js:196:32 etc.

Extra line-breaks are mine to make it evident that there is a malformed json array, probably due tho the nul'.

I tried patch 10.2.1 from #35, it worked on the first call of the form (a click on submit button), but it didn't work on the next calls although there was no error displayed on the console.

Changed title to better reflect the issue

Hmm... A bit long the new description. Metatags are not only in content types; we found them in taxonomies, in users, in views, etc... Why not set a second permission ? Two permissions are not too much and could avoid long explanations to say what a permission does and what it does not. Example : the current permission "Who controls the per bundle Metatags settings. And a new one for "Who controls the Metatags content".

Metatags demands quite technical skills or at least knowing to what they serve. Or in a site with large audience, the presence of this field can be confusing to users. For example, in my site I have content types that are reserved to accredited authors. Okay they can be informed and trained on the usage of metatags, but other content types are open to all registered users while some other content types (like forums) are open to even anonymous users. We usually fill default metatags, eventually with tokens. We can not trust all these users that they will fill correctly the metatag fields.

Imagine you have a recipe type where users can post their preferred recipes (I hope you like cooking), SEO is important for this kind of content. You activate default metatags + Schema.org: Recipe. Users will then be faced with several dozens of metatags to fill. And if they search some help clicking the "available tokens" link they will really be... lost in translation.

I think that access of metatags to users should be only an option and by default users should not have access. Metatags is too powerful to leave in the hands of just anyone. I think metatags should behave by default like the other "system" fields (authored, promoted, sticky, alias, ...). I'm not sure but I think this was the case in Drupal 7, anyway I don't remember having to deal this kind of problem in D7.

I was confused by the "admin meta tags" permission scope. Your answer makes it much clearer now. Thank you for taking the time for this.

Damien, I understand that I have to manage permissions but as I wrote "the permission to 'administer meta tags' is set to admin only". Isn't that enough ? With this setting, I don't understand why any other registered user has access to field_metatag too. Secondly, if I remove the field from the user entity, admins will not have access any more. Tercio, what is the benefit of users managing metatags by themselves? Metatags are used mainly for SEO purpose, and seo is not a user's concern.

erwangel → created an issue.

erwangel → created an issue.

erwangel → created an issue.

This is still a big problem on Drupal 10.2

Patch from #2 worked for me too on upf-2.0.0. I had to use patch for D-10 compatibility 📌 Automated Drupal 10 compatibility fixes RTBC before to be able to install the module with composer.

Thank you for this plugin which as it says aims to "reduce the need in custom plugins for each content type"! This MR-88 applied and worked perfectly on D10.2.3 and SCS 1.4.4 for transferring feed entities (type feeds_feed). I just had to change the 'owner' field in the export yaml text ; this is hardcoded, to 'uid'. Perhaps you should set the default name of the entity owner to 'uid' that is more likely to meet than 'owner' or at least set a comment close to the corresponding line in yaml to attract user's attention that they may have to adjust the name of this field. I also had to move by hand the 'source' field which is of type 'uri' but this is rather a general issue, not this plugin's concern, as SCS lacks definition for 'uri' field in SingleContentSyncFieldProcessor.

Finally, there was an other entry remaining in the key_value table:
entity.definitions.bundle_field_map entity_message N;
Deleting it seems the error has gone.

erwangel → created an issue.

Finally, I could achieve the exactly same display with formatter "blazy grid" and adjusting the media display mode accordingly with colorbox formatting. So I can have the contextual links displayed close to the media. So there is no problem and you can close the issue. It's just confusing between "blazy media" and "blazy grid". Perhaps make the difference between the two and the corresponding use cases clearer somewhere in the documentation.

erwangel → created an issue.

Yes, dev version (2024, February 11th) removed the media_colorbox display from all media types and the entry has gone from the database config table as expected.

Installation with #31 and migration steps from #25 worked for me going from D7 to D10.

However I got some errors with quiz_results_answers. I had 189 items in d7_quiz_result which were all migrated, but only 1516 items from the 1869 processed by quiz_results_answers were migrated. Perhaps the non migrated items are unfinished quizzes but there is nothing in migrate:messages that could help to debug. Also while rolling back quiz_results_answers , I got this error:

TypeError: Drupal\quiz\Entity\QuizResultAnswer::getQuizResult(): Return value must be of type Drupal\quiz\Entity\QuizResult, null returned in Drupal\quiz\Entity\QuizResultAnswer->getQuizResult() (line 26 of /path_to_site/web/modules/contrib/quiz/src/Entity/QuizResultAnswerEntityTrait.php) #0 /path_to_site/web/modules/contrib/quiz/src/Entity/QuizResultAnswer.php(162): Drupal\quiz\Entity\QuizResultAnswer->getQuizResult()

The other problem I got is with custom fields (I have a media_field in D7 quiz and question nodes) and usual drupal node fields like published y/n, author/date display, promoted, comments, etc or fields added by modules like metatag (essential for SEO), Any idea how to migrate these fields ? It is impossible to recreate all them as they are not accessible by "Re-use an existing field" and not available in the "Create a new field" options list. But perhaps this is not a migration problem but a limitation of the new quiz module concept. In such case, it is preferable to go the old way with quizzes and questions as nodes rather than trying to recreate a whole distinct entity.

You can close this issue. I've just seen that D10 Paragraphs has its own migration for D7 Field_collection, and it works. So no need of field_collection_to_paragraphs module.

Just to say for others coming here that there are two migrations to execute with drush:
- d7_field_collection_type and
- d7_field_collection:name_of_your_field_collection_type
In my case d7_field_collection_type didn't create the corresponding paragraph fields as I was expecting. They had to be created by hand with the same machine_name as in d7 field collection. So my migration process was the following:
1) Import the nodes or entities containing the data related to the fields used in your field_collection_type
2) drush migrate:import d7_field_collection_type
3) Create manually the fields in the paragraph type as explained above
4) drush migrate:import d7_field_collection:name_of_your_field_collection_type
4) Import the entities using this paragraph type

erwangel → created an issue.

erwangel → created an issue.

erwangel → created an issue.

This seems to be a Drupal function called to get values of entity fields. I removed all media_gallery specific fields that had been created by the d7 migration such as media_gallery_block_columns, media_gallery_expose_block, media_gallery_image_info_where, media_gallery_block_rows, etc. from the Manage form display (admin/structure/types/manage/media_gallery/fields) and I can now edit gallery nodes with no problem. But is this normal behavior ? Should we consider the issue as solved ?

erwangel → created an issue.

The issue is still present with the dev version (25 Oct 2023). it reports the CckIframe despite the comment in the other issue (D7 to D9 Migration (3327719))

@_shY,
1. yes, it is patch from #11
2. As you can see below, it works after your correction! ["drupal/field_collection"] not ["field_collection"]

From the composer require print out:

- Installing drupal/field_collection (dev-4.0.x 81ea688): Cloning 81ea6884dc from cache
- Applying patches for drupal/field_collection
https://www.drupal.org/files/issues/2023-09-13/field_collection-3297187-... → (3297187-11 - Automated Drupal 10 compatibility fixes)

Thanks @_shY and @RogerB for all your guidance!!!

Hi @_shY,
Still no chance, with your command composer.json was indeed update to allow lenient but still compatibility errors:

Problem 1
- Root composer.json requires drupal/field_collection dev-4.0.x -> satisfiable by drupal/field_collection[dev-4.0.x].
- drupal/field_collection dev-4.0.x requires drupal/core ^8 || ^9 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev] but the package is fixed to 10.1.7 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

In my composer I have :

 "require": {
        "mglaman/composer-drupal-lenient": "^1.0"
       ...
  },
    "minimum-stability": "dev",
    "prefer-stable": true,
    "config": {
        "allow-plugins": {
            "mglaman/composer-drupal-lenient": true
            ...
        },
    },
    "extra": {
        "patchLevel": {
            "drupal/core": "-p2"
        },
        "patches": {
             "drupal/field_collection": {
                "3297187-11 - Automated Drupal 10 compatibility fixes": "https://www.drupal.org/files/issues/2023-09-13/field_>
            }
        },
        "drupal-lenient": {
            "allowed-list": ["field_collection"]
        }
    }
...

Well, this is no more a real problem as I could proceed with a manual patching and installation but just trying to understand why lenient is not working to do it the composer way...

erwangel → created an issue.

I'm using Media gallery 2.2.3 with Drupal 10.1.7 but there is no folder named media_gallery_migration. Instead there is media_gallery_import folder and the corresponding module is marked "incompatible with version 10.1.7" by Drupal Extend. So what is the solution we have to migrate media galleries from D7 to the latest D10 ?

Indeed this may be a solution and even better that what I suggested (option to select bundles) but we will still need an option to apply or not to summary which inherits the text format of the main field (body). I think most people don't want to have summaries with plenty links. Also I didn't check how such glossified summaries appear in metatags or in other token based fields.

erwangel → created an issue.

I couldn't install it event with #11 + mglaman/composer-drupal-lenient. "composer.json" was correctly updated with the composer config --merge --json extra.drupal-lenient.allowed-list '["field_collection"]' instruction but the composer require gave the following error:

Problem 1
- drupal/field_collection dev-4.0.x requires drupal/core ^8 || ^9 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev] but the package is fixed to 10.1.6 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- drupal/field_collection 4.0.x-dev is an alias of drupal/field_collection dev-4.0.x and thus requires it to be installed too.
- Root composer.json requires drupal/field_collection 4.0.x-dev@dev -> satisfiable by drupal/field_collection[4.0.x-dev (alias of dev-4.0.x)].

I then tried to remove composer.lock and install mglaman/composer-drupal-lenient globally as indicated on its page but this doesn't seem to be the road as it gave a huge list of require incompatibilities. I finally ported the patch modifications manually and installed the module without composer.

Any new development on CER migration from D7 to D10 ? How can we map cer_left and cer_right (and cer_bidirectional ?). Do they have any relation with the D10 "prepend" and "append" ?

Thank you RogerB for your quick answer. However I still have a problem reported by composer

- Root composer.json requires drupal/field_collection dev-4.0.x -> satisfiable by drupal/field_collection[dev-4.0.x].
- drupal/field_collection dev-4.0.x requires drupal/core ^8 || ^9 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev] but it conflicts with your root composer.json require (10.1.6 as 9.5.11).

My question is
1 - should I try it with the option --with-all-dependencies, and in such case is there any risk to import update dependencies to D9.5.11 for other parts/modules that are properly running as D10 compatible ?
2- do I have to remove the line "drupal/core": "10.1.6 as 9.5.11" after installation in order to avoid other modules being downloaded with a D9 version ?

My request is a bit different but concerns the same issue: is it possible to have field_image migration to media entity as an option ? In other words, is it possible to leave image_field as image (and migrate associated items without changing the field type) and only change file(image) field to media file ?

Can not apply #11 because of info.yml is patched for core version requirements (4.0.x-dev requires D9 is patched for D10)
See @ https://www.drupal.org/project/drupalorg/issues/3066468 📌 Packaging info from .info.yml often creates conflicts when patching (ddo) Active
Is there any other option than manual patching ?