CDN links have disappeared?
CDN links have disappeared?
We have a webapp that uses the datatables CDN and it has suddenly stopped working.
Looking into it, it seems that the CSS and JS files on the CDN no longer exist.
We are using the following URLS:
https://cdn.datatables.net/w/bs/dt-1.10.18/fc-3.2.5/fh-3.1.4/r-2.2.2/datatables.min.css
https://cdn.datatables.net/w/bs/dt-1.10.18/fc-3.2.5/fh-3.1.4/r-2.2.2/datatables.min.js
Is this a known issue? How can we resolve it quickly so our customers can use it again, then what do we need to do to resolve it properly?
This question has an accepted answers - jump to answer
Answers
It seems that switching https://cdn.datatables.net/w/ to https://cdn.datatables.net/v/ makes it work, but I noticed in our code that at one point we used /v/ and we switched to /w/ - What is (was?) the difference between /v/ and /w/? I tried playing in the datatables download builder, but can only get /v/ for the CDN URL. I'm a little scared to change them all to /v/ without knowing what the difference is!
Sorry! I had forgotten that at one point I used the
/w
CDN prefix. I've fixed it now.I've transferred the CDN to a different server today and thought I'd tested everything, but got this, and the CORS on .json files wrong.
There is effectively no difference between them. It is an artefact of how the CDN builder used to work - there use to be actual files on the server for each one, and the directory name was one way of handling the massive directories. The newer node based file builder doesn't have that limitation, so the /r, /v, /w (etc) paths all just point at the same node process now.
Allan
No worries, thanks for fixing it so quickly!
jQuery UI icons still don't work. We use this link:
https://cdn.datatables.net/v/ju-1.12.1/jq-3.3.1/jszip-2.5.0/dt-1.10.23/b-1.6.5/b-html5-1.6.5/fc-3.3.2/fh-3.1.8/rg-1.1.2/sc-2.0.3/datatables.min.css
The css loads but there are links to background images (icons) that are broken. For example:
background-image:url("/jQueryUI-1.12.1/themes/base/images/ui-icons_444444_256x240.png")
Browser tries to load the image without /v/ part of the path and it fails.
Apologies for having missed that and thanks for letting me know. Fixed now.
Allan
Thank you!