By default, Help Center quarantines unsafe HTML tags and attributes in articles to reduce the risk of somebody introducing malicious code. See the list of safe tags and attributes below.
The unsafe HTML is not stripped from the articles on the server. Rather, it's not included in the HTTP responses sent to browsers. As a result, articles might not render as intended in browsers. You can override the default setting to allow all the article HTML to be sent to a browser.
Warning: Making this change will allow potentially malicious code to be executed when users open an article in a browser.
To allow unsafe HTML in HTTP responses
- In Guide, click the Settings icon (
) in the sidebar. - Under Security, select the Display Unsafe Content option.
- Click Update.
Safe tags
strong, em, b, i, p, code, pre, tt, samp, kbd, var, sub, sup, dfn, cite,
big, small, address, hr, br, id, div, span, h1, h2, h3, h4, h5, h6,
ul, ol, li, dl, dt, dd, abbr, acronym, a, img, blockquote,
del, ins, u, table, thead, tbody, tfoot, tr, th, td, colgroup
Note: Even if Help Center doesn't strip safe tags, the third-party HTML article
editor used in Help Center (TinyMCE) may strip some safe tags from the HTML. For example, the
editor removes
<i> tags with no content, such as those used for Font Awesome
icons.Safe attributes
href, src, width, height, alt, cite, datetime, title, class, name,
xml:lang, abbr, target, borderEverything else is considered unsafe.
27 Comments
If the i class is stripped, what is the workaround for using Font Awesome icons then?
For example, if I add
It gets removed from the html in my article.
Hello Nicole,
One of the features of WYSIWYG editors is that they will "clean up" HTML that they do not support. For example, <bold> is not supported with our WYSIWYG but <strong> is and thus bold tags are removed.
I did some digging into this for you and currently, the WYSIWYG editor that we use in our help center does not support this tag, so at this time there is no workaround.
I'm sorry I couldn't give you better news on this, but please let us know if there is anything else we can help with.
Sincerely,
Patrick | Tier 1 Advocate
Is there a workaround for centering <td> elements? I'd like my bullets to be centered, rather than left-aligned.
Hey Tami!
So not all HTML would be supported in the editor, but I was able to use the following class with some success:
It basically indented the list a bit as opposed to the left justification.
Hope that's useful to you!
So... Font awesome is not supported?? How do i add icons then?
I cant find the option to Display Unsafe Content under Settings. Can you please help?
Hi Ruth -
Make certain that you are in the Guide Admin and not the settings for Support. You can toggle this using the four grey boxes in the upper right-hand corner of the screen.
From there, click the gear icon in the left-hand pane. This will take you into the settings.
Then, scroll down to the section titled "security" and you will see a box you can check next to "Display unsafe content."
Hey Alexia,
There are some "hacky" way to get Font Awesome to work, such as utilizing
<div>or<p>tags instead of<i>tags. In some testing this seems to have worked but we cannot guarantee it as a workaround because as stated Font Awesome is not really supported in help center.That said, there is a community post here which might help: https://support.zendesk.com/hc/en-us/community/posts/203458726-Help-Center-Adding-icons-into-your-theme
Wes also suggested another solution not using font awesome icons here: https://support.zendesk.com/hc/en-us/community/posts/211589848-Adding-category-images-to-the-Copenhagen-Theme
Hello Zendesk team,
New to Zendesk so bear with me. I'm trying to edit the source code of a particular article (specifically, I am trying to wrap a <p> element within <a> elements to make the entire piece clickable - which is pretty common), but the changes I make are getting stripped out. I assumed it has something to do with TinyMCE, but is there a way to prevent this? Is it only stripping in the preview and it will save in production?
Any help would be appreciated.
Thanks!
Hey Zachary!
Just to clarify, do you have unsafe HTML enabled in your Help Center?
I'm going to check with some of our Community Moderations to have them take a look for you.
I do, yes. I'm also only using <p> and <a> elements, which are listed as safe.
I'm trying to change this:
To this:
But each time I make the changes, the <a> elements are stripped out, which leaves just this:
Am I doing something wrong?
Hey Zachary!
Yeah, I don't have any insights to share on this. I'll ping the Moderators again to see if they can help!
Hi Zachary,
This isn't really my area of expertise, but it looks to me like the <p> inside <a> element is not always allowed and some browsers are not handling it well, even when it is allowed.
I'm just guessing, but maybe the editor is stripping it to prevent unwanted rendering.
Is there a reason why you don't simply mark the entire content and use the editor to hyperlink everything?
Hope I'm being helpful, otherwise just tell me off...
I also have a problem with the article editor stripping an <a> element. I have an article that contains a link to a form, and I need it to be a clickable image with no text. I put the code below into the article (the <a> is inside a <div>):
When I saved the article and then opened it again, the <a> element was gone. I figured out that the <a> isn't removed if it has text, so my workaround is that I put the following code in the article, and use jquery to remove text from any element with the remove-text class:
This is very strange behavior, that the article editor removes any <a> element that doesn't have text.
Hey Karen,
It looks like this is actually expected behavior as mentioned in this article. The 3rd party article editor (TinyMCE) the Help Center uses may strip some safe tags from the HTML. This will include the <a> tag as you're experiencing on your end.
Cheers!
Hi Brett, what seems strange to me is that the article editor strips the <a> element if it contains no text, but doesn't strip it if it contains text. This seems more like a bug than expected behavior.
Hey Karen,
I did some additional digging and it looks like in general if there's an empty tag it's removed. In this case your <a> tag is empty so TinyMCE removes it from the article editor. This external article on Stack Overflow mentions this as well: how to prevent tinymce from stripping empty tags from input?.
Hope this information helps!
Hi Brett, thanks for the Stack Overflow article. I used the suggested solution of putting in the <a> element, and then the article editor didn't strip the <a> element. Using the nbsp; is a much better workaround than putting in text that I had to remove with jquery.
Glad to hear it Karen :)
That definitely seems like a much easier solution.
Thanks for posting here for visibility!
A small addendum to this: when I hovered over the link, the   appeared as a dash:
So I had to use CSS with font-size: 0px to hide it. I couldn't use visibility or opacity to hide it, as that also affected the image that is displayed in the link.
Thanks again for sharing Karen :)
Any idea how to make my table bigger while I am viewing it and not while I am editing it? I've set my table width to 1000 but when I go to view it as normal user, the table is still small.
This is in the editor
And this is in normal view
I understand that maybe this is happening because in the right side of the page there is the "recently viewed articles" area and maybe it prevents the table to become bigger. I am definitely not an html expert, so any advice would be appreciated.
Thank you!
Hey Chris,
This looks like a CSS issue, but its really hard to figure out what needs adjusting without being able to see a live version of the page. Do you have a link to the help centre with this kind of issue on display?
Thanks!
Thanks Dan! As a solution I removed the table and I put the images below the paragraphs. This solved the problem for now.
Chris
What is the use-case for this malicious code getting into the Help Center? Is ZD mainly concerned about user comments or is there another avenue I'm missing? If the comments are turned off and permissions set to not allow anyone but admins edit articles, how is malicious code getting in? Via the admin users?
Yes, afaik it's aimed at agents managing the articles, accidently adding HTML that you don't want to be customer facing. For instance iframes from third parties that would track the user.
Makes sense. We have a small team of trustworthy admins, so I'm not worried about us. But in a large organization where folks might not know what the best practices are, this could be potentially bad. Thanks for the feedback.
Please sign in to leave a comment.