Drupal 11 issues

[occupant]

Just recently started testing in Drupal 11 and it looks like jQuery is at version 4.x. This breaks the CLF javascript (including bootstrap, both local and CDN versions)

Some initial thoughts on ways to alleviate:

• bundle a local copy of bootstrap 5 and update any CLF-specific js, and avoid the CDN entirely
• look at some kind of compatibility layer (assuming one exists) and add that to the theme's dependencies
• ?

Regardless of approach, it will mean a new release version I think.

[joelpittet]

My preference is to split away from the CDN. Decoupling from the CDN means less standing on our head 🙃.

[joelpittet]

Could you post the errors/issues on here so we can be more specific @occupant?

[occupant]

For sure.

The errors I see in the console are from js/clf/ubc-clf.min.js

Clicking on the search / navigation dropdowns (bootstrap collapse) triggers:

TypeError: a.camelCase is not a function. (In 'a.camelCase(["scroll", b].join("-"))', 'a.camelCase' is undefined)

The same error happens with the CDN version of the CLF.

Dropdown behaviour (ie. main menu subnav) does seem to be working, so it looks like it's isolated to the collapse behaviour.

I also am seeing a 404 (https://cdn.ubc.ca/clf/globalutility/index.php?jsoncallback=? ). Looking at the current version of the CLF CDN js (https://cdn.ubc.ca/clf/7.0.5/js/ubc-clf.min.js), it looks like the endpoint has changed to https://cdn.ubc.ca/clf/globalutility/index.js. This should be a simple fix.

We could probably clear up the error in bootstrap-collapse.js and rebuild, but it seems like a house of cards and incentivizes not moving forward.

[joelpittet]

Do you happen to have a contact for anyone maintaining the CLF that we could reach out to and collaborate on a solution? Dropping the CDN might not align with their goals, but from my perspective it’s the best path forward — mostly because I value local development without internet access and minimizing external dependencies. We’ve seen how well relying on external stuff worked for our Twitter widgets… 🤦‍♂️

[occupant]

I do, yes. It's Michael Kam in central comms. I'll reach out to him.

[occupant]

@joelpittet perhaps getting ahead of myself, but I made a proof of concept branch #84 that:

1. Adds a local version of bootstrap5 and popper (popper is in core, but just did this in case there were issues with the versions - should investigate using the core version)
2. Edits js/clf/ubc-clf.min.js to remove bootstrap and update the CLF custom js, fixing the 404 mentioned above (https://cdn.ubc.ca/clf/globalutility/index.php?jsoncallback=?)
3. Updates the local library version (probably want to update the other CLF library definitions as well)
4. Updates the templates that use data attributes to their bootstrap 5 equivalent.

This is more or less what we've been doing with Kraken without issue for several years.

[joelpittet]

@occupant it's well overdue to drop bootstrap 2, right? And the conflicts with newer or different libraries are painful to fight against.

From what I saw in Michael's email to us, they’re planning to move in that direction too. Might be time to make the legacy CDN opt-in, or maybe (better) just drop support for it altogether?

Not sure we should maintain a BC layer, it would be nice help transition people though... is there a middle ground? Anyways glad you are putting the PoC out here!

[occupant]

@joelpittet , yes, it absolutely is overdue, I don't think anyone would disagree with that. I think the best we can offer in terms of CDN support is the CSS. Which then begs the question, is that even necessary? I'd say no and suggest we make all assets local.

We could update the CDN libraries to point to local equivalents (leaving the namespaces intact), which should cause minimal impact. I'll try that out and see if anything unexpected crops up.

[joelpittet]

Yes, "all assets local" is a good start, then it's at least "fixable" without specificity and !important.

[occupant]

@joelpittet I've updated #84, moving all CDN assets to local locations and updated the libraries to use those. There's a lot of redundancy in the libraries file, but it does let us maintain a fairly straightforward update path.

So far (other than a few small css tweaks I had to make due to changed use of the 'in' and 'show' classes in bootstrap) it all seems to be ok in limited testing

[joelpittet]

@occupant so the plan is to leave all the libraries named clf-cdn-* in there for BC but make the assets the load local, to keep the changes low? I agree with that approach, just confirming

[occupant]

@joelpittet Yes, I think that might cause the least disturbance for anyone upgrading