πŸ‡ΊπŸ‡ΈUnited States @dan612

Portland, Maine
Account created on 19 October 2015, over 8 years ago
  • Drupal Developer at AcquiaΒ 
#

Merge Requests

More

Recent comments

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

attaching a basic file to get started. i believe using this will at least stop the warnings/error during a migration and will allow this new field type to be set, but i believe we need to define how the underlying data gets mapped to the new field as well.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

made an MR to show i am still noodling on this 😬

I re-ran the make -B command, then my process was as follows:

  1. Run sh ./scripts/test-unvetted-modules-composer-installability.sh recommendation.json /tmp/test-general-installability-unvetted 10.2.3
  2. Go to new directory and run composer install --dry-run
  3. Move each failure to curated.json with a note as to why it fails to install, and vetted: false
  4. Run composer remove <package> then re-run composer install --dry-run

Basically just worked through all the various failures during composer installation, went to the projects to review why it failed and then updated the note with the findings. Then my pipelines jobs started to fail due to PHP 8.2 incompatibility - so I made a few more updates to address that after changing versions and testing again locally

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine
πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

😁 i did! however I am not sure we are talking about the same issue. I encountered 2 types of issues when working on this:

  1. Issues where version constraints differed between curated.json and generated.json -- as you described in your previous comment, these were mostly submodules and easy to fix by manually changing the version.
  2. Modules which get picked up by generated.json but are not installable via composer

The second issue above is where this is stuck, none of these modules - https://www.drupal.org/files/issues/2024-02-10/d10-composer-install-brea... β†’ - were able to be added to a D10 project via composer, cleanly. For example drupal/field_properties:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/field_properties ^1.0@alpha -> satisfiable by drupal/field_properties[1.0.0-alpha2].
    - drupal/field_properties 1.0.0-alpha2 requires drupal/core ^8 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev] but the package is fixed to 10.2.3 (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.

or smartmenus:

[6:53:43] ~/Sites/d7-upgrades/the18-d10 [main] $ lando composer require 'drupal/smartmenus:^2.0@beta'
./composer.json has been updated
Running composer update drupal/smartmenus
Gathering patches for root package.
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/smartmenus ^2.0@beta -> satisfiable by drupal/smartmenus[2.0.1-beta1, 2.0.1-beta2].
    - drupal/smartmenus[2.0.1-beta1, ..., 2.0.1-beta2] require drmonty/smartmenus 1.1.1 -> found drmonty/smartmenus[dev-master, v0.9.6, v0.9.7, 1.0.0, 1.0.1, 1.1.0] but it does not match the constraint.

So for these...i feel like we would have to vet each on against D10 and provide a curated recommendation in order for this to be complete.

To be honest a lot of these packages look as though they are in alpha/beta and dont have a stable release to begin with...which makes me wonder why the crawler script was even picking them up because it should only get D10 packages when:

 * For the given project, try to derive a D7-D10 migration recommendation.
 *
 * Projects are ignored if:
 *
 * - Their owner has declared that it has been replaced.
 * - Their status is anything other than receiving maintenance fixes only or
 *   under active development (e.g. not obsolete).
 * - They do not have a Drupal 7 release.
 * - They do not have a Drupal 10 release.

the above snippet was taken from crawl.php

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Hi - thank you for the update! 😁

I think since focal_point_focus β†’ is now showing compatibility with Drupal 10 we should break it out into a separate issue where we can manually vet/test the path from D7 --> D10 and update our recommendation based on the results. That way we can update the recommendation & merge in without relying on completion of this issue - did that and can update status in that issue!

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Nice! I think that resolved the issueπŸ˜…πŸ€ž. I updated the recommendation and tested it locally. Video here 😎 β†’

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

ooooh, ok! i ran this instead ... git diff origin/4.x -- ':!./tests/*' > ~/Desktop/3416551-change-settings-fix-only.patch and attached that πŸ˜„

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

In order to install this module with composer you must add the following to your project composer.json prior to requiring this module

       {
            "type": "package",
            "package": {
                 "name": "contextly/contextly-kit",
                 "version": "5.0.10",
                 "type": "drupal-library",
                 "dist": {
                      "url": "https://assets.context.ly/archives/kit/contextly-kit-5.latest.tar.gz",
                      "type": "tar"
                 },
                 "autoload": {
                      "classmap": [
                              "server/",
                              "server/includes/",
                              "server/includes/assets/",
                              "server/includes/package/"
                      ]
                 }
            }
        }

See this part of the readme.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

bat has a pretty robust ecosystem that will require substantial testing. Now that auth0 recommendation has landed πŸ“Œ D10: Re-vet Auth0 (drupal/auth0) Fixed , I think my inclination is to merge what we have in here but leave this and the bat issue open as there are higher priority modules to vet. What do you think? πŸ₯Ή

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Pipelines is quite angry with me but im not sure if that much noise is normal or not 😬

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Leave it to me to not read instructions πŸ˜†

There were a few places where "modern Drupal" didn't fit...it read awkwardly. I tried to update things within context to what seemed fit πŸ˜€

Couple screenshots of the changed ui:

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

This patch is failing to apply for me locally for some reason, not sure why. The part which is failing is related to the additions in the test fixture:

diff --git a/tests/fixtures/drupal7.php b/tests/fixtures/drupal7.php
index 630b6d0..9b8a86d 100644
--- a/tests/fixtures/drupal7.php
+++ b/tests/fixtures/drupal7.php
@@ -82,6 +82,18 @@ $connection->insert('variable')
     'name' => 'acquia_subscription_data',
     'value' => 'a:12:{s:9:"timestamp";i:1234567890;s:6:"active";s:1:"1";s:4:"href";s:83:"https://insight.acquia.com/node/uuid/1b2c3456-a123-456d-a789-e1234567895d/dashboard";s:4:"uuid";s:36:"1b2c3456-a123-456d-a789-e1234567895d";s:17:"subscription_name";s:4:"Test";s:15:"expiration_date";a:1:{s:5:"value";s:19:"2042-12-30T00:00:00";}s:7:"product";a:1:{s:4:"view";s:14:"Acquia Network";}s:16:"derived_key_salt";s:32:"1234e56789979a1d8ae123cd321a12c7";s:14:"update_service";s:1:"1";s:22:"search_service_enabled";i:1;s:6:"update";a:0:{}s:14:"heartbeat_data";a:4:{s:11:"acquia_lift";a:3:{s:6:"status";b:0;s:8:"decision";a:2:{s:10:"public_key";s:0:"";s:11:"private_key";s:0:"";}s:7:"profile";a:5:{s:12:"account_name";s:0:"";s:8:"hostname";s:0:"";s:10:"public_key";s:0:"";s:10:"secret_key";s:0:"";s:7:"js_path";s:0:"";}}s:22:"search_service_enabled";i:1;s:12:"search_cores";a:7:{i:0;a:2:{s:8:"balancer";s:28:"useast1-c1.acquia-search.com";s:7:"core_id";s:11:"TEST-123456";}i:1;a:2:{s:8:"balancer";s:28:"useast1-c1.acquia-search.com";s:7:"core_id";s:19:"TEST-123456.prod.v2";}i:2;a:2:{s:8:"balancer";s:28:"useast1-c1.acquia-search.com";s:7:"core_id";s:19:"TEST-123456.test.v2";}i:3;a:2:{s:8:"balancer";s:28:"useast1-c1.acquia-search.com";s:7:"core_id";s:18:"TEST-123456.dev.v2";}i:4;a:2:{s:8:"balancer";s:29:"useast1-c26.acquia-search.com";s:7:"core_id";s:24:"TEST-123456.prod.default";}i:5;a:2:{s:8:"balancer";s:29:"useast1-c26.acquia-search.com";s:7:"core_id";s:24:"TEST-123456.test.default";}i:6;a:2:{s:8:"balancer";s:29:"useast1-c26.acquia-search.com";s:7:"core_id";s:23:"TEST-123456.dev.default";}}s:21:"search_service_colony";s:28:"useast1-c1.acquia-search.com";}}',
   ])
+  ->values([
+    'name' => 'acquia_application_uuid',
+    'value' => 's:36:"297dddeb-a730-422d-bf87-f0fb4b0eaa31";',
+  ])
+  ->values([
+    'name' => 'acquia_identifier',
+    'value' => 's:10:"ABCD-12345";',
+  ])
+  ->values([
+    'name' => 'acquia_key',
+    'value' => 's:32:"0db2c95529d76edfc282e9eed0800b21";',
+  ])
   ->execute();

 $connection->insert('system')

Not sure what about this is problematic. The message from patch output is:

patch '-p1' --no-backup-if-mismatch -d 'docroot/modules/contrib/acquia_connector' < '/app/patches/breaking-test.patch'
Executing command (CWD): patch '-p1' --no-backup-if-mismatch -d 'docroot/modules/contrib/acquia_connector' < '/app/patches/breaking-test.patch'
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/tests/fixtures/drupal7.php b/tests/fixtures/drupal7.php
|index 630b6d0..9b8a86d 100644
|--- a/tests/fixtures/drupal7.php
|+++ b/tests/fixtures/drupal7.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.

1 out of 1 hunk ignored

patch '-p0' --no-backup-if-mismatch -d 'docroot/modules/contrib/acquia_connector' < '/app/patches/breaking-test.patch'
Executing command (CWD): patch '-p0' --no-backup-if-mismatch -d 'docroot/modules/contrib/acquia_connector' < '/app/patches/breaking-test.patch'
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/tests/fixtures/drupal7.php b/tests/fixtures/drupal7.php
|index 630b6d0..9b8a86d 100644
|--- a/tests/fixtures/drupal7.php
|+++ b/tests/fixtures/drupal7.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.

1 out of 1 hunk ignored

patch '-p2' --no-backup-if-mismatch -d 'docroot/modules/contrib/acquia_connector' < '/app/patches/breaking-test.patch'
Executing command (CWD): patch '-p2' --no-backup-if-mismatch -d 'docroot/modules/contrib/acquia_connector' < '/app/patches/breaking-test.patch'
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/tests/fixtures/drupal7.php b/tests/fixtures/drupal7.php
|index 630b6d0..9b8a86d 100644
|--- a/tests/fixtures/drupal7.php
|+++ b/tests/fixtures/drupal7.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.

1 out of 1 hunk ignored

patch '-p4' --no-backup-if-mismatch -d 'docroot/modules/contrib/acquia_connector' < '/app/patches/breaking-test.patch'
Executing command (CWD): patch '-p4' --no-backup-if-mismatch -d 'docroot/modules/contrib/acquia_connector' < '/app/patches/breaking-test.patch'
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/tests/fixtures/drupal7.php b/tests/fixtures/drupal7.php
|index 630b6d0..9b8a86d 100644
|--- a/tests/fixtures/drupal7.php
|+++ b/tests/fixtures/drupal7.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.

1 out of 1 hunk ignored

   Could not apply patch! Skipping. The error was: Cannot apply patch ./patches/breaking-test.patch

The only info i can really glean from that is can't find file to patch at input line 5 - but i have no idea why this would be the case.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

#13: are you proposing to not fix #3416551: Update settings migration to target state API? πŸ€” See my comments on the MR, I think I see what's wrong πŸ€“

Thanks! Also thank you for the guidance on rebasing to remove all the make commits interactively - that make the whole process much smoother.

I made some adjustments to https://www.drupal.org/project/acquia_connector/issues/3416551 πŸ› Update settings migration to target state API Needs work - not sure about how to do the minimum_version approach via annotation. Its like i would need a maximum_version as well which would be applied to the v3 source plugin.

The patch fails to apply cleanly for me for some reason β†’ despite passing all tests. Not sure what is going on there but trying to sort it out locally.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Oh! Whoopsies, good find 😬 After making these changes I altered the tests a little bit and tried running them. I was met with:

  www-data@2fdc9bf0644d:/app/docroot/core$ ../../vendor/bin/phpunit  ../modules/contrib/acquia_connector/tests/src/Kernel/Migrate/d7/MigrateAcquiaConnectorConfigurationTest.php
  PHPUnit 9.6.16 by Sebastian Bergmann and contributors.

  Testing Drupal\Tests\acquia_connector\Kernel\Migrate\d7\MigrateAcquiaConnectorConfigurationTest
  E                                                                   1 / 1 (100%)R

  Time: 00:09.830, Memory: 10.00 MB

  There was 1 error:

  1) Drupal\Tests\acquia_connector\Kernel\Migrate\d7\MigrateAcquiaConnectorConfigurationTest::testConfigurationMigration
  PHPUnit\Framework\Exception: PHP Fatal error:  Uncaught AssertionError: The container was serialized. in /app/docroot/core/lib/Drupal/Core/DependencyInjection/ContainerBuilder.php:88
  Stack trace:
  #0 /app/docroot/core/lib/Drupal/Core/DependencyInjection/ContainerBuilder.php(88): assert(false, 'The container w...')
  #1 [internal function]: Drupal\Core\DependencyInjection\ContainerBuilder->__sleep()
  

I was able to get around this by implementing the same solution from here - https://www.drupal.org/project/drupal/issues/3197324 πŸ› Exception trace cannot be serialized because of closure Needs work .

I made a few updates to the MR which i believe also allows it to have a passing test now 😎

  www-data@2fdc9bf0644d:/app/docroot/core$ ../../vendor/bin/phpunit  ../modules/contrib/acquia_connector/tests/src/Kernel/Migrate/d7/MigrateAcquiaConnectorConfigurationTest.php
  PHPUnit 9.6.16 by Sebastian Bergmann and contributors.

  Testing Drupal\Tests\acquia_connector\Kernel\Migrate\d7\MigrateAcquiaConnectorConfigurationTest
  .                                                                   1 / 1 (100%)

  Time: 00:08.521, Memory: 10.00 MB

  OK (1 test, 7 assertions)
  

Do you mind explaining more about how I might use the minimum_version here? My conditions are:
if >= 7004, run variables to state
if < 7004, run prior config migration
ill need to ponder more about how to accomplish this with annotation based 🫣

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Currently we have 171 generated recommendations. After this there are 1423 generated recommendations.

I realized this morning that what I was doing in my previous efforts was just re-vetting all those modules which failed to install cleanly...which is what we want to do anyway but there are probably higher priorities πŸ˜„. that being said, i think i should break some of my comments in #7 πŸ“Œ D10: Run crawler script to update generated.json Active into tickets as the work (or groundwork) is already done now.

New idea. What if we just omit all the d10-install-breaking-modules from generated.json? This would mean we still get an additional ~1,200 modules which install successfully on D10 and it would unblock this issue, which relies on basically vetting every module which fails to cleanly install via composer.

Locally I reset things back to recommendations-10, re-ran make -B and cofirmed the mass update in generated.json. At this point my statistics showed:

$ cat ./statistics.txt                                                                       
410 recommendations (curated)
  (of which 364 contrib recommendations)
1480 recommendations (generated)
1790 recommendations (total)
  (of which 89 vetted recommendations)
    (destination: targeting 73 composer packages)
    (destination: targeting 121 Drupal modules)
    (source: migrating from 231 Drupal modules)
    (source: obsoleting 63 Drupal modules)
  (of which 63 obsolete recommendations)
  (of which 3 patched recommendations)
  (of which ~ 310 generated recommendations overridden by curated recommendations)
41 unique patches, or 13.7 (avg) per patched recommendation for a total of 41 (36 max)
  (of which 3 patches are not migration-specific, but necessary bugfixes)

Then i added the modules i knew from previous efforts to be breaking to a new file, iterated over it and removed those from generated.json. Then re-ran the CI process locally to make sure things worked. Whenever there was a failure, i removed it from generated.json and tried again. I attached the list of packages which caused failure β†’ . The result appears to be a passing CI pipeline now πŸŽ‰. I will leave it up for discussion what other implications this has and if it is a good idea or not 😬

I believe it is an improvement 🀞 because the majority of these modules should work on Drupal 10 (considering they have a D10 compatible release tagged). So even though we haven't tested them or vetted migration paths, i believe it makes things easier for the end user because they will come preinstalled (but not enabled) if they had them on Drupal 7.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ changed the visibility of the branch 3420498-update-generated to hidden.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Here are the current issues:

  Problem 1
    - Root composer.json requires drupal/ace_editor ^2.0 -> satisfiable by drupal/ace_editor[2.0.0-alpha1, 2.0.0-beta1, 2.0.0-beta2, 2.0.x-dev].
    - drupal/ace_editor[2.0.0-alpha1, ..., 2.0.x-dev] require npm-asset/ace-builds ~1.0 -> could not be found in any version, there may be a typo in the package name.

This one will get addressed with https://www.drupal.org/project/acquia_migrate/issues/3417209 πŸ“Œ Obsolete vetted modules to review - 1/10 Active .

  Problem 2
    - Root composer.json requires drupal/agls ^1.2 -> satisfiable by drupal/agls[1.2.0, 1.x-dev].
    - drupal/agls[1.2.0, ..., 1.x-dev] require drupal/metatag ^1.0 -> found drupal/metatag[dev-1.x, 1.0.0-beta1, ..., 1.x-dev (alias of dev-1.x)] but it conflicts with your root composer.json require (^2).

I would argue that the recommendation for metatag @ version ^2 supersedes drupal/agls (based on installation usage). So drupal/agls should be moved to curated.json with a note stating that it needs to be manually installed due to the need to downgrade metatag.

  Problem 3
    - Root composer.json requires drupal/codemirror_field ^2.0 -> satisfiable by drupal/codemirror_field[2.0.1].
    - drupal/codemirror_field 2.0.1 requires codemirror/codemirror5 ^5 -> could not be found in any version, there may be a typo in the package name.

This module requires manual installation due to needing to alter the repositories section of composer.json by hand. Should update this in curated.json

  Problem 4
    - Root composer.json requires drupal/commerce_realex ^3.0 -> satisfiable by drupal/commerce_realex[3.0.0, 3.0.x-dev].
    - drupal/commerce_realex[3.0.0, ..., 3.0.x-dev] require annertech/rxp-js 1.3.1.21 -> could not be found in any version, there may be a typo in the package name.

The recommendation from the previous version of recommendations.json still applies to this module.

  Problem 5
    - Root composer.json requires drupal/contextly ^3.0 -> satisfiable by drupal/contextly[3.0.0].
    - drupal/contextly 3.0.0 requires contextly/contextly-kit 5.0.10 -> could not be found in any version, there may be a typo in the package name.

This recommendation still applies to the current module.

  Problem 6
    - Root composer.json requires drupal/feeds_ftp_fetcher ^2.0 -> satisfiable by drupal/feeds_ftp_fetcher[2.0.0-alpha1, 2.x-dev].
    - drupal/feeds_ftp_fetcher[2.0.0-alpha1, ..., 2.x-dev] require ext-ftp * -> it is missing from your system. Install or enable PHP's ftp extension.

This seems to be more an issue with the CI - i think we need to enable a new extension for this to install. Locally I am able to install it.

  Problem 7
    - Root composer.json requires drupal/lightgallery ^1.4 -> satisfiable by drupal/lightgallery[1.4.0, 1.x-dev].
    - drupal/lightgallery[1.4.0, ..., 1.x-dev] require sachinchoolur/lightgallery ^1.2.21 -> could not be found in any version, there may be a typo in the package name.

The same recommendation apples from the previous version.

  Problem 8
    - Root composer.json requires drupal/monster_menus ^9.1 -> satisfiable by drupal/monster_menus[9.1.0-rc1, 9.1.0-rc2, 9.1.0-rc3, 9.1.0].
    - drupal/monster_menus[9.1.0-rc1, ..., 9.1.0] require drupal/core ^9.4 || 10 -> found drupal/core[9.4.0-alpha1, ..., 9.5.x-dev, 10.0.0] but it conflicts with your root composer.json require (10.2.3).

This module might be ok to use (haven't tested) but cannot be installed due to a typo in its composer.json file, here. Based on the module .info file this should be compatible with ^10 which would install on 10.2.3, but this requirement in composer.json prevents installation.

  Problem 9
    - Root composer.json requires drupal/signaturefield ^1.1 -> satisfiable by drupal/signaturefield[1.1.0, 1.x-dev].
    - drupal/signaturefield[1.1.0, ..., 1.x-dev] require npm-asset/signature_pad ^2.3 -> could not be found in any version, there may be a typo in the package name.

The same recommendation applies.

  Problem 10
    - Root composer.json requires drupal/smartmenus ^2.0 -> satisfiable by drupal/smartmenus[2.0.1-beta1, 2.0.1-beta2, 2.0.x-dev].
    - drupal/smartmenus[2.0.1-beta1, ..., 2.0.x-dev] require drmonty/smartmenus 1.1.1 -> found drmonty/smartmenus[dev-master, v0.9.6, v0.9.7, 1.0.0, 1.0.1, 1.1.0] but it does not match the constraint.

This module requires manual installation. See here.

  Problem 11
    - Root composer.json requires drupal/swagger_ui_formatter ^4.0 -> satisfiable by drupal/swagger_ui_formatter[4.0.0].
    - drupal/swagger_ui_formatter 4.0.0 requires php ~8.1.0 -> your php version (8.2.15) does not satisfy that requirement.

This module is not yet compatible with PHP 8.2. It also appears the issue queue is disabled β†’ ? Odd.

  Problem 12
    - drupal/drupal[8.4.0-alpha1, ..., 8.7.x-dev] require composer/installers ^1.0.24 -> found composer/installers[v1.0.24, ..., 1.x-dev] but it conflicts with your root composer.json require (^2.0).
    - drupal/at_tools[3.6.0, ..., 3.x-dev] require drupal/adaptivetheme ^4.0 -> satisfiable by drupal/adaptivetheme[4.0.0, 4.1.0, 4.x-dev].
    - drupal/adaptivetheme[4.0.0, ..., 4.x-dev] require drupal/core ^8.8 || ^9 -> satisfiable by drupal/drupal[8.4.8, 8.5.15, 8.6.18, 8.7.14].
    - Root composer.json requires drupal/at_tools ^3.6 -> satisfiable by drupal/at_tools[3.6.0, 3.x-dev].

I am a little confused on this one. The project composer.json file says it needs drupal/adaptivetheme: ^8.4 but i dont see that as a realease/tag. β†’ . Maybe this tracks to 8.x-4.x? If so, then the issue is that 4.x of drupal/adaptivetheme is incompatible with Drupal 10. β†’ . It also appears that at_tools has been abandoned and now the work is being done in at_tool β†’

I made this changes locally and then saw this error:

  Problem 1
    - drupal/drupal[8.4.0-alpha1, ..., 8.7.x-dev] require composer/installers ^1.0.24 -> found composer/installers[v1.0.24, ..., 1.x-dev] but it conflicts with your root composer.json require (^2.0).
    - drupal/basic_cart 7.0.0 requires drupal/easy_install * -> satisfiable by drupal/easy_install[dev-1.x, dev-3.x, dev-4.x, dev-5.x, dev-6.x, dev-7.x, dev-8.x, dev-9.x, dev-10.x, 1.0.0, 1.x-dev, 2.0.0-alpha1, 3.x-dev, 4.0.0-alpha2, 4.x-dev, 5.0.0-alpha3, 5.x-dev, 6.0.0-alpha4, 6.x-dev, 7.0.0-alpha5, 7.x-dev, 8.0.0-alpha6, 8.x-dev, 9.0.0-rc1, 9.x-dev, 10.0.0, ..., 10.x-dev].
    - drupal/easy_install[dev-10.x, 10.3.0, ..., 10.x-dev] require drupal/core ^8 || ^9 -> satisfiable by drupal/drupal[8.4.0-alpha1, ..., 8.7.x-dev].
    - drupal/easy_install[dev-1.x, dev-3.x, dev-4.x, dev-5.x, dev-6.x, dev-7.x, dev-8.x, dev-9.x, 1.0.0, ..., 1.x-dev, 2.0.0-alpha1, 3.x-dev, 4.0.0-alpha2, ..., 4.x-dev, 5.0.0-alpha3, ..., 5.x-dev, 6.0.0-alpha4, ..., 6.x-dev, 7.0.0-alpha5, ..., 7.x-dev, 8.0.0-alpha6, ..., 8.x-dev, 9.0.0-rc1, ..., 9.x-dev, 10.0.0, ..., 10.2.0] require drupal/core ~8.0 -> satisfiable by drupal/drupal[8.4.0-alpha1, ..., 8.7.x-dev].
    - Root composer.json requires drupal/basic_cart ^7.0 -> satisfiable by drupal/basic_cart[7.0.0].

This module does not appear to be installable right now due to an issue with Easy Install being incompatible with Drupal 10. Easy install needs to be patched - see https://www.drupal.org/project/easy_install/issues/3297022 πŸ“Œ Automated Drupal 10 compatibility fixes Needs review .

Then I hit:

  Problem 1
    - drupal/block_country dev-1.x requires drupal/ip2country ^1.9 -> found drupal/ip2country[dev-1.x, 1.9.0, 1.10.0, 1.11.0, 1.x-dev (alias of dev-1.x)] but it conflicts with your root composer.json require (^2).
    - drupal/block_country 1.x-dev is an alias of drupal/block_country dev-1.x and thus requires it to be installed too.
    - Root composer.json requires drupal/block_country 1.x-dev -> satisfiable by drupal/block_country[1.x-dev (alias of dev-1.x)].

This module does not have a stable release. Stopping for now...

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

I figured out i could run

php scripts/test-unvetted-modules-composer-installability.sh recommendations.json /tmp/test-general-installability-unvetted 10.2.3

to test this locally (to avoid the aforementioned spamming of pipelines πŸ˜„). However...i think this is exposing a larger issue. Some of the generated recommendations, for example:

        {
            "package": "drupal/node_revision_delete",
            "constraint": "^2.0",
            "replaces": {
                "name": "node_revision_delete"
            },
            "vetted": false
        },

conflict heavily with the curated.json value, which is:

            "package": "drupal/node_revision_delete",
            "constraint": "^1",
            "install": [
                "node_revision_delete"
            ],
            "replaces": {
                "name": "node_revision_restrict"
            },
            "vetted": false
        },

even though it is vetted:false in curated.json it still feels like something else needs to happen here. Another example is rabbit hole:

Array
(
    [package] => drupal/rabbit_hole
    [constraint] => ^1
    [replaces] => Array
        (
            [name] => rh_file
        )

    [install] => Array
        (
            [0] => rh_file
        )

    [vetted] =>
)
conflicts with
Array
(
    [package] => drupal/rabbit_hole
    [constraint] => ^2.0
    [replaces] => Array
        (
            [name] => rabbit_hole
        )

    [vetted] =>
)

I'm not sure i feel comfortable updating these in curated.json without actually testing them myself locally, but I guess if its not marked as "vetted" that is ok? Updated the MR with updates to the failing packages and an added conditional in the test-unvetted-modules-composer-installability.sh script be more lenient with version checks to start 😊.

I thought the constraints in curated.json would have superseded those in generated.json, but this appears to be throwing an error. My changes have also broken things quite substantially in pipelines 😬 sooo im rethinking this at the moment

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

I think there are probably quite a few of these, another failure:

(
    [package] => drupal/chosen
    [constraint] => ^4
    [replaces] => Array
        (
            [name] => chosen_ajax
        )
    [vetted] => 
)
conflicts with
Array
(
    [package] => drupal/chosen
    [constraint] => ^4.0
    [replaces] => Array
        (
            [name] => chosen
        )
    [vetted] => 
)

I dont want to spam pipelines so maybe I can try to identify which ones differ and fix them all in one go .

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

❌ pipelines failing!

Array
(
    [package] => drupal/auto_entitylabel
    [constraint] => ^3
    [replaces] => Array
        (
            [name] => auto_nodetitle
        )
    [vetted] => 
)
conflicts with
Array
(
    [package] => drupal/auto_entitylabel
    [constraint] => ^3.0
    [replaces] => Array
        (
            [name] => auto_entitylabel
        )
    [vetted] => 
)

I think it is because ^3 vs ^3.0. Seeing what happens if I change that in curated.json

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

I am a little confused by the output in statistics

specifically this part:

  -  (of which ~ 388 generated recommendations overridden by curated recommendations)
  + (of which ~ 311 generated recommendations overridden by curated recommendations)

Did we lose 77 curated recommendations in this process somehow?

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Updated the IS as per #2 πŸ“Œ Update labels/verbiage to Drupal 10 throughout interface Active - for future proofing.

I think these alterations will require a ui rebuild as we need to compile the changes into ui/dist/common.bundle.js. I tried doing this locally but was hitting some issues with node versions. I think i was able to get npm run build to work on Node 18 (whereas node 20 was failing) - but need to run through it again to be sure 😁

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Works great πŸ˜„ opened an MR with the new recommendation

video of the fun β†’

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Looks like the most recent version of token_filter is 2.1.0 - https://www.drupal.org/project/token_filter/releases/2.1.0 β†’ . Testing first with ^2.1 in curated.json.

The D7 Setup:

  1. Install token and token filter
  2. Add the REPLACE TOKENS filter to a text format
  3. Edit a node that uses that text format, enter some tokens
  4. Verify on the front end that the tokens are replace

The above is working, now to generate a D10 project 😎


πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Re-ran the job and it worked πŸ€·β€β™‚οΈ maybe just a random failure (are these common amongst Gitlab CI pipelines?)

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Well...I managed to break a pipeline πŸ˜…

Looks like maybe something to do with a yarn failure?

yarn install
00:54
$ yarn --cwd $_WEB_ROOT/core install
yarn install v1.22.19
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/@babel/plugin-syntax-import-assertions/-/plugin-syntax-import-assertions-7.20.0.tgz: Request failed \"500 Internal Server Error\"".
info If you think this is a bug, please open a bug report with the information provided in "/builds/issue/acquia_migrate-3420211/docroot/core/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

πŸ€”

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ created an issue. See original summary β†’ .

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

I think the D7MenuLinkDeriver that was introduced here πŸ› Existing menu links show validation issues on migration (and ALL menu links pointing to node translations are invalid) Needs work is part of the issue. If it detects Drupal 6 as the source database, it will return without creating derivatives:

    // Do not create derivatives for Drupal 6 node translation menu link
    // migrations - return only one, with the ID which is equal to the base ID.
    // @see \Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator::getDerivatives()
    $legacy_drupal_version = static::getLegacyDrupalVersion($source->getDatabase());
    if ((int) $legacy_drupal_version !== 7) {
      return [0 => $base_plugin_definition];
    }

Without a check in fixMultilingualNodeMenuLinkMigrations() to ensure the plugin is a derivative, this fails. Adding a condition with a continue like this locally corrects the problem:

    foreach (array_keys($node_translation_menu_link_migrations) as $plugin_id) {
      $plugin_id_parts = explode(PluginBase::DERIVATIVE_SEPARATOR, $plugin_id);
      // Plugin is not a derivative.
      if (count($plugin_id_parts) < 3) {
        continue;
      }
      assert(count($plugin_id_parts) >= 3);

now running test:

www-data@2fdc9bf0644d:/app/docroot/core$ ../../vendor/bin/phpunit /app/docroot/modules/contrib/token/tests/src/Kernel/ValidateD6MigrationStateTest.php --debug
PHPUnit 9.6.16 by Sebastian Bergmann and contributors.

Testing Drupal\Tests\token\Kernel\ValidateD6MigrationStateTest
Test 'Drupal\Tests\token\Kernel\ValidateD6MigrationStateTest::testMigrationState' started
Test 'Drupal\Tests\token\Kernel\ValidateD6MigrationStateTest::testMigrationState' ended


Time: 00:08.926, Memory: 10.00 MB

OK (1 test, 52 assertions)
So as far as i can tell at this point (strap in for the ride) πŸ˜…:

1. the Drupal\Tests\token\Kernel\ValidateD6MigrationStateTest::testMigrationState starts
2. this instantiates a new MigrationPluginManager
3. this triggers migration_plugins_alter() hooks
4. per https://www.drupal.org/project/drupal/issues/3051251 πŸ› Existing menu links show validation issues on migration (and ALL menu links pointing to node translations are invalid) Needs work , there is a migration_plugins_alter() hook in menu_link_content which runs MenuLinkContentMigrationPluginsAlterer::refineMenuLinkContentMigrationDependencies() and MenuLinkContentMigrationPluginsAlterer::fixMultilingualNodeMenuLinkMigrations()
5. in fixMultilingualNodeMenuLinkMigrations() we attempt to first get all Migrations tagged as "Drupal 7", then we populate a variable ($node_translation_menu_link_migrations) with the plugin definition only if it has the id of node_translation_menu_links. At this point if the variable is empty we should return:

  public static function fixMultilingualNodeMenuLinkMigrations(array &$migrations) {
    $drupal_7_migrations = self::getMigrationsWithTag($migrations, 'Drupal 7');
    // If "content_translation" is enabled, we will migrate every node menu link
    // with "node_translation_menu_links" migration.
    $node_translation_menu_link_migrations = array_filter($drupal_7_migrations, function (array $definition) {
      return $definition['id'] === 'node_translation_menu_links';
    });
    if (empty($node_translation_menu_link_migrations)) {
      return;
    }

However, the variable is not empty due to the D7MenuLinkDeriver returning [0 => $base_plugin_definition];, which leads to the assertion failure.

I'm not sure where I am netting out here in terms of a recommendation haha. There is also the issue you mentioned on #4 which is that these Kernel tests do not appear to be running anyway in Gitlab. But I'm confident this module works well in Drupal 10.
πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

It looks like the failing Kernel test was introduced here - https://www.drupal.org/project/token/issues/3199214 β†’ .

How/why is this being thrown from menu_link_content? How did we get there? ... the failing lines are in fixMultilingualNodeMenuLinkMigrations():

  /**
   * Refines multilingual node menu link migration.
   *
   * Removes "d7_menu_links" node derivatives if node menu link translation
   * migration is present.
   *
   * @param array[] $migrations
   *   An associative array of migration definitions.
   */
  public static function fixMultilingualNodeMenuLinkMigrations(array &$migrations) {
    $drupal_7_migrations = self::getMigrationsWithTag($migrations, 'Drupal 7');
    // If "content_translation" is enabled, we will migrate every node menu link
    // with "node_translation_menu_links" migration.
    $node_translation_menu_link_migrations = array_filter($drupal_7_migrations, function (array $definition) {
      return $definition['id'] === 'node_translation_menu_links';
    });
    if (empty($node_translation_menu_link_migrations)) {
      return;
    }

    foreach (array_keys($node_translation_menu_link_migrations) as $plugin_id) {
      $plugin_id_parts = explode(PluginBase::DERIVATIVE_SEPARATOR, $plugin_id);
      <strong>assert(count($plugin_id_parts) >= 3);</strong>
      [, $entity_type, $bundle] = $plugin_id_parts;
      assert($entity_type === 'node');

This gets triggered from a hook_migration_plugins_alter() in menu_link_content:

/**
 * Implements hook_migration_plugins_alter().
 */
function menu_link_content_migration_plugins_alter(array &$migrations) {
  MenuLinkContentMigrationPluginsAlterer::refineMenuLinkContentMigrationDependencies($migrations);
  MenuLinkContentMigrationPluginsAlterer::fixMultilingualNodeMenuLinkMigrations($migrations);
}

But im still not sure why this is being called to begin with. What triggers the migration_plugins_alter() hook, in the context of a ValidateD6MigrationStateTest?

The assertion is attempting to explode $plugin_id on : separator and count the various parts. The failure comes from the $plugin_id value being node_translation_menu_links, which has no semicolons and thus fails assertion.

I think it's this line causing issues:

foreach (array_keys($node_translation_menu_link_migrations) as $plugin_id) {

because the only array key in $node_translation_menu_link_migrations is node_translation_menu_links:

dump(array_keys($node_translation_menu_link_migrations));

...yields..

array:1 [
  0 => "node_translation_menu_links"
]

But this makes me wonder if there is some larger misconfiguration going on, as my array keys are way off - this code would never work if I am reading correctly. I'm still unsure why menu_link_content plugin alter hooks are being called from a token test.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

That's indeed odd, because it's passing here on 10.2.3: https://git.drupalcode.org/project/token/-/jobs/743268

Regarding this issue:

2) Drupal\Tests\token\Functional\Tree\HelpPageTest::testHelpPageTree
Behat\Mink\Exception\ResponseTextException: The text "The list of the currently available tokens on this site are shown below." was not found anywhere in the text of the current page.

/app/vendor/behat/mink/src/WebAssert.php:907
/app/vendor/behat/mink/src/WebAssert.php:293
/app/docroot/modules/contrib/token/tests/src/Functional/Tree/HelpPageTest.php:38
/app/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

I think the issue is with the permission being assigned to the user. "access administration pages" is not the a viable permission in and of itself. We need "access help pages" - at least that is what corrects the issue in my local setup.

Not sure why this seems to work on 10.2.3-dev. I think i found the changes needed - https://git.drupalcode.org/project/token/-/commit/19bd13e587d0a4313b600c... - but they are not landed in a release yet.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

I set up a new D7 instance and installed token & imagecache token. Here is what the /admin/help/token page looked like after just installing token:

Then installed imagecache token and the help page now has the additional tokens included:

To test that the token replacement is working (without needing to also pull in another module to vet such as token_filter) I created a new text field, added the added the following:

To test that this actually works I added a little hook:

function dan_token_test_preprocess_field(&$variables) {
  if($variables['element']['#bundle'] !== 'article') {
    return;
  }
  if($variables['element']['#field_name'] !== 'field_token_test') {
    return;
  }
  $variables['items']['0']['#markup'] = token_replace($variables['items']['0']['#markup']);
}

And here is the before/after:

Looking at the token β†’ project page it looks like there is a newer version, 8.x-1.13 - so we can update that in the curated.json file. I did this, ran make, created a new D10 project, then ran AM:A to get my new field migrated over with the token value in place.

I think now it would be best to run the test suite in the token module. Here are the results:

www-data@f17c72c38ff3:/app/docroot/core$ ../../vendor/bin/phpunit /app/docroot/modules/contrib/token
PHPUnit 9.6.16 by Sebastian Bergmann and contributors.

Testing /app/docroot/modules/contrib/token
.....E........E.................................................. 65 / 78 ( 83%)
..........F..                                                     78 / 78 (100%)

Time: 08:40.729, Memory: 16.00 MB

There were 2 errors:

1) Drupal\Tests\token\Functional\TokenMenuTest::testMenuTokens
Behat\Mink\Exception\ElementNotFoundException: Button with id|name|label|value "Save content type" not found.

/app/docroot/core/tests/Drupal/Tests/WebAssert.php:144
/app/docroot/core/tests/Drupal/Tests/UiHelperTrait.php:78
/app/docroot/modules/contrib/token/tests/src/Functional/TokenMenuTest.php:159
/app/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

2) Drupal\Tests\token\Functional\Tree\HelpPageTest::testHelpPageTree
Behat\Mink\Exception\ResponseTextException: The text "The list of the currently available tokens on this site are shown below." was not found anywhere in the text of the current page.

/app/vendor/behat/mink/src/WebAssert.php:907
/app/vendor/behat/mink/src/WebAssert.php:293
/app/docroot/modules/contrib/token/tests/src/Functional/Tree/HelpPageTest.php:38
/app/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

--

There was 1 failure:

1) Drupal\Tests\token\Kernel\ValidateD6MigrationStateTest::testMigrationState
assert(count($plugin_id_parts) >= 3) in /app/docroot/core/modules/menu_link_content/src/MenuLinkContentMigrationPluginsAlterer.php:78

/app/vendor/phpunit/phpunit/src/Framework/TestResult.php:756

ERRORS!
Tests: 78, Assertions: 1191, Errors: 2, Failures: 1.

πŸ€” will need to review these. I ran an one liner with drush and can confirm the token replace functionality is working:

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

because AM:A will automatically eliminate the one that doesn't work

I did not know about this πŸ˜… - that seems more appropriate than what I was attempting to accomplish...one migration which varies source, process, and destination key+values πŸ™ƒ. Will give it a go!

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

All I was asking for is a clearer note 😊 Don't say "it's lacking X", say "X requires manual setup, because it needs manual re-evaluation" πŸ‘

😁 got it -- updated the note in the issue fork MR.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Did the two samples I linked in #6 not provide concrete examples?

Isn't the purpose of those to allow mapping of D7 plugin IDs to their modern D8+ counterpart? Those hooks are being added so that developers dont have to maintain a migrate Field plugin with getFieldWidgetMap() and getFieldFormatterMap() but rather can just simply add this hook to adjust the mapping.

In our case we already have those methods so I think those hooks are moot (right?), unless im misunderstanding their purpose.

Make sure you're looking not at d7_field_instance as it lives in 10.2.x, but at its post-patching state: AM:A applies lots of core patches! I suspect you might have been looking at "plain core"?

I am looking at d7_field_instance after an AM:A generated Drupal 9 project (as this was filed against D9). The patches/hooks do not appear to alter the d7_field_instance migration, but rather the d7_field_instance_widget_settings migration, which does not appear to control the name field settings. The hooks do not fire in the d7_field_instance migration.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

I started exploring porting the code in #8 ✨ Migration from Name module Needs work to an EventSubscriber (as I believe the Event system is superior to hooks) and ran into this issue - https://www.drupal.org/node/2952291 β†’ . See this change record β†’ .

It looks like migrate_plus β†’ is dispatching and providing the PREPARE_ROW event which we need to subscribe to. Until this issue - https://www.drupal.org/node/2952291 β†’ - lands, it probably does not make sense to add this to the name module itself as it would then cause a dependency on Migrate Tools (or we alter the composer.json of name module to pull in that issue MR, which is still in process so that seems unstable)...as such I think the only recommendation I have right now is to add the (deprecated) hook into the name.module file.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

I tried to get this working locally but am still facing some issues. Things get a little confusing between FieldInstance, FieldInstanceSettings, FieldInstanceWidgetSettings πŸ€ͺ

I thought adding something like this would suffice:

/**
 * Implements hook_field_migration_field_widget_info().
 */
function name_field_migration_field_widget_info() {
  return [
    'name' => ['name_widget' => 'name_default'],
  ];
}

But it seems like the module has already provided a custom field plugin with the mapping therein. IIRC this hook should not be needed since the custom plugin and getFieldWidgetMap() + getFieldFormatterMap() are present.

I think the Migration that controls the settings which we need is d7_field_instance. That migration maps the settings like this:

  settings:
    plugin: d7_field_instance_settings
    source:
      - settings
      - widget
      - field_definition

Where is the correct place to alter these? I could:

  1. adjust the d7_field_instance source plugin
  2. adjust the d7_field_instance_settings process plugin
  3. add a prepare row hook to override the settings

Im leaning towards #3 right now, but thats only because I dont think its OK to propose altering the core field module. So, doing this locally I am able to migrate a name field WITH the current field settings:

/**
 * Implements hook_migrate_prepare_row();
 */
function name_migrate_prepare_row(Row $row, MigrateSourceInterface $source, MigrationInterface $migration) {
  if (!str_contains($migration->id(), 'd7_field_instance')) {
    return;
  }
  if ($row->getSourceProperty('type') == 'name') {
    $field_definition_settings = unserialize($row->getSourceProperty('field_definition')['data'])['settings'];
    $settings = $row->getSourceProperty('settings');
    $settings['components'] = $field_definition_settings['components'];
    $settings['minimum_components'] = $field_definition_settings['minimum_components'];
    $settings['max_length'] = $field_definition_settings['max_length'];
    $settings['labels'] = $field_definition_settings['labels'];
    $settings['widget_layout'] = 'inline';
    $row->setSourceProperty('settings', $settings);
  }
}
πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

I did! I'm still not sure what to make of the guidance right now though. Should I be creating an entirely new source plugin which varies the variable names based on the underlying module version? If so, how do we account for this in the migration yaml mapping?

For example in d7_acquia_connector_settings the following variables are mapped:

   source:
     plugin: variable
     variables:
       - acquia_agent_debug
       - acquia_spi_cron_interval
       - acquia_spi_cron_interval_override
       - acquia_agent_hide_signup_messages
     source_module: acquia_agent
   process:
     debug: acquia_agent_debug
     cron_interval: acquia_spi_cron_interval
     cron_interval_override: acquia_spi_cron_interval_override
     hide_signup_messages: acquia_agent_hide_signup_messages

If I change the variable names coming from the source this mapping is no longer valid. Should I be overriding these values somewhere as well? Perhaps if i create a custom source plugin for this, I also need to make a custom process plugin (to determine correct mapping)... am I overthinking it? 😁 I also had the thought of doing this in an EventSubscriber, but wasn't sure the best way to access the D7 database in a consistent manner (as it wont always be "migrate" in settings.php) ... sorry if i am missing something obvious😬

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

But not migrating advanced settings which probably should be reassessed anyway … that does make sense. Can you clarify that in the note, please?

I don't think I described what I was trying to do very well haha πŸ˜ƒ There are 2 aspects of settings for this module:

Login Credentials:

Advanced Settings

The login credentials I don't think would be necessary to migrate.

The advanced settings do contain some data which could prove beneficial to migrate over. For example auth0_role_mapping, contains a mapping of Auth0 role names to Drupal Roles, a la:
s:19:"admin|administrator";

Or the auth0_claim_mapping contains a mapping of Auth0 profile names to Drupal user field names:
s:27:"given_name|field_first_name";

It was these settings which I was thinking might be worthwhile to migrate over so users don't have to copy them manually. But probably a nice to have vs hard blocker.

making me wonder why we'd consider this vetted if it's not

I think i was considering it vetted because I was able to set it up and have a functioning D10 module (after manual setup) - so can confirm it works, but there is no (existing) automated way to get it 100% in place

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Updated issue fork to include recommendation for bankvault. The previous note was:

This module is not yet compatible with PHP 8 β€” see https://www.drupal.org/project/bankvault/issues/3310429 β†’ .

Updated it to:

This module has no Drupal 10 release, see https://www.drupal.org/project/bankvault/releases β†’ .

---
BAT has a new release candidate β†’ which we should re-vet against. opened in child issue πŸ“Œ D10: Re-vet bat (drupal/bat) Active !

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

What a great guide written here! β†’

I followed it through and was successful in getting my Drupal 10 site set up with Auth0:

Video here β†’ πŸ™‚

I don't think it's worthwhile to try to migrate the standard LOGIN settings from Auth0 in D7 to D10. Best practice would also dictate these not even be stored in configuration, but rather set with an override.

We could write a migration for some of the advanced settings though which might be helpful ( I opened this issue to address πŸ“Œ Create migration of advanced settings from Drupal 7 to Drupal 10 Active ). Should we wait for that issue to be completed before updating the recommendation? Or do you think that is a "nice to have " - as this module is going to require manual setup anyway.

I updated this recommendation to be...something that might fit...but happy to reevaluate πŸ˜€

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

The issue described in the note is now fixed for auth0 β†’ and there a Drupal 10 compatible release:

This module is not yet compatible with PHP 8 β€” see https://www.drupal.org/project/auth0/issues/3258312 β†’ .

I think there is a free version of Auth0 and there is a guide here which was recently updated: https://www.drupal.org/docs/contributed-modules/saml-sp-single-sign-on-s... β†’ .

This should be broken out into a child issue to determine if the beta is working and what the curated recommendation should be for this module...assuming we do not run into any paywalls πŸ™‚

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Updated issue fork to include recommendation for apigee_account. The previous note was:

Apigee says: 'Choose an SSO module compatible with Drupal 9.' (source: https://docs.apigee.com/api-platform/publish/drupal/d7-d8-module-comparison)

This status has not changed and thus the note can remain the same. Worth mentioning that this documentation can be found here - https://docs.apigee.com/api-platform/publish/drupal/d7-d9-module-compari...

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ changed the visibility of the branch 3417878_animate_css to hidden.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

This appears to be working in Drupal 10! I can see the included animate.css library and the classes which are migrated over are inheriting the styling/effects.

Video here β†’ showing me migrating a basic page with Animate CSS classes via AM:A and it having the effect on D10.

Believe this means we can add this as a vetted recommendation now πŸ˜€

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Animate CSS appears to have a stable release - https://www.drupal.org/project/animate_css β†’ - and the issue referenced in our current curated.json file is now closed. https://www.drupal.org/project/animate_css/issues/3114653 πŸ› Cannot install through composer Fixed .

Breaking this out into child issue to see if it can be installed on a new D10 site.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Updated issue fork to include recommendation for alb_auth. The previous note was:

This module is not yet compatible with PHP 8 β€” see https://www.drupal.org/project/alb_auth/issues/3295402 β†’ .

The linked issue is now closed, however, in order to properly vet/test this module we would have to set up an Amazon Load Balancer (https://aws.amazon.com/elasticloadbalancing/pricing/) which could have financial implications. I also encountered this after enabling the module - https://www.drupal.org/project/alb_auth/issues/3417848 πŸ› Error on config form route after fresh installation Active .

Changing the note to:

Module installs cleanly with D8+ but cannot be manually tested due to needing an Amazon Load Balancer. The admin configuration form is also throwing an error, see - https://www.drupal.org/project/alb_auth/issues/3417848 πŸ› Error on config form route after fresh installation Active

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

dan612 β†’ created an issue.

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

I was able to get the active+required components to transfer over by adding the following to :

if ($row->getSourceProperty('type') == 'name') {
  $settings['components'] = $field_data['settings']['components'];
  $settings['minimum_components'] = $field_data['settings']['minimum_components'];
  $settings['max_length'] = $field_data['settings']['max_length'];
  $settings['labels'] = $field_data['settings']['labels'];
}

However, is this the best way to accomplish this or is there perhaps a better way? Altering the core field module to accommodate a name based field instance seems a bit..too specific. πŸ€”

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Updated issue fork to include recommendation for advanced link. The previous note was:

This module is obsolete in Drupal 9. No known equivalent module exists; please help porting this module if it's critical for your site

I think this note is slightly misleading as there are some viable alternatives. Updated to:

This module is obsolete in Drupal 9+. Potential alternatives include: editor_advanced_link, and linkit (bear in mind https://www.drupal.org/project/drupal/issues/3317769 ✨ Drastically improve Drupal's default linking experience in text fields Needs work ).

πŸ‡ΊπŸ‡ΈUnited States dan612 Portland, Maine

Thanks for opening this issue!

Following up on #2 ✨ Migration from Name module Needs work I did some testing locally. Steps performed:

  1. Install Drupal 7.99
  2. Set up a content type
  3. Add the NAME module (version 7.x-1.13)
  4. Install and add to content type from step 2
  5. Create new piece of content with name field populated
  6. Generate a new D9 project using acli
  7. Connect D7 database as migrate source for D9 site
  8. Run migrations for content type created in step 2

Summary
This resulted in the data being transferred over, but the field configuration appeared missing in D9. I think this should work to transfer the data over but you may need to manually port over the field settings to get the fields properly configured again.

More details...

On a new D7 Site
Node add/edit form display:

Display:

DB Storage:

On my D9 Site
On the field settings you can see no components selected after the migration:

You will need to manually update settings here in order for the node add/edit display to look correct:

Display:

DB Storage:

Production build https://api.contrib.social 0.61.6-2-g546bc20