Use Image URL filename in <img src> tags

@kyle Clark check out my workaround at https://support.zendesk.com/hc/en-us/community/posts/4409217209370-Tip-Click-to-view-full-size-image-in-lightbox-or-modal

Katarzyna Karpinska, URGENT please. A new update to ZD has broken all of our images again as soon as we edit an article. We were displeased with having to manually add filenames to img src tags, but it worked as a solution with fancybox. Now we have no workaround. As soon as we edit any text on a page, all images break in fancybox again. Adding the filename to the extension does not work. This is critical to our site, please let us know how to get this working again. 

Another change to Zendesk images has once again broken this workaround. I can't seem to figure out what broke now.

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>

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. 

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. 

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).

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?