#Drupal 11 compatibility

After the release of Feeds 8.x-3.0-rc1 → , tests now pass. Merged the code!

I'm leaving the issue open for possible future automated fixes.

It would be good to test Commerce Feeds manually with the new Commerce 3.0.0-alpha1 release → before creating a new release.

dqd → changed the visibility of the branch 2.0.x to hidden.

Thanks, @ankitv18!

dqd → changed the visibility of the branch 8.x-1.x to hidden.

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

We can't just change this, we need to update the versions to a minimum of 10.2.0. See: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Form%21Co...

We can't just change this, we need to update the versions to a minimum of 10.2.0. See: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Form%21Co...

We can't just change this, we need to update the versions to a minimum of 10.2.0. See: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Form%21Co...

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

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

wells → changed the visibility of the branch project-update-bot-only to hidden.

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

I tested MR #145 with a new installation of Drupal 11, and it works as expected. No issues found during installation or testing.

All checks are green. I tested the ISBN-module manually as well on Drupal 11. All seems well.

I think the IE support removal is very good change too

Drupal 11 support will only be added to the 2.0.x branch.

If you know of any security vulnerabilities, pleasr let me know where to find them! If they affect current supported jQuery3/4 with bootstrap 3, then they'll be dealt with, if it's for older versions only, then no.
Keep in mind, I already gutted IE support which actually went well, was pretty straight forward.

wells → changed the visibility of the branch project-update-bot-only to hidden.

wells → changed the visibility of the branch project-update-bot-only to hidden.

wells → credited berramou → .

wells → credited sarwan_verma → .

Adding credits from 📌 Remove watchdog_exception it's deprecated Closed: outdated .

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

Have you considered splitting off the webform submodule to a different project?

Tests on D11 are still blocked on webform dependency, we need to figure out what to do with it.

One option is to remove webform from dev dependency and skip the webform tests, unless we can separate dependency for D10 and D11.

duh! yeah the core version requirements in the examples I have missed to watch after *facepalm*

Committed. Thanks everyone!

@joseph.olstad Think about never actually doing any release other than alpha1, alpha2, etc. There are known security vulnerabilities that have gone unpatched for the last 5 years.. If you're going to make new versions, you need to decide if you take the responsibility to fix those vulnerabilities or if you simply ignore them. Marking them as alpha clearly signals those releases as unsupported.

Hi Heikkiy,

When I look at the table here https://www.drupal.org/docs/distributions/degov/semantic-versioning-model → it suggests:

0.0.x = patch version for bugfix
0.x.0 = minor version update with new features that do not break functionality
x.0.0 = major, new features, breaking backwards compatability.

Well, this upgrade doesn't really add new functionality, so I think your decision to go to 1.0.4 is totally fine ;-).

Thanks for your collaboration!

smustgrave → closed merge request !57

Thanks for catching my mistake, @zeeshan_khan!

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

Reviewed and tested the patch. Everything works as expected.

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

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

jonhattan → changed the visibility of the branch project-update-bot-only to active.

jonhattan → changed the visibility of the branch project-update-bot-only to hidden.

tsecher → closed merge request !3

This looks good to me as well! Thanks for your help.

You are welcome!

We could drop support for `^8 ||` at this point, I guess?

Done!

dqd → changed the visibility of the branch 2.0.x to hidden.

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

It looks like the rector patch only added ^11 to the info yaml file. It's unclear if other Drupal 11 compatibility fixes are required against 3.x, but it's certainly worthwhile to support Drupal 11. I've manually applied the patch to the MR for ease of composer-ing.

Fixed in 1.0.4 release.

After much module testing, I now have a "working" TVI module on Drupal 11. The patch file is attached.

At this stage, the code has not gone through regression testing. If one of the module maintainers can do this at their earliest convenience, that would be great. (PS. I am a novice when it comes to Drupal module debugging / maintenance. So any pointers in this respect would be gladly appreciated.)

Done - 3.0.2

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

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

New changes LGTM, and make the module D9 compatible once again! Thanks, @ankitv18! :)

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

it has been fixed already Here

Big thanks @joseph.olstad for the efforts done here! Amazing work, looking forward to the movement of this, as it would be an amazing thing not having to go to Bootstrap 5 as some of my websites would require tons of work to achieve that

Maybe it is time to issue a new release with Drupal 11 support?

Gitlab ci file has been added manually or something so that its creation is a missing step in the change and is not registered as "new file" causing merge to fail with "file not exist". It wants to add the content to the file, but create the file. It assumes it exists already, which is not.

Not addressed yet but maybe a good hint for follow ups:

Deprecated API use for APIs removed in future Drupal major versions is not required to fix yet.

web/modules/contrib/duration_field/src/Element/DurationElement.php 41 Class Drupal\duration_field\Element\DurationElement extends deprecated class Drupal\Core\Render\Element\FormElement. Deprecated in drupal:10.3.0 and is removed from drupal:12.0.0. use Drupal\Core\Render\Element\FormElementBase instead.

web/modules/contrib/duration_field/src/Element/GranularityElement.php 20 Class Drupal\duration_field\Element\GranularityElement extends deprecated class Drupal\Core\Render\Element\FormElement. Deprecated in drupal:10.3.0 and is removed from drupal:12.0.0. use Drupal\Core\Render\Element\FormElementBase instead.

wow very strange comment #23 vanished.

I've figured out how the cdn works, but I haven't added it to the docs, here it is:

css: https://cdn.jsdelivr.net/gh/entreprise7pro/bootstrap@v3-dev-2/dist/css/bootstrap.min.css
css_theme: https://cdn.jsdelivr.net/gh/entreprise7pro/bootstrap@v3-dev-2/dist/css/bootstrap-theme.min.css
js: https://cdn.jsdelivr.net/gh/entreprise7pro/bootstrap@v3-dev-2/dist/js/bootstrap.min.js

Also made a host for the docs.

https://bootstrap.7pro.ca/

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

Close this as duplicate of the youngest identical upgrade bot issue 📌 Automated Drupal 11 compatibility fixes for view_entity_ref_field_formatter Needs review Maintainers: it is recommended to have a latest branch/dev release available. This works best with the upgrade bot to prevent hiccups.

Close this as duplicate of the youngest identical upgrade bot issue 📌 Automated Drupal 11 compatibility fixes for view_entity_ref_field_formatter Needs review Maintainers: it is recommended to have a latest branch/dev release available. This works best with the upgrade bot to prevent hiccups.

Close this as duplicate of the youngest identical upgrade bot issue 📌 Automated Drupal 11 compatibility fixes for view_entity_ref_field_formatter Needs review Maintainers: it is recommended to have a latest branch/dev release available. This works best with the upgrade bot to prevent hiccups.

DeprecationHelper also introduced in D10.1 so it's better if we can stick with FileSystemInterface::REPLACE until the minimum support is D10.3 or later on at the time of the D12 readiness.

cc: @damienmckenna

Ok I've spent some time on the fork, upgraded bootstraps javascript to accept jQuery 4. I removed nearly all microsoft IE support from the entire branch. I am able to compile all of this, it is compiling and I have compiled it and pushed it up and made a github release of bootstrap and called it v3-dev-1
the actual release once it's tested and people are happy with it will be 3.4.2

Here's the zip file you can try out, with the dist folder has the compiled js and css
https://github.com/entreprise7pro/bootstrap/archive/refs/tags/v3-dev-1.zip

There's also the same thing in tar.gz
https://github.com/entreprise7pro/bootstrap/archive/refs/tags/v3-dev-1.t...

Hi @jncventura, ok, do you have a github account? Perhaps I can grant you admin access to my fork.
BTW
https://github.com/entreprise7pro/bootstrap/archive/refs/tags/v3-dev-1.zip

I appreciate folks helping to review this build of bootstrap against Drupal 11.

Thanks

avoiding an unnecessary drupal module/module-fork would be good.

If this module shifts from depending on and installing the original Bootstrap JS package towards depending on and installing the fork linked above, I think this should be documented and explained with thorough detail on the module home page... why it is that we needed to fork, whose behind "enterprise7pro", etc.

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

@joseph.olstad in #23 (which is weirdly unpublished), you suggested to fork twbs/bootstrap and have the build method be a Drupal method. You should be fine with just adding GitHub Actions to the fork you just did in GitHub to generate the minified Javascript libraries. Then, the only change would be to the libraries.yml of this theme to fetch the libraries from GitHub.

There's zero need to create a Drupal module when the code you forked does not use any part of Drupal.

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

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

Fixed. Will be on the next release.

Merged in the previous code and new code. Looks good!

I'm working on a 3x fork, the main branch is the v4/v5 stuff, v3-dev is the 3x dev branch, I'll set this as the default branch shortly.
Fork is here:
https://github.com/entreprise7pro/bootstrap

It could use \Drupal\Core\Utility\DeprecationHelper::backwardsCompatibleCall() and selectively use FileSystemInterface::REPLACE or FileExists::Replace, right?

I'm not fully following the discussion here, but if it is possible to make this module D11 compatible, that would be greatly appreciated. Migrating to Bootstrap 5 would be a momentous task.

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

@jncventura, perhaps I'm missing something however radix is already doing something similar to what I'm suggesting we do. With that said, there's maybe a manual step that the radix project does. The Bootstrap license is an MIT License, which afaik, is compatible with Drupal licensing. Perhaps there's a nuance I'm missing here?

The jQuery 4 compatible version of Bootstrap should not be a Drupal extension at all. It should probably be in GitHub and a simply be a fork of the existing sources.

Ok, thanks for that @jcnventura.

We'll 100% for sure have to fork twbs bootstrap and remove that version check and any IE11/IE10 specific js code, should be a fairly easy task.

Suggest that we add a contrib module , example, call it bootstrap3, in there would be the build sources and compile instrucitons, this is where we'd have the new version of bootstrap and it would generate an optimized min js that we'll consume and add as a dependency for use by the bootstrap theme.

Some refactoring involved, I am imagining that this is 100% do-able.

The radix theme actually includes bootstrap sources in it's builds, we could do something similar to what radix does but I think to align with how we've been doing things for years and to avoid hacks (radix can get messy), I'm suggesting putting it in a support module called bootstrap3 (for example).

@joseph.olstad in #10 was the point where I got this theme to work in Drupal 11. The upstream bootstrap code has a test early on that checks for the version of jQuery being used. If it detects jQuery 4, it throws an error and refuses to run.

My efforts stopped at that point, as asking a Drupal theme maintainer to co-maintain Bootstrap 3 is simply too much to ask (even if it is maintaining a patch and not the full library, I think it will eventually become the full library).

We have 2 years to migrate away from Bootstrap 3. I think the best solution here would be a tutorial on the best way to migrate from this theme to another of the Bootstrap 5-based themes.

While reviewing this I realized that the change from FileSystemInterface::REPLACE to FileExists::Replace makes the module require 10.3: https://www.drupal.org/node/3426517 → I'm not sure I want to drop 9 and 10.2 entirely yet. Argh.

Would it be possible to support D9 and maybe leaving D12-level deprecations until later? I'd prefer to support D9 if possible. Thank you.

Here is a full list of changes in jQuery 4: https://blog.jquery.com/2024/02/06/jquery-4-0-0-beta/

Maybe it is doable, maybe even this module could provide own fork of JS files of bootstrap

Postponed. The following modules required to be updated first:

• 📌 Automated Drupal 11 compatibility fixes for campaignmonitor Needs work
• ✨ Drupal 11 compatibility fixes for webform Needs work

vladimiraus → changed the visibility of the branch 3435621-automated-drupal-11 to hidden.

@benstallings - You have added "Related issues: #3465786: Add support for Drupal 11" this one is for tailwindcss project not for encrypt so I am opening it again.
Please correct me if I'm wrong.

We'll have to change support to a minimum of 10.2 for this. I don't have a problem with that. In some cases a new branch/version has been done for this and in some cases it has stayed on the same. If we ever do need to fix anything with a D9 compatible version, then we will need to cut a new branch and 2.0 version.

Made some final adjustments. @rajeshreeputra are you able to merge issues as well? Or are we still waiting for @bohart? Should we contact him via mail?

@emilorol thanks for the fix. See MR!47.

The test failures seem unrelated, since tests have not run automatically for a while now.

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

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

This looks good to me as well! Thanks for your help.

We could drop support for `^8 ||` at this point, I guess?

Added the GitlabCI yml file, phpunit tests are green, other non-critical tests are failing but that can be fixed in a follow-up issue.

I will move this to RTBC and would like to merge in the next 1-2 days unless a review comes in that blocks that action.

It would be good to have both D11 support as well as (GitlabCI) tests running again.

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

Can be closed now that D11 is out. Thank you SO MUCH!!

Picking this up and hijacking it to add the GitlabCI integration

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

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

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

Available in the `dev` branch.

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

marcoscano → credited minirobot → .

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

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

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

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