Problem/Motivation
On the Swiper template config form, there are links to download local copies (minified and plain) to use local rather than CDN versions. The project page documents briefly using v11 of the Swiper code for the 2.x module, but the links to the Swiper library point to the v8 code.
Steps to reproduce
Install module
Create or edit a template (default for example)
Follow links to relevant Swiper files
Proposed resolution
Change links to point to correct v11 files
Correct links:
swiper-bundle.js : https://cdn.jsdelivr.net/npm/swiper@11.1.10/swiper-bundle.js
swiper-bundle.css : https://cdn.jsdelivr.net/npm/swiper@11.1.10/swiper-bundle.css
swiper-bundle.min.js : https://cdn.jsdelivr.net/npm/swiper@11.1.10/swiper-bundle.min.js
swiper-bundle.min.css : https://cdn.jsdelivr.net/npm/swiper@11.1.10/swiper-bundle.min.css
Remaining tasks
Make the changes
User interface changes
Text description and links changed
| Comment | File | Size | Author |
|---|---|---|---|
| swiper-file-links.png | 19.44 KB | dreamleaf |
Issue fork swiper_formatter-3470178
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:
Comments
Comment #2
dreamleafOoops sorry, accidentally made the changes in the 1.0 branch, replicated in correct issue branch.
Comment #4
bbu23Hi,
The module uses
unpkg.com/swiper@11/<FILENAME>[FILENAME]instead of the specific versions proposed in the description. If we add the proposed change as it is, then there will be a version mismatch. Is there a reason why you didn't just update the number 8 to 11 without changing the domains?Thank you!
Comment #5
dreamleafIf I remember right, the unpkg links didn't work with version 11 (no idea why) so I grabbed links from the official Swiper docs for the CDN. My ultimate goal was to just get the version working as it was being really buggy with the incorrect version.
So yeah, I selfishly didn't consider those with it already setup, but considering it was really buggy, they would have needed to change the local file in their library anyway as the module doesn't do that part.
Comment #6
bbu23I see and it's understandable. Makes sense.
But now that the links are working, I think we should have the same in both places: libraries and help text.
Comment #7
dreamleafAgreed, would it also be sensible to have the links for version 11 as:
https://unpkg.com/swiper@latest/swiper-bundle.min.css
Or does it need to be fixed to a specific known working version?
Comment #8
bbu23I think major versions should be updated by us (my opinion as a co-maintainer), it's a bit risky to have them change on the fly without prior testing. I'll have the maintainer confirm as well.
Comment #9
nk_ commentedI agree that we shouldn't run new version as they come, that was after all the original reason for not defining url with @latest, or the other token. So let's keep it as it is for now.
In fact, I believe it is worth considering implementation of https://asset-packagist.org/ or similar, at least as an approach.
Comment #10
bbu23Sounds good, thanks for confirming.
In this case, let's solve the issue at hand by matching the values from libraries. A separate issue can be open for the library management if needed.
So, the values in the MR should match the values in the libraries definitions.
Comment #11
dreamleafThere's been some talk this year about asset-packagist reliability:
See:
https://www.sitback.com.au/insights/article/working-with-javascript-in-d...
& https://github.com/darvanen/drupal-js/tree/main
While I'm not really loving the proposed way that works, it may be worth chasing the rabbit and seeing if there is any more consensus on external JS inclusion methods?!?
Comment #16
bbu23Comment #18
bbu23The original issue has been fixed. The links now point to the correct major version of the external library.
For any other issues, feel free to open a different ticket.
Thank you for your contribution!