Inline images in Guide articles display for all users as a broken link or don't display for anonymous users or end users.
This problem occurs where images are attached as inline attachments to another article that is:
- Restricted to a specific group of users
- In draft status
- In archived status
Due to any of these reasons, the image is displayed as a broken link, followed by the name of the image:
These are options to fix the problem. If the article is:
- If the article is restricted to a specific group of users, update the restriction settings.
- If the article is in draft status, publish the article.
- If the article is in archived status, restore the article.
Alternatively, download the attachments and upload them individually to each article or use the Guide assets section. This is the recommended approach.
To identify the location of attachment in the original article
- Inspect the individual element in the console and copy its unique numerical ID:
Run the following API call for article attachments:
Replace the subdomain with your subdomain name and the unique ID value with that of one the original article inline attachment.
You'll get the response below that retrieves the original article source.
"display_file_name": "Screen Shot 2020-02.png",
After you've identified the article's unique ID, add it to any knowledge base article editor and this returns the article, for example:
For more information, see the section: Working with articles in the knowledge base.
Are there any developments/new fixes for this issue? I agree, this is not a sustainable solution at all. Plus the behavior of this issue is inconsistent so it's difficult to avoid. A few of our users have already reported articles with missing images and we don't know how to exactly avoid it.
workaround is that you first create article, then obtain article id, which you use when uploading attachments so that attachments are tied to the article. In response json you get an absolute attachment path so you can use regex to substitute relative paths in your article for absolute paths obtained as a response of attachment upload and then use article update API to upload / publish your article with proper attachment paths.
Thanks for all your comments! Very helpful and looking into my issue now to see if this works. :)
This is a huge issue if using any kind of API to automatically publish articles into Zendesk. I am using MadCap's Zendesk Connector, and so many images are broken. Because it is published through the API, I cannot manually adjust in Zendesk.
Is there an estimate for providing a fix, rather than just a workaround?
I think it's a bit of a cop-out to just say "If the article is restricted to a specific group of users, update the restriction settings."! We NEED our articles to be restricted by user group, in order to protect intellectual protocol. It's OK once the users are logged into Zendesk - they can see the images they're supposed to. The problem is that we are also displaying the articles on our app via a Pendo widget. In that widget, users can see the articles they're supposed to, but all the image links in the articles look broken as the images are hidden behind SSO in Zendesk, and there appears to be no solution.
Any update on this issue?? I have been adding screenshots as I go when creating articles - they were fine at the time of publish, however, it seems like the images copy-pasted always become broken after a while but not the ones that were uploaded.
The same issue here. We've started uploading images in GC and then adding absolute image links, but this creates additional work.
I've been in a long back and forth emailing their support. They insist that it's a problem with my images being in draft mode, or inline, or restricted. But it's not the case. What I find is that the issue is inconsistent. I thought I figured out a workaround but after a week, some images had the problem again. It's hard to figure out even a workaround when the problem is inconsistent. :(
Does this problem occur when attachment limits are exceeded?
This shouldn't normally be the case when attachment limits are exceeded. Usually, this is the warning/error that you'll get when the attachment limit is reached in an article:
For more information, see Guide product limits for your help center
We had this same issue happen again today after being plagued by it sporadically for a few years. I spent some time testing to try to diagnose what's happening and here's what I think I've found.
Images break on an article if the image was copied (copy/paste) from another article and then the original article is deleted or the images are deleted from the 'images included in the article' interface (where you can upload images to the article). Archive does not affect the images, only deletion of the article or images from the article library of images.
What appears to be happening is that when you copy/paste into the new article, the image is still referencing the image added in the original article. The copy/paste does not add the image to the new article's image 'library'. Once the source image is gone, the image breaks in the new articles.
"Run the following API call for article attachments" is not a useful step. I have no clue how to run an API call. This issue is happening increasingly, apparently randomly, and is extremely painful. Are there any directions that are more useful for someone who is not an engineer?
I use the Zendesk Knowledge Base Sync for Confluence app to sync articles from Confluence to Zendesk.
A year ago, I had to resolve an issue where users couldn't see images in articles that had been synced, permissioned, then updated. I determined that, for end users to see images, the images must be uploaded (using the Zendesk API for attaching images) to the Article images tab and not the Unused images tab. I had to get the sync app provider to fix the sync app.
This year, in January, images in Guide articles started displaying as a broken link or didn't display for anonymous users and end users. I determined that Zendesk began enforcing an attachment limit of 500. (We couldn't add the 501st.)
The sync app I'm using uploads images to Zendesk within the article (not attached to the article) as NEW attachments every time the article is published from Confluence. The sync app adds references to the latest attachments.
When the attachments cannot be uploaded to Zendesk due to attachment limits, then the images do not get attached to the article (and thus do not appear in the article). To resolve this problem for pages over the attachment limit, the attachments must be removed and the pages must be re-published. The UI in Zendesk didn't allow for deleting images in bulk.
I let the sync app provider know about the issue.
Meanwhile, I wrote and ran API scripts to determine which pages are over the attachment limit and remove their attachments (nearly 40,000). (Typically, the pages over the attachment limit are older not newer.) I set up a process to monitor and handle pages approaching the attachment limit. (Each time an article is published, my script removes all but the latest versions of the images from the article so the number of attachments stays below the limit.)
If you're using an app to push content to Zendesk, consider reaching out to the app provider to adjust the app to keep images under the limit.
Hi Bruce, I am concerned that I might be running into a similar problem. I am using the connector from Madcap Flare to publish changes to Zendesk Guide.
I ran a publish on April 8 and tested the articles. They were fine. I looked this morning, and many many images are missing.
How do you determine which articles have too many images uploaded? When I check the Images tab in my article, I see "There are no images loaded in this article". Is that what it looks like when you say "then the images do not get attached to the article and thus do not appear in the article"?
I am not an API developer, so writing API scripts is out of my wheelhouse. Is there another way? Can you provide some guidance?
Thanks for sharing,
My issue is no new attachments can be added when there are already 500 articles.
If you are seeing "There are no images included in the article", then no images are being attached when the article is synced.
We'd appreciate a long-term solution to this issue. We've been on Zendesk for 3+ years and this is the first time we've encountered this issue. The ideal situation here is that anyone who browses over to our public KB should be able to view the images in our articles.
Hey everyone, I've been able to replicate and understand the issue.
The issue caused by copying and pasting the same image from another Help Center article, this means the image will be directly linked to the same image in the other article. If any of those articles are deleted, it will delete the location of the image which will result in this issue.
The solution to this is, if the image is already on your device, just reupload it instead of copy and pasting. If the image is not on your device, download the image onto your device and reupload it to the new article. This will establish a different link to the image, in the event one article is deleted, the image will not be lost.
Hope this helps 🙂
We have some articles where images work on Chrome browsers on PC but not on Firefox browsers on PC. Also, the images do not work on Chrome browsers on Android and iOS devices. But again they are working on Chrome browsers on PC. Is this the same issue or something different?
Shawn Matts, this sounds like a different issue. Would be great to see it with examples and quite possibly more investigation. I'd advise you to rise a ticket for this.
I get a different type of issue.
Images display fine when viewing via the Help Centre (agent or end user), but when an agent tries to view the same article in the Knowledge Capture App (ticket app sidebar), the images don't display.
Tried recreating the images in the article from scratch but still no joy.
I have tried to replicate it on my end but was not able to experience the issue, I have even used SSO for it. Please check if your agents have already cleared cache and history and other troubleshooting steps here. If the issue persisted, please contact our support directly and we'll investigate further.
Please sign in to leave a comment.