Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
The 3.x branch has been created to work on Drupal 11 compatibility. Since Drupal 11 requires PHP 8.3 this gives us the opportunity to modernize our code base. We can adopt new best practices such as strict types, readonly properties and PHP 8 attributes. This issue collects tasks to modernize the codebase and adopt new D11 and PHP 8.3 features.
Must have:
#3529573: Make 3.x branch compatible with Field Inheritance 3.0.0
#3529984: Update deprecations that will be removed in D11
#3529989: Move Group recurring events submodule to its own fully project namespace
#3522736: You have requested a non-existent service "daterange_compact.date_range.formatter"
#3537787: Require PHP 8.3 in the 3.x branch
#3510919: Drupal 11: Views Data Alter hook clash
#3541881: Drupal 11 compatibility
Nice to have:
#3480508: Use readonly constructor property promotion for injected dependencies
#3481021: \Drupal calls should be avoided in classes, use dependency injection instead
#3530512: Replace Annotations with Attributes
#3485904: Registrants should have a language
#3477791: NotificationService leaks state
#3542050: Use a boolean for the waitlist state
Issue fork recurring_events-3480491
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
chrisla commentedThanks for starting this. I would like and need a D11-compatible version without any other feature changes or updates as I will be migrating our sites to D11 very soon. Other modules have been creating minor updates introducing the bare minimum for D11 compatibility. I was planning on spending some time this month to see how much this module needs for that minimum compatibility and it would be great if we could have at least one release still on the 2 branch without needing to check on updating a whole ton of stuff just for D11 compatibility.
Comment #3
pfrenssenIf you can make an MR with the minimum necessary changes to get D11 compatibility while still retaining full backwards compatibility with Drupal 9.3+ then that is very welcome. But let's do that in a dedicated issue, this issue is specifically on future forward changes and does not affect 2.x.
Comment #4
chrisla commentedPerfect, I have time planned at the end of the month and early November. I just wanted to make sure we were addressing D11 compatibility in 2 branch as well.
Comment #6
chris dart commentedI have made some commits to get this to be minimally D11 compatible. These are unrelated to the other child issues here which appear to aim to clean up and make the code more modern.
Comment #8
plopescHello @pfrenssen!
I really like the idea brought in this issue. Last week I started to work on a similar upgrade path for Field Inheritance module. You can see how it looks in #3526071: [META] 3.0.0 Plan.
Key part of the upgrade would be to integrate the Field Inheritance architecture changes introduced in #3500250: Store relation with the parent entity in the database instead of the State API, which you actually suggested a while ago.
I'm wondering if we could define a similar approach for Recurring events, where a new 3.x branch is used to define Drupal 10.3+ releases based on Field Inhetance 3.x.
The reason why I preferred to use 10.3 instead of directly a new 11.x branch was to give sites the opportunity to have an stable environment with the new Field Inheritance architecture before moving to 11.x. This approach was taken by Drupal Commerce and the 3.x version. That was very convenient for us in other Commerce based projects, where the migration was taken in 2 steps to reduce friction points.
I'm open to help and collaborate with the migration of this module, given that it's a key requirement in some of our projects. At the same time a review and test of the new FI architecture would be very helpful to ensure that both modules are aligned.
Comment #9
plopescComment #10
plopescComment #11
plopescUpdate roadmap
Comment #12
pfrenssenComment #13
pfrenssenReally nice to see this moving forward! I added a new blocker: #3537787: Require PHP 8.3 in the 3.x branch
Comment #14
pfrenssenComment #15
pfrenssenComment #16
pfrenssenComment #17
pfrenssen@chris dart I missed your contribution, thanks for starting the work on the D11 compatibility. However this is just a planning issue where we organize the bigger task of modernizing the code base. I think we might be ready now to start on the actual Drupal 11 compatibility. So far we were blocked on our dependencies (like the Field Inheritance module) not being ready. But we should do the work in separate issues and link them here.
Comment #18
pfrenssenComment #19
pfrenssenI created an issue to commit the D11 compatibility fixed that were proposed here by Chris Dart: #3541881: Drupal 11 compatibility.
Comment #20
pfrenssenComment #21
muriqui commentedLooks like all of the issues on the roadmap have been fixed. Anything else that needs doing before creating a 3.0 release candidate?
Comment #22
chrisla commentedI have some time and funding to contribute to the release of 3.0 and D11 compatibility. Are we waiting on anything else other than release of Field Inheritance 3.0 as well via https://www.drupal.org/project/field_inheritance/issues/3480537 ?
Can I contribute in some way? Is more testing required? What is blocking a full release?
Comment #25
muriqui commentedOpened a new MR to tighten up the coding standards and do some final clean-up. Still some work to do there, but waiting on getting some other pending MRs merged. Once that's done, I think we can consider this effort complete and roll out a stable 3.0.0.
Comment #26
muriqui commentedComment #27
daceej commentedLooks good on my end. I tested some typical interactions and did not run into any exceptions.
Comment #29
muriqui commented