@heddn

Posted on the PR but I'm not sure about the extra hardening. Other feedback addressed.

Responded to feedback.

Can we add to an exist Functional test or create a new one that causes this?

If we are going to work in this space, can we also adjust SnippetTest so it no longer try/catches MigrateSkipProcessException?

There are still a few comments on the MR without any feedback. Also, for those facing this and don't want to apply a patch, you can always move dependencies from required to optional. I almost never use required because of reasons like what this issue causes.

Thanks for the fix.

Now this needs tests showing the problem and how it is fixed.

This should be based on 6.x branch.

heddn → made their first commit to this issue’s fork.

The CR has a fix: https://www.drupal.org/node/3537201 →

Can we add a change record with docs how to use this?

Given this is label only changes and tests still pass and Andy confirmed we got all the places, I'm going to go out on a limb here and mark this RTBC. Feel free to kick it back.

heddn → created an issue.

LGTM

Merging what we've got. Even though this isn't done, it make incremental improvements.

Be nice if we could add tests and the toggle for this functionality as mentioned in the IS.

I've been using the module w/ Drush 13 without issue, so I'm not sure what parts of drush 13 are broken.

Needs a rebase

MRs accepted

Can we add a test for this? I don't see any failing tests showing this issue. BTW, I'm certain it is a problem, we just should add tests.

I've published and updated the change record.

Thanks for fixing this.

Let's do it.

NW for test failures

Had a chance to manually test this today and everything seems to be in order still.

heddn → made their first commit to this issue’s fork.

heddn → made their first commit to this issue’s fork.

The lone failure was a build test failure and seems unrelated.

Posted feedback on MR

re #10:

that isn't quite true. regularly I get the access granted for the user account given for S3. and even if eventually i use an account with locked down permissions, I find it easier to setup with this drupal gui than to navigate in all of the various S3 vendor's UI and configure it.

https://www.drupal.org/docs/develop/automated-testing/phpunit-in-drupal/... → and more specifically https://github.com/ddev/ddev-selenium-standalone-chrome?tab=readme-ov-fi... helped a lot with getting insight into the failures.

Back to NR

Could use tests and enhanced docs.

Closing as duplicate of 🐛 Using the XML Data Parser with a Predicate pulls in the final xml item regardless of if the predicate matches Needs work

heddn → made their first commit to this issue’s fork.

This seems to introduce errors in tests. See https://git.drupalcode.org/project/stripe/-/pipelines/558766 vs https://git.drupalcode.org/issue/stripe-3316114/-/pipelines/558737.

Thanks for the fixes here.

Thanks for the fixes here.

Related javascript tests seem to be failing but I can't reproduce the issues manually. Any suggestions?

Implemented suggestions

Anyone able to confirm if this makes things happy? If you do, feel free to drop in your steps to testing (similar to #31) and mark this RTBC.

Are we sure this is the only place that surfaces? And we should update cspell if it is.

Would still be nice to add a unit test.

Thanks for the improvements here.

heddn → made their first commit to this issue’s fork.

Probably removing the string from the const is the safest fix. Feel free to open a PR.

Can we add a test or something to confirm the problem and fix please?

Back to NW for #32 and other feedback.

The fixes for this were already in the dev branch. I thought I'd released it in a tag, but must have missed it.

https://www.drupal.org/project/migrate_source_ui/releases/8.x-1.3 →

Let's merge this and tag a release. If there are any more issues, we can resolve them in a follow-up and yet another release. I'd rather not leave this hanging forever.

Removing the blocker as there is a work around.

For now, I'm going to implement https://git.drupalcode.org/project/paragraphs/-/merge_requests/115/diffs... in the contrib module that this effects. I'm not sure another rewrite off all this when field migrations are about to go away is really desired.

Sorry, I missed that. Fixed. Thanks for your patience.

That label is added on d.o pages to educate visitors about what is a stable project. It can't be removed.

Some would kindly test and approve the latest patch.

This is done.

This is postponed on the upstream core issue being resolved. Secondly, getting this to green on tests is proving to be troubling. I'd appreciate anyone who can help out in the space.

This now needs some tests. And we should compare this against 🐛 Nested translated block configuration is not being displayed RTBC and/or 🐛 Nontranslatable custom block fields are not synchronized between translations Needs review to see if there is any overlap.

Can this get converted into an MR? We should also compare it against 🐛 when I add a referenced custom block after translating it, the layout page does not pick up the added blocks Active to see if there is any overlap.

Let's add some test coverage for this.

It wouldn't be trivial to back out the full phpcs changes as they were done back in January and the impact wasn't caught until recently. The easier way forward is to see these fixes land quickly.

Posted a response to the last comments.

I've opened 🐛 Calling $migration->getMigrationDependencies() from a field plugin results in an infinate loop Active .

I've opened 🐛 Calling $migration->getMigrationDependencies() from a field plugin results in an infinate loop Active .

🐛 Drupal 7 to Drupal 11 migration runs forever Active complains about this on the contrib project. Given it is breaking contrib, I'm moving this to a major.

heddn → created an issue.

The addition of this seems to have added an infinite loop via field discovery calling getMigrationDependencies. Will start looking for a bug report, but wanted to mention this here in case someone else has already surfaced this.

Thanks for the fixes here.

This needs to be rebased.

This needs a rebase and steps to reproduce the issue.

Thanks for the fixes here.

Thanks for the work here.

Ideally we identify what made this hard dependency on migrate_plus in 6.1 and revert/rollback/fix that. Is that even possible?

Can you tell if this makes things easier to upgrade to the 6.1.x branch?

heddn → made their first commit to this issue’s fork.

What is the benefit of this?

Good enough for me.

Can we add any tests for this?

Thanks for the fixes here.

Thanks for the fixes here.