Support Drupal 10 in the 1.0.x branch

Am I right that now with 📌 Add compatibility with Group v2 and v3 Fixed RTBC this issue is also unblocked?

Sure, sorta. ;) I'd rather get Group v1 D10 compatible first, but it's gonna be a little while before I'll be able to work on that. Maybe this can proceed in parallel?

the 2.0.x branch is now D10 compatible. I'll leave this issue for making the 1.0.x branch D10 compatible, which is blocked on a D10-compatible release of Group V1, e.g. 📌 Initiative for Group 1.x compatibility under Drupal 10 Fixed and friends.

Uploading a full patch, which provides Drupal 10 compatibility against 1.0.x-dev branch.

Please test

This is an automated patch generated by Drupal Rector. Please see the issue summary for more details.

It is important that any automated tests available are run with this patch and that you manually test this patch.

Drupal 10 Compatibility

According to the Upgrade Status module → , even with this patch, this module is not yet compatible with Drupal 10.

Currently Drupal Rector, version 0.15.1, cannot fix all Drupal 10 compatibility problems.

Therefore this patch does not update the info.yml file for Drupal 10 compatibility.

Leaving this issue open, even after committing the current patch, will allow the Project Update Bot → to post additional Drupal 10 compatibility fixes as they become available in Drupal Rector.

Debug info

This patch was created using these packages:

1. mglaman/phpstan-drupal: 1.2.0
2. palantirnet/drupal-rector: 0.15.1

Now that Group v1 supports Drupal 10, can a release be made based off of the most recent patch to get v1 of Entity Group Field to support Drupal 10 as well?

I am also interested in this being in a v1 release so that I can properly focus on the Group v2 or v3 upgrade early next year!

I've rerolled that patch from #15 against the 1.0.0-alpha2 tag. The changes from 📌 Configure GitLab CI Fixed are not yet tagged, thats why the generated patch from MR11 doesn't apply.

Thanks for the patch @timohuisman !

Sorry folks, forgot this one was still open. Marked ✨ Providing a version that's compatible with D10 and Group 1.x Closed: duplicate duplicate. Som things we still need to solve here, not addressed in the current MR:

1. Strong preference not to drop D8 support unless we have to, which I don't think is necessary. Nothing in here actually looks like it requires 9.5. Let's use core_version_requirement: ^8.8 || ^9 || ^10
2. Drupal\Tests\entitygroupfield\Kernel\GroupAutocompleteFormElementTest::testGroupAutocomplete
   LogicException: system module does not define a schema for table 'key_value_expire'.
3. We also need to tweak the .gitlab-ci.yml file in the 8.x-1.x branch to get this testing on D10. Not sure if we need the full complications of the 2.0.x branch's copy with the "matrix" testing, or if there's a slicker way to have it test on D10 by default but still be able to test earlier versions, etc.

But I'd love to get this resolved, committed and another 1.0.x release tagged ASAP.

Thanks!
-Derek

Fixes #18 except for #18.3 and the .gitlab-ci.yml file.

Decided to move #18.3 to a follow-up ( 📌 Fix GitLab-CI configuration on both 1.0.x and 2.0.x Active ), since it doesn't have to block the release and isn't directly related to the D10 compatibility in the code itself.

dww → credited jurgenhaas → .

dww → closed merge request !11

1.0.0-beta1 → is now out! 🎉

@dww
First Thanks for the great work and rolling out a new release!

Strong preference not to drop D8 support unless we have to, which I don't think is necessary. Nothing in here actually looks like it requires 9.5. Let's use core_version_requirement: ^8.8 || ^9 || ^10

General question: I also maintain the contrib modules. If the Drupal core doesn't support the D8 and D9. How long as a contib maintainer we should support the unsupported Core?

Like in the case of above commit https://git.drupalcode.org/project/entitygroupfield/-/commit/27c7d0ec2bf... we relied on a core/once library which was introduce in Drupal core in 9.2. See https://www.drupal.org/node/3158256 →
Now, we're claiming that we support 8.8 but we don't

Sorry for highlighting this here but that's a question general for all projects

You're welcome, and thanks for helping! And for this question:

I also maintain the contrib modules. If the Drupal core doesn't support the D8 and D9. How long as a contib maintainer we should support the unsupported Core?

Not everyone agrees on this, but my strong belief is "as long as you feasibly can". If the exact same code won't crash your site on 3+ different versions of Drupal core, amazing! That makes life so much easier for people stuck on older versions of core, trying to get out of an impossibly complicated web of composer hell. I'd rather make it as easy as we can for our end users to upgrade instead of punishing them for not having upgraded already by artificially making it harder than it already is.

That said, if you want/need to use newer features that only exist in later versions of core, so be it. Start a new minor branch or whatever, and move on. But don't drop support just for the sake of it. If the code still works on 8.8, let it be. If there's real tech debt needed to keep supporting "ancient" versions, declare a new minimum and clean up.

In the specific instance of this once requirement in the library, I'm honestly not sure why that's there. 😂 The entire library definition is from the initial commit (d909330 from jidrone), and it's not clear how much of that we're actually using. I just tested again on a D8.9 site and the widget all seems to be working as planned, even pointing to a non-existent library item. Probably we could remove that line entirely. Regardless, it doesn't crash a test site if there's a missing library. Even if it doesn't work perfectly, at least telling composer it'd be okay to use this version as it was trying to upgrade things, huzzah.

At least that's how I see it...
-Derek

Automatically closed - issue fixed for 2 weeks with no activity.