--- title: "Troubleshooting editor issues" slug: "troubleshooting-editor-issues" description: "Resolve unsupported HTML tags and formatting issues in your articles with our guide on using WYSIWYG editors effectively for consistent content display." updated: 2026-07-09T06:09:45Z published: 2026-07-09T06:09:45Z canonical: "docs.document360.com/troubleshooting-editor-issues" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.document360.com/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting editor issues Use this article to resolve common issues you may encounter while working in the Document360 editor — from sections that can't be edited and formatting that breaks after pasting, to videos that won't load. Issues are grouped into three sections: fixable problems, expected platform behaviors (known limitations), and frequently asked how-to questions. --- ## Editing issues ### Unable to edit the article section due to unsupported HTML tags This issue occurs when an article is converted from the WYSIWYG editor to the Advanced WYSIWYG editor, resulting in unsupported HTML tags. **Steps to resolve** If the issue has already occurred, review the article's code view and remove any unsupported HTML tags. These tags are typically wrapped within the `<editor360-custom-block>` tag. Removing this tag will restore editing functionality and resolve the issue. **To prevent this issue** 1. Avoid converting articles from the standard WYSIWYG editor to the Advanced WYSIWYG editor. 2. Instead, import or copy-paste content directly into the Advanced WYSIWYG editor to prevent formatting challenges. 3. If the issue has already occurred, review the article’s code view and remove any unsupported HTML tags. These tags are typically wrapped within the `<editor360-custom-block>` tag. Removing this tag will restore editing functionality and resolve the issue. --- ## Formatting and display issues ### Code block text is cut off or not displaying correctly This issue can occur when inline styling is applied directly to the code block within the article editor. Certain inline styles may affect the rendering behavior of the code block, causing the top portion of the text to appear cut off or improperly aligned on the published page. **Steps to resolve** Navigate to the code view of the specific article and remove the inline styling applied to the affected code blocks in the article editor. Once the inline styling is removed, the code block should render correctly on the knowledge base site. --- ### Normal text in the editor is displayed as a hyperlink on the live site This issue can occur when the article content contains empty `<a>` (anchor) tags or custom CSS applied to anchor elements, usually introduced while copying and pasting content from external sources. **Steps to resolve** - Remove the empty `<a>` tags from the article code view. - Remove any unnecessary custom CSS applied to anchor (`<a>`) elements. - Paste content without formatting using: - `Ctrl + Shift + V` (Windows) - `Cmd + Shift + V` (Mac) This helps prevent unwanted hyperlink formatting on the live site. --- ### Article content formatting is inconsistent Formatting inconsistencies occur when content is copied and pasted from external sources, retaining original styles that conflict with the article's default formatting. To ensure uniform formatting across your article, follow the steps below: 1. Select the entire content within the article. Select the **Clear** formatting option available in the **Format** menu to remove any inherited styles applied to the content while the article structure remains the same. 2. After clearing the formatting, manually reapply necessary styles such as headings, lists, or bold text if needed. Clearing the formatting ensures that content displays consistently in both light and dark modes on the Knowledge base site. --- ### Font color is not displayed as intended in dark mode This case usually occurs when inline CSS styles are carried over while copying content from external sources (like web pages, documents, or PDFs). These styles often override the platform's default theme, causing low contrast or invisible text in dark mode. **To prevent this** - Paste as plain text using `Ctrl + Shift + V` (Windows) or `Cmd + Shift + V` (Mac) when adding content to an article. - This removes any unwanted formatting, keeping your content readable in both light and dark modes. If you've already pasted content and are facing readability concerns, try selecting the text and removing the inline formatting using the **Clear** option in the Advanced WYSIWYG editor. --- ## Videos and embed issues ### Embedded video doesn’t load in the Editor In the editor, direct HTML player code is not supported. The player still tries to start from the HTML code, leading to network requests that stay in a pending state. To fix this problem, substitute the HTML player code with the iframe embed code. For instance, here's the Wistia HTML player code: `<wistia-player media-id=”lorem” aspect=”1.777777”></wistia-player'>` If you insert the HTML code, the video will not play. You need to utilize the iframe code that is supported: `<iframe src=”https://fast.wistia.net/embed/iframe/loremipsumloremipsum”> </iframe>` --- ### Some Wistia embed codes are not working in the editor Document360 supports video embedding primarily through supported HTML tags such as `<iframe>` and `<embed>` within the Advanced WYSIWYG editor. Some Wistia embed models, especially the **Popover** and **Legacy** embed types, include unsupported `<script>` and custom HTML tags. These unsupported tags are automatically sanitized by the editor for security and stability reasons. Because of this: - The embed may not get inserted properly - The editor may appear blank or unresponsive - Slowness or freezing can occur when unsupported code is added through code view **Recommended approach** We recommend using the **Wistia Inline embed format** with supported `<iframe>` embeds to ensure: --- ## Known limitations The behaviors in this section are by design. Where available, workarounds are included. ### Tab spacing is not supported within list items Tab spacing is not supported within list items, so pressing the `Tab` key will not insert a tab character when the cursor is positioned inside a list item. --- ### Bold and italic formatting is not retained after Word import When importing Word documents, bold and italic formatting may not be preserved if the formatting is applied through Word character or paragraph styles (for example, **Strong**, *Emphasis*, or *Caption* styles) rather than using the inline formatting options available in the Word editor toolbar. This behavior is a known limitation of the current Word import implementation, which is based on Mammoth. The implementation includes a custom style mapping only for underline formatting and relies on Mammoth's default conversion behavior for other text styles. Mammoth's default processing converts formatting applied through inline run properties but does not convert formatting inherited through style references. As a result, bold and italic formatting defined via Word styles may not be reflected after import. --- ### Checklist items cannot be checked by readers on the Knowledge base site Checklist blocks created in the **Advanced WYSIWYG editor** are displayed as read-only on the **Knowledge base site** by design. Readers can check or uncheck checklist items only while editing the article inside the **Knowledge base portal**. If your use case requires temporary interaction on the live site, such as SOP walkthroughs or process validation, you can use **Custom CSS and JavaScript** to make the checklist checkboxes clickable. Example: ```css #articleContent ul[data-type=taskList] li[data-checked] > label { pointer-events: auto; } ``` > [!NOTE] > NOTE > > Any checklist state changed using this workaround is temporary and resets when the page is refreshed. --- ### Text enclosed in angle brackets (< >) disappears from article titles after saving This is an expected platform behavior. Any content enclosed within angle brackets (< >) is automatically removed from article title fields. This restriction is in place as a security measure to prevent unintended HTML injection, which could affect the rendering and integrity of your Knowledge Base site. For example, if you enter
If you forget your password, click Forgot Password on the login page. Enter your registered email, and you’ll receive a password reset link.
For better security, choose a password with at least 8 characters, including numbers and special symbols.