Help Center Article Editor needs to support (easy) source code formatting

👋very much in favour of an improved code sample experience!

4 years later, this remains a significant pain point.

Adding my vote for this to be implemented. We are putting together developer documentation and being able to add code blocks would be a really great addition.

I've done some slight digging around and found this article: http://web.simmons.edu/~grabiner/comm244/weekfour/code-test.html

If you remove the <code> bit, and only keep the <pre> looks like it works?

Unless you guys are looking for something else?

Code I used for this is:

<pre> 
 p { color: red; }
 body { background-color: #eee; }
</pre>

I confirm it works, but you have to do manual Source code edit, and there can't be a <span> tag included.

It also don't show in the editor.

+1 as an organisation which supports users who code, the lack of simple editor (TinyMCE) options like this is deeply frustrating for those team members authoring articles and supporting users, and for the users who are receiving lower quality support.

+2 this relates to our ability to have a consistent set of styles when editing/previewing, as compared to being published. If we could add code formatting and other enhancements within our custom theme, problem solved. However our custom theme doesn't apply to the editor/preview, so we're back to square one. see: https://support.zendesk.com/hc/en-us/community/posts/115006874967-Automatically-Adding-Colored-Notes-in-Articles-Based-on-Article-Keyword and https://support.zendesk.com/hc/en-us/articles/227537227-Why-is-an-article-s-appearance-different-in-the-editor-than-in-Help-Center-

It's been 4 and a half years since this thread started on implementing a simple html WYSIWYG editor in the help center.  It's obvious that it's not going to happen.  Implementing something like TinyMCE isn't exactly rocket science: https://www.tiny.cloud/docs/get-started/first-steps/  and shouldn't be a big undertaking.  

Zendesk uses a modified version of TinyMCE. They CHOSE to strip out functionality. Right on Tiny's homepage...

Hey all,

It's not quite as simple as what parts of TinyMCE we do and don't strip out. From our perspective, what we allow into an article via the Article Editor has to be compatible with a number of different publishing destinations. For example, if you create an article with a red text that has to be rendered properly in our Article Editor, Help Center article templates (with CSS styling), the legacy Mobile layout of a our Help Center, the Knowledge Capture Application, the Mobile SDK that customers integrate with, the Web Widget and for customers that consume article content via the Article API. Supporting all these channels as output sources for an article makes our platform useable in many different contexts, which is great. However it increases the burden of building out new features for the Editor. So yes, TinyMCE has code block support. But that doesn't mean that we can "just turn it on" for our Editor.

That being said, there are a number of things that customers are asking for that we don't provide that we should add to the editor. It's a process of refinement and prioritization. I can assure that I read all of your feedback. We are working on set of competitive research and user testing around source code formatting right now. I'm hoping we have some settled findings by early August. From there it will be about working out timing for implementation. I can't give you a timeline at this point, but it is something we're actively looking at.

Thanks!

thanks Ryan, useful to understand.

I do wonder whether, like with theming, the overall compatibility across channels couldn't be left to the customer? If it were an option to configure some editor features, or at least to use our own theme custom CSS within the editor, that would, that would be transfer a similar level of responsibility to what we do today as a customer when customising our theme in general. For some customers who only use one or two of the channels you describer, that would represent a major change in what was possible... 

thanks again for your response.

Hey Nick,

Thanks for the response and the feedback. The equivalent in the article editor is to enable the setting for unsafe HTML and use the source code editor or API. For example, you can embed GitHub gists or PDFs using the Google Document Viewer. Examples of that here and here. Both of these are then totally broken if we look at them in the Knowledge Capture app for example. Our trick is that if we add anything to the editor as something we support out of the box, we've gotta support it on all of our channels.

Thanks!

Hey Ryan,

Sorry to report but neither of the links you just sent are working. One gives a 404 and the other requires authorization to Z3N.

Sorry about that Chaz. It's in my test account and I'm always changing around permissions. Try again, the links should work now.

Thanks!

This is a blocker for me to be able to role out fuller use of the guide.   How is it that this has not been implemented?   Please prioritize this.

Thanks for that feedback, Jason. 

This is a blocker for me as well.

I have narrowed down to Zendesk for our service desk and knowledge base requirements in a lengthy process and this basic requirement is probably the main reason why we simply cannot go ahead.

Our product requires technical integration documentation and code snippets are bock standard in any half-decent editor. Even Freshdesk has a fantastic code block in their editor...

The lack of decent code block options is a major disappointment for my team as well. We need to be able to share code snippets to our advanced users, and more frequently in our internal guides. 

Messing around with the source code editor has been very difficult with no line numbering, tabbing, etc. I try to stay out of there whenever possible. But for now, I'll just need to settle for using <pre> I think. 

My company spoke to a ZenDesk representative on the phone recently and discussed this issue among others.

ZenDesk make it clear that code block support in the Help Center / Guide is not on their roadmap anytime soon, nor is allowing customers submitting tickets to use markdown for code blocks.

Their best alternative was to write our own editor that uses Markdown, formats it to HTML and then posts that to the Guide over their API.  Thanks but no thanks.

We're a developer-targeting tech company, so swapping code blocks with customers is easily a third of what our support team does.  This is very disappointing news and renders the Help Center basically useless for us indefinitely. :-(

Customers ask how they can implement images and code snippets in their replies, just as we agents can. I'm sorry to have to tell them they can't, and it's not up to me.

Hey all,

Today we've rolled out an ability to insert code blocks as pre-formatted text in the article editor. It's a small change and doesn't include syntax highlighting, but will hopefully will make it a little easier to insert code into your articles.

We will continue to take more advanced functionality as a product feedback.

Thanks!

@Ryan, Thanks, code block support is good news, but the implementation seems unfortunate to me. Can you explain why the decision was made to use </br> inside the <pre> block  rather than the MUCH more readable inclusion of EOL characters in the HTML code? Does this help with multi-browser support?

Hey @Jonathan,

I'll need to take a look at this as I don't believe that's the intention necessarily. Let me talk to the engineering team and I'll get back to you.

Thanks!

Adding my two cents here: 

1. Paste your code as plain text into a Google Doc. 
2. Use Code Blocks add-on to do the syntax highlighting.
3. Import the Google Doc into Zendesk using the import tool.
4. Copy the code into an article. 

Advantage: The code is both highlighted and can be copied and pasted. 
Disadvantage: Time, of course. But you can import in batches or you can have plenty of snippets in a single Google doc and then just distribute snippets in your articles. Also, at least basic HTML knowledge is needed, the import tool is now that seamless. 

Cheers!

@Ryan, any update on my question above (2018-09-13)?

AFAICT there has been no change in the implementation.

Thanks!

Hey Jonathan,

We've determined that this can vary depending on the text editor/browser you're copying from. Can you let us know the text editor you're using, the code you're attempting to copy and what actually gets inserted? That'll help us to debug this better.

Thanks!

I've managed to make https://highlightjs.org/ work for me with some custom setup.

It has kind of a conflict with a standard zendesk script which makes it not possible to use dark themes, but still a decent solution.

Here is the result:

To use it you should:

1. Add links to the css and the script to your document_head.hbs

<link rel="stylesheet"
href="//cdn.jsdelivr.net/gh/highlightjs/cdn-release@9.13.1/build/styles/atom-one-light.min.css">
<script src="//cdn.jsdelivr.net/gh/highlightjs/cdn-release@9.13.1/build/highlight.min.js"></script>

*Take different version/style from here https://highlightjs.org/download/ if you need

2. Add a script which will proccess all the 'pre' blocks to the script.js

$('pre').each(function(i, block) {
hljs.highlightBlock(block);
});

3. After it all your code snippets (like: <pre> Some code </pre>) will look much better.

If I will manage to disable the standard script it will make everything much easier, but unfortunately, I can't spend more time on it right now...

Hey Michael,

Thanks for putting that demo together. What do you mean by "disable the standard script"? If you'd like to use it without using jQuery, you can add the following to script.js outside of the $(document).ready(function() { ... }); section

window.onload = function() {
 var snippets = document.getElementsByTagName("pre");
 for (let snippet of snippets) {
 hljs.highlightBlock(snippet);
 }
}

Thank you, Ryan.

'Standard script' - I meant something which handles all the <pre> tags in an article and adds the area with border and grey background. It works after the custom script I've applied. And when my script makes the background dark, the default script after it makes it grey which is not good if I want to use a dark style with white font colour for the code snippets.

Zendesk should really update the TinyMCE WYSIWYG editor and/or add the many useful editing tools that have been available for this WYSIWYG editor for many years.If you want I will be glad to write another comment with ALL the popular WYSIWYG tools that we are not getting that we should have. Quickest way to see you own favorites that your not getting is to go here: https://www.tiny.cloud/features

The TinyMCE WYSWYG editor natively supports creating custom styles like the one Zendesk uses for Notes (I worked for an enterprise CMS company that also uses TinyMCE, so I know what is possible).

If the whole "has to be compatible with a number of different publishing destinations" then how about bringing the WYSIWYG article editor that Zendesk uses for it's OWN Guide articles for the rest of us to use in our articles!

For example: Article Notes... You can't do this now, but Zendesk can for their guide.

Zendesk article Notes are comprised of:

<div class="p">

<div class="note note">

<div class="notetitle">Title</div>

Note body text.

</div></div>

If you try to add these tags, they get removed, If you try to add <style> tags in the source of the article, they get removed when you publish the article.

Why can't we have the WYSIWYG tool that assigns these tags and styles to our content in articles. I am sure I can find more like this. We should have access to the same Guide article editor that Zendesk uses itself!  see image:

One of the selling points for me, or rather what I saw in Zendesk's support articles when making the buying decision was the broad variety of styling that was possible. It was not cool when I then later found out that these are not possible in the WYSIWYG editor we get for Guide articles.

Having to re-define the CSS of a text color in the tool bar to get the example above is a real hack (as found in another community post: https://support.zendesk.com/hc/en-us/community/posts/205335977-Add-Note-and-Warning-boxes-to-your-Guide-articles ), and we should not have to reinvent what is already there (just turned off).

Hear, hear!

One editor to rule them all! (Tickets, articles, community...)