Feature Request

I do NOT like not seeing the slug that is used when I make an XREF. The new advanced editor Link editor only shows the article title when you select the article to be linked. I want to see the SLUG as well as the title. I also want to be able to manually enter or edit the slug. Sometimes I create a link to an article that has not yet been created, or I know the slug will change soon. The old editor let you do that because it let you edit the slug in the link. The new link editor doesn't allow that. Another problem: this has always been a problem but now it's worse: When linking to a HEADING on the same page, the link editor has always added the slug and then the anchor ID. This is very annoying because it means when the user clicks on the link on the published page, THE WHOLE PAGE REFRESHES instead of just jumping to the heading. I have always worked around this by NOT USING the "link to a heading" feature. I simply manually add the anchor ID in the link box. BUT NOW I CAN'T DO THAT because I don't have access to the slug when making a link. I know of a workaround: I click the tab to add an EXTERNAL link and then add the anchor ID in the URL field. This works for now, but is it just a matter of time before you take that away too? At a higher level I find it annoying that so many features keep changing in ways that are supposed to make tasks "easier" but in reality they only make it easier for people who don't know what they're doing. For people with experience working on web-based documents, we find this "dumbing down" of the features to be very annoying. This removal of the slug field in the link editor is a perfect example of this.

It would be nice to have the possibility to add links to files that are stored in the Drive directly from the article page (currently you need to go first to the Drive, identify the document to link, copy the link address and paste it in the article)

I have several related updates I'd like to see within Drive for better usability and management: View items in a list instead of a grid. We have a naming convention that makes it easier to find images than looking at the small thumbnail. However, we can only see part of the name in the current UI grid setup. View a larger version of image. Currently only thumbnail-size available, even when viewing the file details. Makes it hard to see what the image is to determine if I want to use it or replace it. When searching for images and files within Drive, the file's parent folder isn't listed, so I have no idea where it's living. Often, I want to go to the parent folder to view what else it has related to the image I just searched. When updating and adding images in articles, I want to be able to click on an image to - See it's name - See the Drive folder it lives in - Go to the file in Drive so I can replace the file Rename files in Drive - Occasionally there's a typo in a file name or it doesn't follow the proper naming convention, so I'd like the ability to update the file name in Drive. Often, a file has several dependencies so it's not a viable solution to just upload the same image with the corrected file name and replace it in the many places it's used. -- Each image seems to have it's own unique identifier string, so renaming images shouldn't break links, references, or dependencies. The Drive pop up window to insert a file from the article editor is always taller than my browser window, so I have to scroll down to click the Insert button once I've selected an image. The pop up window should be smaller than my browser window height.

A customer found the Recycle Bin icon (trash can) unclear, as it typically signifies "delete" rather than a place to view deleted items. They suggested replacing the icon with a clear "Recycle Bin" label or adding a visible tooltip to improve discoverability. This would make navigation more intuitive and align with common design practices.

It would be very helpful to be able to customize the sections on the home page based on whether the viewer is logged in or not. The "Knowledge Base Categories" section is great because it will only show the public categories if the user is not logged in; however, the "Widgets" section is problematic because it will show articles regardless of whether the user is able to access them, resulting in frustration if they attempt to click these links. One simple solution would be to have the ability to make entire sections only visible to logged in users (or to certain reader groups), similar to how we currently set the security settings for individual categories and articles. This would allow us to streamline the Home Page experience for public viewers while also including more detailed information for logged-in users.

In 2.0, the Copy link feature is not currently configurable, while the feature is good for users who frequently share article links. For certain use cases, the link feature is not required, having the option to disable it would be good.

Enable auto-collapse of the category and article list on the left panel when table content is wide, to improve readability and reduce horizontal scrolling.

Instead of having to go through existing table and changing them to be this setting, why not make this the default so that PDFs don't get screwed up.

The animation that happens when a widget is opened or closed makes it appear that it's coming from a button in the lower right. This is problematic when using a custom button that isn't in the lower right. For example, the button we use is in the upper right so it's confusing when it looks like it comes from a non-existent button in the lower right. Ideally, the animation should make it look like it comes from wherever the trigger is or it should be customizable.

I love the broken link list, but am really struggling to tell which link is broken when viewing the specified page in the WYSIWYG editor. Please make it possible to highlight broken link in WYSIWYG view.