Unzipping zip file holding HTML templates within a course doesn't resolve all paths to resources
When I unpack a zip file holding modified HTML templates in a Brightspace course (Sandbox) it doesn't resolve all paths to resources. For example, the paths to the CSS stylesheets are resolved correctly. It looks something like this:
<link rel="stylesheet" type="text/css" href="/content/enforced/Sandbox/Brightspace_HTML_Template_v3_WH/_assets/thirdpartylib/fontawesome-free-6.1.1-web/css/all.min.css">However, for some script files, e.g. bootstrap.min.js, popper.min.js, jquery.min.js (other scripts files, like the script.min.js and custom.min.js resolve correctly and some images in the footer the paths are not resolved correctly. These paths look something like this:<script src="../_assets/thirdpartylib/bootstrap-4.6.2/js/bootstrap.min.js"></script>Or for the images in the footer, as follows:<footer><img id="logo" src="../_assets/img/webp/logo.webp" alt="Logo" width="128" height="82"> <img id="logo-dark" src="../_assets/img/webp/logo_dark-mode.webp" alt="Logo" width="128" height="82"></footer>I correct the paths manually afterwards, but that's quite a drag :(For what reason do some path not resolve after unpacking the zp files within a Brightspace course? And, more importantly, what can I do to make the paths to these resources resolve correctly?Do other HTML templates users also encounter this problem, occassionally?Kind regards,ArmanAnswers
-
Hi Arman, thanks for reaching out to let us know what you're experiencing. We recommend connecting with your institution's IT Help Desk to investigate this further. If you need some help finding that contact information, please send me a direct message and I can assist you with that!
-
HI @Arman.V.176
Since they're modified templates, the simplest cause is likely that there is an error in those file paths ex. they may have a hard coded (ex. a path that may contain the organizational unit etc. from the location the templates were originally developed in) vs. relative file path (ex. that is leading to the wrong location.
While using a relative path can help to cut down on some of these issues you have to be careful that all of the resources that you're adding into the course are:
1) housed in the folders those relative paths point to (a common issue I've run into is where a resource actually lives in shared files, not manage files. Those won't export with the zip and if imported to another site will appear broken)
2) That subfolders aren't changed in name or locationI don't have an easy tool to help in the trouble shooting when these things happen- I also wind up trying to find one problem ex. the logo that won't load, and then try to trace back the file paths and resources to make sure they connect.
I could be wrong about what's happening in your specific experience- and there could be something else afoot.
To determine if there is a bug, Alex's suggestion is a good one to create a case to review a specific example of this behaviour with a Support Agent. -
Hi,
Actually, almost all paths resolve correctly after first saving the HTML page. So the paths then correctly point towards the css stylesheets and the various script files. So, that's great! :) For example, after saving the main stylesheet is referred to as follows: <link rel="stylesheet" type="text/css" href="/content/enforced/My_Course/html-bs5/_assets/css/custom.css">
Only the paths of the <source> within a HTML <picture> element do not resolve correctly. They still refer to the local production folder as follows: srcset="../_assets/img/background-img/small/background-img-2.webp". The same holds true for the other <source> within the <picture> element. I can change the paths manually and thereafter everything works fine. However, I think it's a bridge too far for most teachers within our organisation to do this themselves within the source code.
By the way, If I do not use the <picture> element, but only an <img> tag the path to the image resolves correctly. However, then the same image is served irrespective of screen size, Loading a large image and display it much smaller should be avoided to save bandwidth. Loading a small image and display it much larger should be avoided to prevent pixelated artifacts.
I guess, it's specific for the <picture> element. It could be a quirck of Brightspace. Do you happen to know of other users that implement the <picture> element also have this problem. Or how I can have the paths within the <picture> element to resolve correctly?
Knd regards,
Arman
-
Moreover, the problem that the paths do not resolve correctly after unzipping also occurs when using the
<img srcset="" src="" alt=""> syntax is for serving differently-sized versions of the same images for different screen sizes and pixel-densities.The paths to the images which are referred to using srcset attribute do not resolve correctly (still the same as my local project). Since the <piture> element also uses the srcset attribute, I guess it has something to do with this srcset attribute. @Stefanie.B.518 Do you know if this s something specific for Brightspace? I guess I'm not the first person to use the scrset attribute.Kind regards,Arman -
Hi @Arman.V.176
I'm so grateful to you for the update on that!
Truly, I'm glad to hear that nearly all paths are working as expected- and the note on <picture> vs <img> is interesting even more so do to your observation about srcset
I'm going to share this with colleagues here at D2L who work on custom content for clients using our templates as well as the folks who developed the last template pack.
I haven't used that attribute before- but they'll be much more knowledgeable than me about this.