The important book patch was inadvertantly removed back in 2024 during commit 591824aef9 between 5.1.1 and 5.2.0
The module currently is functional however it isn't 100% complete according to my plans.
Hi @bmango, thanks for the report, I'll fix this soon. For now, you can unzip or untar the module to try it out. Or clone it into your contrib folder.
Please tag this for a Drupal 11 release. It's been two years now without a tagged release.
The maintainer is alive.
https://www.drupal.org/project/site_alert/releases/8.x-1.4 →
1.4 was released supporting Drupal 11!
Thanks
With that said, there's some other things I'd do if I was maintainer of this project.
TODO
- Add a link to the project page of site_alert to urge new installs to choose the more popular sitewide_alert → module instead
Basically not needed now, Livre 1.0.x is compatible with Drupal 10.5.x, Drupal 11.1.x, Drupal 11.2.x and Drupal 11.3.x and is based off of the 3.0.x branch of the Book module.
Keeping an eye on the upstream for changes, will ensure git aligns when possible.
✨ Book navigation block (prev/next) without TOC on top level book pages Postponed: needs info
moving this back to 3.0.x since this issue is closed and my related merge request for 2.0.x was rejected.
I'm evaluating the 3.0.x functionality as it pertains to this feature. I'm seeing the same/similar result to what I saw with a modified version of @sylus patch from #3173808-26: Make book child content-type configurable per enabled book content-type → (not seeing the next/previous buttons in the footer)
In my testing of 3.0.x, I'm not seeing the next/previous buttons in the footer.
I'll be doing extensive testing and work on this in the comming 24 hours where I'll set up vanilla Drupal 11.2.5, Drupal 11.1.8 and Drupal 10.4.8 with the 3.0.x functionality and see if I can find a winning recipe and or make adjustments if necessary.
Might just require a totally vanilla setup in my testing so I'll baseline it and go from there.
joseph.olstad → changed the visibility of the branch 3554905-merge-3.0.x-into-2.0.x-with-fixes to hidden.
joseph.olstad → changed the visibility of the branch 3554905-full-backport to hidden.
joseph.olstad → changed the visibility of the branch 3554905-cleaner-backport to hidden.
@smustgrave, prior to me fork/replacing the book module, any feedback on this is appreciated. It's 100% passing, all green!
@smustgrave, it's ok, I can easily fork book using composer replace without renaming the book module which is probably what I will do just as I have done in the past for jquery_ui in jq_ui.
https://a1.11pro.ca/en/public-documentation/drupalorg/dx-composer-replac...
so once the tests are 100% passing , I can close these two issues and continue with the forked project which will be a clone of book however using the replace pattern as documented.
Have a look at jq_ui →
joseph.olstad → changed the visibility of the branch 3555112-make-3.0.x-compatible to hidden.
joseph.olstad → changed the visibility of the branch 3555112-minimal to hidden.
Ok I'm down to one test fail , otherwise EVERYTHING is green. I'm quite confident that I'll soon have it 100% green. Straight forward code changes.
Almost perfect now.
"drupal/book": "2.0.x-dev#b966267a as 2.0.2",
this patch:
"patches": {
"drupal/book": {
"3554905 - Port book allow other types to create books to 2.0.x":
"https://git.drupalcode.org/project/book/-/merge_requests/131.diff"
}
},
looked closer at the test failure, it's related to permissions.
Status message
You have used a one-time login link. You can set your new password now.
r6z2z24c
Breadcrumb
Home
Primary tabs
View
Edit
pkfob6o6
Member for
7 secondsthen:
ID #29 (Previous | Next) Called from GuzzleHttp\Promise\FulfilledPromise::GuzzleHttp\Promise\{closure}() line 48
GET request to: http://localhost/web/node/1/outline/remove Skip to main content r6z2z24c Breadcrumb Home 00 - test node w48rcdxtys Outline
Access denied You are not authorized to access this page.
So, we had the desired functionality working with Drupal 10 using a core patch.
When we upgraded to Drupal 11, we dropped the core patch obviously, since it no longer applied, forgot about it, and then 8 months after upgrading we noticed a bunch of broken functionality that previously was not broken.
The fix/features were applied to 3.0.x however 3.0.x was made incompatible with Drupal 11.1.8.
So, I've made it compatible with Drupal 11.1.8 and only seeing two errors in the tests that likely won't affect us, and to avoid problems with composer I'm creating a merge patch to bring this back to 2.0.x.
Would like to fix the two remaining issues but probably don't need to.
We need this desperately before a prod release. Cannot upgrade to D11.2.x so we need this functionality in D11.1.8.
All tests are passing 100% in Drupal 11.2.x while there's now only two fails , possibly insignificant fails for D11.1.8.
ya, I actually will use the 2.0.x issue instead, can close this.
This is almost complete, there's only two fails left on D11.1.x and D11.2.x tests are now fully green again other than a minor phpcs.
colleague changed an option, now it's no longer truncating half way through a word. However the ... is not consistently added. With that said, if it becomes an issue I'll work on a patch.
I sent this message to all the maintainers:
Date: Thursday october 30th 2025 (my time)
Subject: Offering to maintain site_alertHello Pieter, Cecily, Adrian, Nicola, I am contacting you since one of your modules looks abandonned. I'm offering to maintain it for you.
💬 Offer to maintain site_alert Needs review
Thank you,
Joseph Olstad.
Need to make a new MR based off of 3555112 and set it to merge to 2.0.x
💬 Make 3.0.x compatible with Drupal 11.1.8 and fix a bug Needs review
joseph.olstad → created an issue. See original summary → .
Ok I brought everything from book 3.0.x over to book 2.0.x
and then I backed off the changes that make 3.0.x incompatible with Drupal 11.1.8.
I changed all the version pinning from ^11.2 to ^11.1
made another change to book.post_update.php as it crashed my environment, the changes are in the merge request.
"drupal/book": "2.0.x-dev as 2.0.2",
this patch:
"patches": {
"drupal/book": {
"3554905 - Port book allow other types to create books to 2.0.x":
"https://git.drupalcode.org/project/book/-/merge_requests/127.diff"
}
},Reviewing, still something to figure out but using the latest and greatest here.
Ok I brought everything from 3.0.x over to 2.0.x
and then I backed off the change that makes 3.0.x incompatible with Drupal 11.1.8.
I changed all the version pinning from ^11.2 to ^11.1
made another change to book.post_update.php as it crashed my environment, the changes are in the merge request.
"drupal/book": "2.0.x-dev as 2.0.2",
this patch:
"patches": {
"drupal/book": {
"3554905 - Port book allow other types to create books to 2.0.x":
"https://git.drupalcode.org/project/book/-/merge_requests/127.diff"
}
},We need this for 2.0.x-dev, we can't just snap our fingers and upgrade from Drupal 11.1.8 to 11.2.5 in order to use 3.0.x.
@al_trottier , couple of ways to fix this while you're waiting.
I'll mention the easiest way first:
composer require drupal/redis:'1.10 as 1.08'
Can we please get this into a tagged release ASAP? ex: 8.x-1.40
There's other modules that require search_api tagged releases and they squeel on dev releases.
@useernamee
that error is from core , something perhaps weird about your setup?
I sent another message to Hestenet about this.
Please, anyone but me, drop a link to this issue in the D11 readiness channel in drupal slack.
Hestenet is not responding. I sent two messages to him via his contact page and nothing. I no longer have slack access so I cannot log into slack to ping anyone about this. There's a channel in there for maintainers or #d11-readiness , please paste a link to this issue in the d11 readiness channel.
I'll say cannot reproduce since it's actually the minors on or after .3 that are more aligned to Symfony LTS and NOT the majors.
Ok, I'm seeing it now, so DXX.3+ where we focus on the .3+ is really the stable offering that certain clients may want to plan their upgrades for. These ones are on or soon to be on LTS versions of symfony. Earlier DXX minors are like the early adopters of the next Symfony major. Ok so while it may not always be a DXX.3 it'll be close to or the next one that gets the Symfony major.
We're getting a better understanding of the timelines here.
Ya feel free to close this. My questions are answered. It's not so much the major but the Drupal minor that gets the symfony LTS.
Thanks.
Symfony’s official releases page
doesn’t explicitly say “every even-numbered .4 release is LTS,” but in practice every .4 release has been designated LTS since Symfony 2.4 (2013).
The pattern has held consistently for over a decade:
Symfony version Release year LTS EOL
2.4 / 2.8 2013–2015 ✅ yes
3.4 2017 ✅ yes
4.4 2019 ✅ yes
5.4 2021 ✅ Nov 2025
6.4 2023 ✅ Nov 2027
It’s about giving the ecosystem a clear signal —
“Drupal 14, 16, 18 → Symfony 9.4, 10.4, 11.4 (LTS)” —
so developers and clients can better understand the scope of upgrades confidently years in advance.
That level of predictability doesn’t require 15-year commitments from Symfony; their 10-year pattern is already reliable enough to anchor a Drupal policy statement.
@longwave
Symfony actually does publish a predictable release cadence and LTS policy on their official releases page: https://symfony.com/releases
.
They’ve consistently followed the same pattern for more than a decade:
- Every even-numbered .4 release is designated as an LTS.
- This pattern has held since Symfony 2.4 → 2.8 → 3.4 → 4.4 → 5.4 → 6.4 → and the upcoming 8.4 LTS (with 9.4, 10.4, 11.4 also planned as LTS).
- The cadence is every 2 years, with .4 being the final minor in each major’s cycle.
So while Symfony doesn’t publish a 15-year forward schedule, its LTS pattern is well established and predictable.
In comparison, Drupal’s own major release dates (e.g., Drupal 12 in June 2026) are targets that often shift, so expecting Symfony to give stronger future guarantees than Drupal itself provides seems disproportionate.
Knowing that every even-numbered .4 is an LTS is sufficient to plan alignment confidently — e.g., Drupal 10 → Symfony 6.4 LTS, Drupal 12 → Symfony 8.4 LTS, and so on.