Configurable ToC Heading Levels

[TimoKruth]

@NGPixel as you wrote

I would consider accepting this PR for 2.x as the next version still require more time. I would however want some UI changes as to not rely on 10 radio boxes, which is a bit too busy. A range slider would be more appropriate, example in 3.0:

Also, the behavior should be more in line with how 3.x will work, with a min and max value:

• min: The minimum heading that will be shown. A value of 2 would ignore h1 nodes but still show their children (if any).
• max: The maximum heading that will be expanded. Lower headers are still accessible but collapsed by default.

These changes shouldn't require much work but it would make the transition to 3.x much easier.

I added a range slider as config choice for ToC heading selection. Please review and give your opinion.
Yeah and I have no idea how to put this in the original PR. Sorry for that.

Maybe we should make the collapse Level a dropdown menu?

The look of my work:
Page option:

Admin option

[TimoKruth]

@NGPixel Any Feedback on this?

[NGPixel]

Thanks for this PR!

Some points to address:

• Global shouldn't be part of the slider. It should be a toggle above or the left of the slider that enables / disables it.

• What is the Collapse Heading Level for? It should be removed completely as it's already be handled by the slider above it.

Slider Range Values:

• Left value = Level to start displaying headers from.
• Right value = The lowest level to show headers expanded. (a value of h3 means that h4 and lower are collapsed by default)

Here's a quick mockup of what it should look like:

When Use Site Defaults is enabled (default):

When Use Site Defaults is disabled:

[TimoKruth]

@NGPixel
Do you mean like the following?

Setting in Editor:

View of ToC and Site:

I will add the Use Site Default Toggle.

[TimoKruth]

@NGPixel Toggle Switch is now implemented and working as I would expect it. Please feel free to check that for yourself.
Following the relevant Screenshots:

Admin Theme Setting:

Page Editor (once using site default once not):

Page using Site Default:

Page using Page Setting:

[NGPixel]

In your screenshots, everything looks great, with the exception of the collapse defaults. If the right end of the slider is set to H2, then H2 should be visible but any children (H3, H4, H5 and H6) should be collapsed and not visible by default (they can still be expanded by the user though).

[TimoKruth]

Then everything is as you expect it. The upper one is expanded by hand to show how it works. The arrows are blue instead of black after clicking on it and show upwards instead of downwards. The lower part of the ToC is the normal not clicked version. That's why I added two of them, to be able to showcase both at the same time.
Hope this clarifies things. If not let me know :)

[FlorinBuffet]

@NGPixel Why is this only in the feat-toc branch? Because nowadays this one is much behind the main branch. Could this also be pushed to the main branch?

[ghost]

@FlorinBuffet, agreed. Why was this merged into a 'stale' branch?
This request has been floating around since 2020 in various forms.
Is there any way to get this into the main branch?

[NGPixel]

@cyr0nk0r Because it's not ready for production use. It has many display bugs that need to be resolved first.

[ghost]

perfect is the enemy of good. I think the people that want this (myself included) would rather deal with a few display bugs and have something for the last 18 months than nothing at all. It's going to get revamped and be fixed anyway in 3.0.
So why not?

[TimoKruth]

Hej @NGPixel if you have a short mention of the display bugs that need to be resolved I could try that and make a new MR if that helps anything

[pez252]

Hi @NGPixel is there any update on this? It looks like @TimoKruth is interested in helping to resolve any display bugs. This feature would be quite helpful for my use case.

[NavarroR1]

Why is this feature taking so long to get implemented? Original request was feedback in May-2020. It has been about 5 years since it was requested.

I could use this feature as well. Can someone please list the outstanding work that needs to get done? I'd be glad to help if I can.

[TimoKruth]

@NavarroR1 I would unfortunately say this is one of those cases where a single person maintains an open source project that quite a few people are depending on and the maintainer has quite a hefty workload already with this project. Including the complete revamp in version 3.
@NGPixel
May I suggest two options?

1. maybe add a maintainer if someone wants to implement something on the old version so you can focus on version 3
2. should we consider version 2 as EOL and I create a fork and try to merge open requests if possible?
3. Suggest any other solution that would help you. We try to be here for you as much as your work is here for us

I am looking forward to your response

[nasiralamreeki]

NGL, I was an early supporter and donated a small amount but ultimately had to abandon WikiJS because the progress has been glacial. I get that it's a single maintainer, but make contributing easier and let others help.

Focus more on v3 and stop maintaining the old version. This project has such promise; don't let time win.