DiscoTOC - automatic table of contents

I believe that if a heading has accented marks or non-ascii characters, the anchor link doesn’t work. For example:

## Cómo hace un año

creates this anchor link:


but clicking doesn’t go to the correct section. To overcome this, I currently have to manually create the header:

<h2 id='heading--whatever'>Cómo hace un año</h2>

and the link:

[this works](#heading--whatever)

Hey guys

Are there any plans to make it compatible with the new Page Publishing feature


Noticed another potential problem and simple workaround. (actual post)

Sometimes the TOC on the right will be collapsed until the post is scrolled further down, then the TOC will expand correctly.

In tinkering with the post text found that if the post text is like

### Installation Instructions
### Language agnostic steps

the problem occurs

and if the post text is like this (with a blank line between section hearers)

### Installation Instructions

### Language agnostic steps

the problem does not appear.

Not expecting a fix or anything but just noting in case others run into this.

This will be an option in the next release of this component.

I think you might be referring to the way that the browser handles the URL for non-ascii characters when you copy the link. In any case. We have plans to automatically generate the ids for headings in core in the next version of Discourse. So, this component won’t have to do that once that work is done. We’ll be sure to test for this :+1:

Eventually, yes. but no immediate plans for that as of now.

I think

Language agnostic steps

here is supposed to be a subheading under

Installation Instructions

but they both have the same level.

problematic headings

So, if you have a heading - level 3 in this case - with no text under it followed by another heading on the same level, then it’s expected that you’d run into this problem.

You can either add a paragraph or two under that heading, or change the levels of the headings underneath it.


@Johani it seems like link no longer uses DiscoTOC

That preview / link still works for me

Can you please let me know what device / browser you’re using?


Sorry to bother you. It seems that a browser plugin must have stopped it from loading (umatrix). I tried on the same setup without that plugin and it worked!


Is there a way to make the component not generate extra white before the first line of text?


Hi @Ellibereth

I was able to fix it like so:

Naturally, that is a change to keep track of in case of update, but maybe someone will add it to the theme itself :slight_smile:


PRs are always accepted :wink:

Have you tried putting the discotoc code at the bottom of your post?

Rather than modify the component itself, which is dangerous as any updates will overwrite your changes, create your own component. Refine the applicable CSS. As Discourse does not officially order CSS placement on a rendered page from components, you may need to use the !important hammer to ensure your styles are applied.

PRs for UI tweaks like this I think are questionable as everyone has their own sense of spacing, sizing, etc.

How would I got about adding a label/title to the ToC. Specifically, I was hoping to just add “Contents” above the actual list. It would seem ideal to have an <li> for this rather than attempt to use something like :before.

Examples of outcome



P.S. I :heart_eyes: this component. Great job.

1 Like

Is there a way to move the TOC to the left side of the post, rather than the default right side?

1 Like

I think I found a [bug] :beetle:

Expanding a oneboxed internal link of another topic that contains TOC, makes it appear on the side of the topic where it was oneboxed (expected behavior I suppose).

When the expanded onebox is closed back though, the TOC remains on the side and leads to weird behavior.

Steps to reproduce:
  1. Create a topic with a table of contents.
  2. Create a second topic and link the first one inside it => A onebox is created.
  3. Expanding the onebox makes the TOC of the first topic appear in the second one (expected behavior I suppose)
  4. Closing the onebox does not make TOC disappear. Clicking the TOC in this case just scrolls the post down incrementally. (Not expected behaviour)
  5. BONUS: Things look even worse, when the second topic has a TOC as well.
    1. Expanding the onebox in this case does not show the original TOC
    2. Expanding and closing the onebox multiple times though, makes the TOC of second topic gradually shrink and disappear at some point. The width of the post is also affected.

The result of expanding and closing the onebox about 10 times:

1 Like

Feature request: transliteration of HTML ids

It will be nice if you can have good trasliterated urls for achors like the rest of the URL

Feature request

Discourse added the ability to automatically display the dark mode, when using TOCs on dark mode in mobile the TOC opens in white (the default non-dark mode color).

And a possible bug, when I load the TOC it loads the contents up to the visible part so the TOC doesn’t have all the information of the publication.

First view of the TOC:


View after scrolling down



I have updated the component to support dark mode automatic switching.


Thanks, you’re awesome it works perfectly.


Am I asleep, or did the ‘insert TOC’ item in the gear menu when editing disappear?