Use Image URL filename in <img src> tags
Feature Request Summary:
Go back to using image filenames and suffixes in the <img src> code. A recent change to Zendesk code has impacted a common workaround to the lack of image Lightbox functionality. https://support.zendesk.com/hc/en-us/community/posts/4409217209370-Tip-Click-to-view-full-size-image-in-lightbox-or-modal
Description/Use Cases:
Zendesk does not have a native image Lightbox feature. Workarounds include zooming images. In order to impact just one image type, the Zendesk community developed code to assist this.
Business impact of limitation or missing feature:
Before, when you added an image, the code looked like:
Participants that arrive earlier than one hour before the session will
see a warning to come back within one hour of the appointed time.<br>
<img src="/hc/article_attachments/9540102520987/Live_FC_Early_Entrant.jpg" alt="Live_FC_Early_Entrant.jpg">
Now, the code looks like:
Participants that arrive earlier than one hour before the session will
see a warning to come back within one hour of the appointed time.<br>
<img src="/hc/article_attachments/9540102520987" alt="Live_FC_Early_Entrant.jpg">
This breaks the functionality. You have to now copy the filename and filetype to the <img src> code every single time. This is highly inefficient and not scalable.
Other necessary information or resources:
-
This seems like a bug, not a feature. This is breaking our use of fancybox to provide image zooms when clicked. Why in the world would a standard src tag not contain the full image path & filename?
-
Thank you both for your comments. As much as I'm sorry for the inconvenience this change caused you, we are not planning to reverse it.
To give you a bit of a context - this change was necessary to introduce new reusability features in Account Level Gallery (e.g. replacing images in all their placements) as well as future improvements for image management (e.g. renaming files in the gallery).
-
Katarzyna Karpinska thank you for the response. Why weren't we warned well ahead of this change that functionality would be broken? The change would've been better received had we known it was coming. It's akin to making a change to an API that may break customer scripts or integrations. We would never do such a thing to our customers without at least 30-90 days of notice. We chased this issue through a support ticket for almost a full month before the source of the problem became clear. It's almost as if this was done secretly, which greatly damages our trust with Zendesk.
Are the enhancements you're talking about right around the corner so that the pain is minimized? If we're talking a month or less, we can deal with the workaround, knowing a better, native image magnifier / viewer is on its way. -
Hi Kyle Clark,
As I stated before I'm sorry for all the inconvenience caused. However, I'd like to point out that the HTML of the articles is not a Zendesk-supported public-facing API. We need to continuously develop and change it to be able to introduce new functionalities and keep our product up to date and we are not able to track all the 3rd party custom scripts that are built on top of it. -
We've experimented a little bit with the Fancybox plug-in to see if there is any way to make it work without the image name. This is by no means an official solution but rather a suggestion on what could be done. We really hope it may get you on a right track.
Below you see a snippet using the very old Fancybox JQuery integration. When the snippet is placed at the bottom of the article page in the custom theme (
article_page.hbs
), it will find all image tags in the article body and add a click handler to each image. When the user clicks on an image, it will fetch the attachment data from the API, assert that the image has the correct content type and open the Fancybox.<link rel="stylesheet" href= "https://cdnjs.cloudflare.com/ajax/libs/fancybox/3.2.5/jquery.fancybox.min.css" type="text/css"> <script src= "https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.3/jquery.min.js" integrity= "sha512-STof4xm1wgkfm7heWqFJVn58Hm3EtS31XFaagaa8VMReCXAkQnJZ+jEy8PCC/iT18dFy95WcExNHFTqLyp72eQ==" crossorigin="anonymous" referrerpolicy="no-referrer" type= "text/javascript"></script> <script src= "https://cdnjs.cloudflare.com/ajax/libs/fancybox/3.2.5/jquery.fancybox.min.js" crossorigin="anonymous" referrerpolicy="no-referrer" type= "text/javascript"></script> <script type="text/javascript"> const contentTypesWithZoom = ['image/png', 'image/jpeg']; const images = document.querySelectorAll('.article-body img'); const attachments = {}; const fetchAttachment = async (id) => { // retrieve cached attachment data if (attachments[id]) return attachments[id]; // fetch attachment data try { const response = await fetch(`/api/v2/help_center/articles/attachments/${id}.json`); let attachment = null; if (response.ok) { const data = await response.json(); attachment = data.article_attachment; // cache attachment data attachments[id] = attachment; } return attachment; } catch (e) { console.error(e.message); return null; } } // run through all images and attach click handlers for (const image of images) { const src = image.getAttribute('src'); const m = src.match(/^\/hc\/article_attachments\/(\d+)$/); if (!m) continue; const attachmentId = m[1]; image.addEventListener('click', async e => { const attachment = await fetchAttachment(attachmentId); if (!attachment) return; // only allow specific content types if (!contentTypesWithZoom.includes(attachment.content_type)) return; $.fancybox.open([{ src : src, opts : {}, }]); }) } </script>
Vous devez vous connecter pour laisser un commentaire.
5 Commentaires