🇨🇦Canada @joseph.olstad

Patch 63 works well on 10.4.0

Still needs attention

 @jsobiecki , please tag 2.1.1 , this fix is only in the dev-2.x right now, should have a tag !

Thanks, I'm seeing it in the latest wxt-5.3.x dev
got the fix by upgrading wxt.

recommend applying patch 6 to the build.

I contacted all 4 maintainers and let them know that this needs action for Drupal 11 compatibility and that it's currently RTBC.

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

https://www.drupal.org/project/tagclouds/releases/2.0.10 →

@japerry, thank you for updating the project page! This explanation helps immensely!

Thanks especially to @poker10 and @mcdruid

We're misusing the lib for practical reasons

this ? lol

Why is this project marked as obsolete? There's no explanation on the project page?

https://www.drupal.org/project/formblock/releases/2.0.0-beta4 →

https://www.drupal.org/project/formblock/releases/2.0.0-beta4 →

Subject: Advancing an LTS Lifecycle Strategy for Drupal and its Ecosystem
As we consider Drupal's core strategy for 2025–2028, I believe we need a concerted effort to establish a long-term support (LTS) lifecycle for Drupal and its ecosystem, including Symfony, Twig, Doctrine, and PHP. The goal is to minimize disruptive upgrades and refocus on delivering value to end-users while maintaining a predictable development and maintenance cycle.

Why an LTS is Critical

PHP currently releases new minor versions annually, often introducing deprecations that create significant churn downstream. This churn directly impacts Drupal, as we are tightly coupled to the lifecycles of PHP and Symfony. Each year, our efforts are diverted from improving Drupal itself to accommodating upstream changes.

By contrast, successful open-source projects like Ubuntu provide a clear LTS strategy: 5 years of mainline support with an additional 5 years of extended support. This model offers stability for both developers and end-users. Similarly, Drupal 7 demonstrated the value of a stable platform with extended support, lasting over 14 years with relatively low maintenance overhead.

An LTS strategy could bring similar benefits to Drupal and its ecosystem. It would allow us to focus on innovation and stability while reducing the burden of rapid upstream changes. Developers and organizations would gain confidence in building on a platform with a predictable lifecycle.

Proposed Path Forward

1. Engage with Key Stakeholders:
I encourage Dries and the leadership team to collaborate with Fabien Potencier (Symfony), the Twig maintainers, and key contributors to PHP. Aligning on an LTS roadmap for PHP and Symfony would form the foundation of an LTS strategy for Drupal.

2. Advocate for PHP and Symfony LTS:
A longer PHP lifecycle—aligned with Symfony's major releases—could greatly reduce churn. Third-party vendors like Red Hat already provide extended security support for PHP, demonstrating that a long-term strategy is feasible. If a unified approach cannot be achieved, we might explore the possibility of an LTS fork for PHP, Symfony, or both.
3. Lock Versions for Stability:
Drupal's LTS releases could lock to specific versions of PHP, Symfony, and Twig for the duration of the release cycle. This would ensure stability, simplify compatibility testing, and allow for focused innovation within Drupal itself.
4. Provide Clear Choices:
Offering both LTS and non-LTS options could cater to different needs. Most developers and organizations, given a clear roadmap, would likely opt for LTS to minimize risk and disruption.
5. Stub Releases for Upgrade Paths:
To address the concerns about upgrade paths, we could include "stub releases" designed specifically to provide smooth transitions between LTS versions. These releases would focus on upgrade compatibility rather than feature development.

Call to Action

Has there been prior discussion with Fabien Potencier or other key stakeholders about a unified LTS strategy for PHP, Symfony, and their downstream ecosystems? If not, I believe this is a critical topic that needs top-level attention.

The alignment of PHP, Symfony, Twig, and Drupal under an LTS umbrella could transform the ecosystem, benefiting developers, maintainers, and end-users alike. It would provide a sustainable path forward, reducing churn and refocusing efforts on the core mission of Drupal—empowering users with a robust, innovative, and reliable CMS.

No longer need the patch, solution now is to upgrade to ^3.0.4 →

No longer need the patch, solution now is to upgrade to ^3.0.4 →

Thank you @wells ! :)

I'd say this is coming from the commerce project. see if you can patch that module.

Please follow up with the upstream contrib project and place a link here. Have a look at the ds solution.

If you have a patch to solve this for the related contrib module please upload it here or place a link to the issue containing the patch.

This is an upstream issue not caused by the theme, it is caused by the contrib module in question making invalid suggestions.

Possibly related to the same issue as documented here:

🐛 No CSS applied to my subthemes when I aggregate CSS and JS Active

Please have a look and try again.

For release 3.33 and release 3.34 you must upgrade to Drupal 10.3 for it to work. You must also use composer for the upgrade for all of the functionality to work as expected.

#3491034-7: No CSS applied to my subthemes when I aggregate CSS and JS →

increasing priority since it's a fatal error and unusable without the patch on a currently supported Drupal release.

This module is currently in an unusable broken state when running Drupal 10.3+ without patch #20

I just linked two duplicate reported issues, set this issue as their parent.

The duplicate related issues are both fixed by patch #20

🐛 When " All day" is checked the page will not render. I get a TypeError: get_class(): Argument #1 ($object) must be of type object, null given in get_class (line 268 of modules/contrib/calendar_link/src/Twig/CalendarLinkTwigExtension.php). Active

and

🐛 Drupal 10.3.10 seems to break this... Active

Hello @carlbowles100,

A solution to your issue was previously reported here:
#3257001-5: not found in include_once() →

The solution is to use composer as follows:

composer require drupal/bootstrap:'^3.34'

see comment #5

Solved by this patch:

#3392784-20: calendar_link() fails silently if date is string but can't be parsed →

the mentioned PHP bug doesn't seem to affect previous releases of Drupal core.

For those using Drupal 10.3+ they should upgrade their PHP to the latest patch level. I upgraded mine to 8.1.31
I tested the following php releases:

8.1.31
8.1.29
8.1.26
8.1.22

These above releases all worked correctly with Drupal 10.3.6 with calendar_link 3.0.3 using the above patch and my Add to calendar button produced an .ics file.

8.1.16 did not work correctly, in my case the "Add to calendar" button did not produce an .ics file

In our case our "Add to calendar" button was created with twig in a view using the calendar_link module api.

I've openned an upstream issue to follow up with the font use case

https://github.com/entreprise7pro/bootstrap/issues/3

Bootstrap 3 is no longer EOL

We're now using the entreprise7pro/bootstrap instead of twbs/bootstrap

I've stubbed an issue to investigate possible approaches to deal with the font preferences.

https://github.com/entreprise7pro/bootstrap/issues/3

Investigating providing an optional override for those who wish to shim in a solution on top of bootstrap 3. An additional CDN with the shim could be provided as an option. We could include this option by default for new installs.

Either way, I'm sure there's a pragmatic low or no disruption solution for everyone going forward.

1) The new bootstrap which is found here github.com/entreprise7pro/bootstrap is officially supported by Cinder Systems Corp and Entreprise 7pro.ca Inc. Two of the most experienced bootstrap 3 service providers for the Government of Canada.

2) Bootstrap 3 works as designed.

3) Should there be a specific usability issue relating to a specific module or specific use case it will be dealt with by capable developers who already have been doing so for a decade or so.

4) There are already thousands of installs of the new bootstrap 3 library.

5) IE support has been dropped

6) jQuery 4 compatibility resolved

7) Known CVE resolved

8) All the twitter employees have been fired by Elon Musk. Cinder Systems Corp and Entreprise 7pro.ca Inc are continuing Bootstrap 3 as a free and supported platform that is community driven.

See release notes for more details.

https://github.com/entreprise7pro/bootstrap/releases/tag/v3.4.4

Ok, some good news, patch #20 works, but only if upgrading to a recent minor release of PHP.

For example, if you are running PHP 8.1.16 with Drupal 10.3, for the calendar_link module to work correctly you must upgrade to PHP 8.1.29 or newer.

If you want to use PHP 8.1.16 successfully in my use case you have to downgrade to Drupal 10.2.

So therefore, I recommend that folks upgrade their minor releases of PHP.

I would imagine it would be similar fix in PHP 8.2 and PHP 8.3, there was some patch release update in PHP that is required by Drupal 10.3+ / Drupal 11+

Step 1)

• Please make sure your web user has write access to the css folder

Step 2)

• Please make sure your web user has write access to the js folder

Step 3)

• rebuild caches

If the css/js aggregations persist, proceed to step 4

Step 4)

• Follow instructions here: #3410301-4: Deprecate system.performance stale_file_threshold →

If the css/js aggregations persist, please look at server error logs, php logs, drupal logs and report the findings here.

Please upgrade to 8.x-3.34 , you should NOT use 5x since your theme is based on bootstrap 3, not 5 and there's currently no easy path from 3 to 5.

Currently there is no upgrade path.

@ashwathyajish, please stick to bootstrap 3 since your theme and likely your sub theme are based on bootstrap 3!

Bootstrap 3 is a recommended release and will continue to be supported. Bootstrap 5 is for new installs not intended for upgrades.

If you are using Drupal core 10.3+ or Drupal 11, then upgrade to bootstrap 3.34

Huge uptake on the Drupal 10.3 / Drupal 11 compatible release of the jQuery 4 compatible Bootstrap 3 Drupal theme. Release 3.34 was released December 2nd 2024 and already has 3061 installs!

Still needs work

✨ Views support Fixed

also busted

This functionality is broken after upgrading from Drupal 10.2 to Drupal 10.3.

TO get this functionality working

downgrade to Drupal 10.2

Needs work because the href no longer comes out data:text/calendar;

Drupal 10.3.x has busted something somehow or some twig/twig upgrade broke something.
not sure
With that said, patch 17 or MR11 fixes the WSOD problem

I'm still investigating the rest

This patch:

is identical to the MR patch:

https://git.drupalcode.org/project/calendar_link/-/merge_requests/11.patch

MR patch applies cleanly, unlike patch #2
https://git.drupalcode.org/project/calendar_link/-/merge_requests/11.patch

Patch 2 removes the closing bracket for the class.

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

Hmm, someone else points the finger at D10.3.10 as causing this.

I'm seeing this also, going to probably downgrade to the previous version of calendar_link that we were using.

In our case we're using the calendar_link with a "paragraph" entity that is referenced by a node.

I suggest reading through the release notes for 3.34 but I will give you the coles notes here.

Basically all you have to do is upgrade to 3.34 but you will have to ensure that these three modules are installed:

1. jquery_ui
2. jquery_ui_draggable
3. jquery_ui_resizable

Please report any issues you might find.

Appears to be same issue in 3.0.x, adding to 3.0.x also

I hope to hear from you soon!

@ramsesiden, are you using Drupal 10.2 or are you using Drupal 10.3?

I made a mistake when publishing release 3.33 , the core requirements should have been minimum 10.3

With that said, it could be that the regression you've found is related to another factor. I would like to assist you and invite you to contact me
directly via my d.o profile contact form so that we can resolve this issue for everyone that may eventually be affected by it.

Hello @ramsesiden, thank you very much for reporting this issue. I would like to assist in resolving this regression. Please contact me through my profiles contact form and we can set up a meeting to have a look at this issue together.

Hello @carlbowles100, please send me a message through my profiles contact form and we can set up a call to look at this issue together.

Hello @tr,
I'll clarify my ask here because I was previously confused between 1x and the light grey 2.0.x-dev release that is shown at the bottom of the project page.

1. Please tag a 2.0.0-alpha1 (or beta1) for release on the 2.0.x branch.
2. Mark the 2.0.0-alpha1 release as recommended instead of the 1.0-alpha6 release.

This will accomplish the following:

1. Provides a recommended tagged release for current versions of Drupal (^10.3 and ^11)
2. Makes our upgrades tied to a tag instead of an unpredictable dev branch.
3. Future bug reports will have a specific release version available for issues to be reported against

Thank you!

It's actually higher than drush, it's the Chi-teck drupal-code-generator
https://github.com/Chi-teck/drupal-code-generator/issues/194

https://github.com/drush-ops/drush/issues/6175

screenshot of drush gen hook when using Drupal 10.3.6

I also tried this with Drupal 11.x and it did the same thing as Drupal 10.3.

Drush Commandline Tool 13.3.3.0

drush gen hook appears to have been forgotten for this refactor. Still no OOP option for drush gen hook !

This patch should do the trick

https://www.drupal.org/files/issues/2024-12-02/3490685-06.patch →

This patch is good, needs review for patch 6, needs review because there's another similar issue in the queue but they seem to have a larger scope.

@smulvih2

FYI, there's a new module that replaces embed_block

https://www.drupal.org/project/ckeditor_insert_blocks →

I believe you had done some work on this.

The embed_block maintainer has not taken much action for a few years now and ckeditor_insert_blocks is designed for use with ckeditor5

FYI: today I just sent a message to the owner of this project asking to merge this and cut a release.

w00t!

WET-BOEW merged our pull request.

The next release of WET-BOEW will be compatible with jQuery 4 and thus compatible with Drupal 11!

https://github.com/wet-boew/wet-boew/commits/master/

Meanwhile over 1200 new installs of bootstrap 3.33 which includes the Drupal 11 in only 5 days of statistics being collected. Zero complaints from any of those.

Nice work Juraj!
Thanks!

The wxt_ext_archive functionality relies on bootstrap and the wet-boew library. GCDS is not bootstrap, is not wet-boew.

Enlighten us please.

With that said, wxt_admin doesn't seem to do much, I don't believe there's much there to worry about if we lose it in my clients build

With that said, for new installs, this module brings in other modules, appears that the patch I propose will likely resolve some conflict.

New patch

I'm going to push a patch in 🐛 wxt versions crashes on system_post_update_add_langcode_to_all_translatable_config Needs review

This dependency:
admin_toolbar_links_access_filter

Is deprecated and should be removed.

https://git.drupalcode.org/project/admin_toolbar/-/commit/b848f6fcfc9f3b...

Here's the commit that is related:

https://git.drupalcode.org/project/admin_toolbar/-/commit/b848f6fcfc9f3b...

This might be caused by admin_toolbar_links_access_filter being deprecated.

They're force uninstalling admin_toolbar_links_access_filter now. It was part of the admin_toolbar module.

Hmm, during the upgrade wxt_admin was uninstalled. Not sure if this is a problem for us but one issue is I had to delete the wxt.versions and wxt_core.versions configuration using either drush cdel or php code in a hook_update

@erik.erskine it was 2 months ago now. From two months organic memory banks in my brain I do recall working on this and I recall the timezone getting double shifted before I made that change.

The timezone needs to be set once not twice.

With that said, it was 2 months ago.

However our approach was refactored and instead of using formatters we ended up using views instead to format our dates so we're no longer using the above patch due to our strict requirements of localisation. It had to be 100% localised perfectly to our spec for both our languages and at the time there were some edge cases that we solved using views instead.

New release and instructions for those still using D10.2.

https://www.drupal.org/project/bootstrap/releases/8.x-3.34 →

Hi @danchadwick , thanks for reporting this issue.

According to this report, it means that anyone using 10.2 will want to stick to 3.32 instead of upgrading.

ah ok, nvm, I'll revisit this module in 3 to 4 months from now when we're closer to a D11 upgrade.

Giving credit, thanks for the reminder!

Moving to GCDS

Looks like nice work and thanks! Please let me know if there's an issue with this release that relates to these changes.