Bugs

If you generate a multi-article PDF from Portal > Content Tools > Import & Export > Export to PDF, all links among the articles within the PDF do not work. For example, if articles A and B are included in the PDF, and there is a link from article A to article B, that link from article A will not work in the PDF. This results in a bad user experience, and makes it seem like the PDF is totally broken and we don't know how to do our job as technical communicators. The problem seems to be that your PDF rendering process does not recognize inline links to other articles as belonging to the PDF itself. Instead, you are coding the link as a relative URL to a website. (See attached screenshot.) User expectations: If two articles are in the same PDF, and those articles link to each other, the links should work in the PDF itself too. Alternatively, do NOT render inter-article links to look like links. (That said, it would be best to render them as links AND make the links work.)

The export to PDF feature is not usable because it does not create a self-contained PDF file. The hyperlinks in the PDF file should open topics within the PDF file and not redirect to the KB. If we wanted to direct users to the KB we would not use the export to PDF feature.

Even though the title shows correctly in the source article, when I display it in an additional place the title shows in source language

The very first name that you set, does not change, when you change the page name. That is the meta-title does not change, and does not get updated if you change the page title. Also a problem if you create a page from a template . OR if you start with a temporary name. This is a recent change

Though the message says all articles are selected but only the articles in the first page is being selected and the remaining don't.

We had an internal accessibility review on our Document360 site and received the following comment: 'HTML id attributes need to be unique to the page. It looks like the dropdowns at the top of the page uses an id attribute multiple times.' I don't think we have any control over this, so is this something that can be fixed?

Suppose I have an article heading (e.g., h2). I link to it via the drop-down menu in the Link dialog box (Heading Three) Problem: If at some future point, I rename the article heading (say, to Heading Three - Test), the link breaks b/c it's not updated to reflect the revised heading name. This issue discourages us from leveraging this feature. Thank you for your attention.

This makes it impossible to mark bits of code in the text

With a bulk import of Readers the default "Document Scope" should be "None" and not "Project", otherwise the Reader Group's Document Scope will be overwritten. Thus, although all Readers were imported in bulk, one then still needs to edit each individual Reader to set the "Document Scope" to "None". As an alternative see https://feedback.document360.com/feature-request/p/reader-import-template-additional-fields-needed-reader-group-document-scope

It's impossible to rely on this one to check quickly if a document was written in Markdown or not. I click on the same document and sometimes it shows "View Markdown" and sometimes it does not, so I have to open it in Edit mode to get the truth.