ID(s) of html elements are changed automatically by the editor
complete
Ivanna Parra
This seems to be happening in both editors and in different scenarios:
- When we use the html editor (in the old editor) and create an html element and set id on it e.g. <h1 id=test>Test</h1> then close the editor and reopen it, the html element will be changed to <h1 id=test-1>Test</h1>
- When you publish an article using the new editor, all custom HTML id tags are removed. This also happens when we switch from the Source code to the text editor. It seems this feature is not supported in the new editor.
- Index numbers are automatically added to the TOC link ID's. The indexnumbers change when you add or remove TOC items completely messes up all external referrals to the chapter.
Aziz Mejri
complete
Custom IDs will no longer be removed, however, the auto generated IDs will stay, even if removed, as we need to use them for our other features.
Patrick Morgan
Aziz Mejri Thanks! Just so I get this right, is this what I should expect that when I add a new header into an article?
- HJ will create an id for the header automatically, as before.
- If I choose to update this id, the update will be maintained when I publish—and no changes will be made to any of the existing ids (auto-generated or custom) on any of the other headers in the article.
- If I delete an id, and do not add a custom id in its place, HJ will still add an id automatically when the article is published.
Did I get that all correct?
Aziz Mejri
Hey Patrick Morgan!
HJ Will create a unique ID for each header, if you edit the element with a custom ID
only
, we will add our unique ID alongside the custom one, if you completely remove the ID, we will regenerate it with our custom ID only.In essence, we will always have our unique ID, as we need them for our other features like the ToC.
There's also a safeguard to prevent custom IDs from using the ones we create, to prevent duplicate IDs, if we find one, we remove it.
Patrick Morgan
Aziz Mejri I'm pretty puzzled here. I can't imagine this is behaving the way it was intended.
I have tested this out, and currently:
- Automatically generated IDs now have a leading space. This prevents it from being used as an anchor.
- If i make any changes, HJ appendsan ID, delimited by a space. This also breaks anchoring behavior.
If this works for your TOC functionality, I can only assume you're doing this with some js script reading the ID string and not with default browser anchor behavior.
I don't want to use the pre-built TOC functionality—I've built my own, and for business purposes we MUST be able to link consistently to basic html anchors that do not change over time. Otherwise, how can I maintain a consistent URL+anchor location in our documentation that I can share with users? If I want to send a user to a specific FAQ in a page from a link with an anchor in our product, I can't be sure the anchor link will be broken the next time I make and edit anywhere in the relevant article.
Patrick Morgan
This behavior is extremely concerning for my organization. We make heavy use of linking to anchors, especially in FAQ articles with many accordions. It rarely makes sense to simply append another FAQ to the bottom of a page, thereby preserving the existing ID links on the page—more often than not, an FAQ will be inserted where it makes most sense from a topical standpoint, which then breaks links to all the other FAQs down the page.
This is the most common example of how editor changes might break links, but as a SaaS company, we also make constant, iterative changes to our products, so we make constant, iterative changes to our documentation—frequently adding to and restructuring our feature articles. Doing so will break links to existing anchors.