Category: Auto TOC

15.x regression: autotoc non-optionally wastes vertical space below the box

See it reproduced here:
https://dev.tiki.org/History

{img fileId="1042" thumb="box"}

---

To me, the first fix would be to make this change between tiki12 and tiki15 (whnever it happened) optional.

In 18.x (and probably earlier) you can print the table of contents on the fly in the pdf produced by mpdf (at pdf generation time), regardless of using hardcoded maketoc calls, o hardcoded title calls with wiki argument variable -+{ { page } }+- (no space intended between angle brackets).

^ Preference: Control Panels > Print > mPDF > __Table of contents__ ^

This feature is nice, but if would deserve another minor level of integration, for those cases in which:
# the Wiki page title is hidden by default, and placed by hand in the wiki page where needed (or replaced by human-(more-)readable text), usually at the top with a heading 1 level style.
** current behavior: mpdf places the table of contents at the top, and page title is shown below the table of contents, which is counter intuitive
# A wiki page has the AutoTOC setting disabled at wiki page level, and a hardcoded call to __~np~{maketoc}~/np~__ is placed below the page title (or wherever, with whichever maketoc params for the users like, such as levels="2,3", my favourite, btw).
** current behavior: mpdf keeps the table of contents produced by itself, plus the table of contents that was previously generated in the rendered html page by the wiki markup). therefore, 2 table of contents are shown, which is not what most users would expect.

Potential solution to both issues: (2 birdies in one shot)
__Allow replacing hardcoded call to maketoc in page with the one produced by mpdf__

How? Brainstorm mode on:
* add a new param -+inpdf+- in maketoc plugin, with several values:
** __replace__: -+~np~{maketoc inpdf=replace}~/np~+- Replace that maketoc call in the wiki textarea with the output of the table of contents from mpdf
** __keep__: -+~np~{maketoc inpdf=keep}~/np~+- keep same behavior as nowadays, for those edge cases in which user has custom maketoc for partial sections of the page (or whatever), which want printed also besides the full table of contents at the beginning, etc.
** __ignore__: -+~np~{maketoc inpdf=ignore}~/np~+- ignore the maketoc call when creating the pdf, so that the only maketoc is the one produced by mpdf at the beginning (for cases with wiki page created by Tiki itself, etc, so that placement of the maketoc from mpdf is the expected one, etc)

Opinions?

Auto TOC fails when using IE10, which will display

{img fileId="410"}

AutoToc:
{CODE()}http://dev.tiki.org/How+to+release#8.__Dogfood_release_policy{CODE}

MakeToc
{CODE()}http://dev.tiki.org/How+to+release#Dogfood_release_policy{CODE}

The MakeTOC URL is much better because URL doesn't change when sections change numbers

Also, the double underscore causes an issue in links

Auto Toc is misplaced and run over the content if your Tiki is right to left.

When multilingual and wiki autotoc are enabled, the table of contents box contains a label "Maintenance" (with the i18n icon) for registered users (with permission to manage translations) after each one of the links to the wiki pages in the auto-toc box.

{img fileId="408" thumb="y" rel="box[g]"}

show admin passwd: 12345

This bug is similar to {wish id=6703}, but about the FOOTNOTE plugin instead of SUP. As explained there:
{QUOTE(replyto="Chealer")}The auto-TOC implementation does not know how to deal with advanced titles. When titles contain plugin calls, since the links can't contain HTML, auto-TOC just strips HTML tags (see the declaration of ''aText'' in autoToc.js (''var aText = $.trim($this.text());''), which may or may not give a valid result.{QUOTE}

For FOOTNOTE, this causes the footnote number to be displayed raw (not in superscript), and clicking on the number brings to the section, rather than to the footnote. For example, with the following heading:
~np~! Buggy{FOOTNOTE()}For now{FOOTNOTE} heading~/np~
...the TOC entry would just display a raw "Buggy1 heading".

I believe it would be best to hide the number, as Microsoft Word 2013 does in TOC-s. Otherwise, it should be in superscript.

This bug (like #6703) is similar to its maketoc pseudo-equivalent: {wish id=4235}.

As I understand the feature Auto TOC, once enabled at a system level it automatically applies to ALL pages, but can be disabled on any individual page.

On our site, only a small minority of pages benefit from having a table of contents and we've been making use of the maketoc plugin to achieve that for many years across multiple versions of TW on those few pages as required. On our site we would need to edit several thousand pages to disable Auto TOC on a page by page basis as currently implemented..

Whilst we appreciate the maketoc plugin has its issues, we read with great concern on page Endangered Features [https://dev.tiki.org/Endangered-features] that consideration is being given to deprecate the maketoc plugin in favour of autotoc.

Before such a change is make, we would wish that a new option be added that allows Auto TOC to be enabled but by default it DISABLES the appearance of a toc on every page. Those few pages which would then benefit from a toc would be able to enable it. This would essentially reverse the current situation where it can be disabled in some pages.

Thank you

The autotoc plugin builds a table of contents based on headings in the wiki text, but it currently includes headings from the pagebottom module zone (the h3 module titles and probably any other headings there).

http://dev.tiki.org/Calendar
{img fileId="507"}

http://dev.tiki.org/BigBlueButton
{img fileId="508"}

http://dev.tiki.org/Group
{img fileId="509"}

http://dev.tiki.org/Social+Networking
{img fileId="510"}

http://dev.tiki.org/Endangered+features
{img fileId="514"}

Also:
http://dev.tiki.org/Web-based+source+code+editor
http://dev.tiki.org/Accessibility

At https://doc.tiki.org/VideoTutorial-408-Trackers%20Feature%20in%20#How_to_create_a_page_to_collect_information_for_a_tracker the links of the autotoc are not going to the relevant anchor.

Bottom content is not accessible for long autotoc.
Scroll down the following page:
https://doc.tiki.org/Tiki19?page_ref_id=5033

See https://dev.tiki.org/Git-and-SVN-combined-workflow for example

As can be seen in the screenshot below, calling the REMARKSBOX plugin adds the call's title to the page navigation.
{img fileId="849"}

This can be seen on [http://erikqvam-11905-6586.show.tikiwiki.org/tiki-index.php|a related issue's show instance].

Headings in a fade block are displayed in the table of contents even with the page properties, TOC set to off.

{img fileId="1532" thumb="box"}

Please see like http://code.google.com/p/sabredav/wiki/Migrating1_6to1_7#Composer_package_name_changed

{flash type="url" movie="display515" width="614" height="376"}

New feature, so should go to trunk

I just came across a problem with the vertical offset for targeting headings with autotoc. That is, a problem caused by this code:
{CODE()}
h1:target::before, h2:target::before, h3:target::before, h4:target::before, h5:target::before, h6:target::before {
content: "";
display: block;
height: 83px;
margin: -83px 0 0;
}
which is inline CSS when autotoc and the sticky top navbar (in this case 83px in height) are used. In a page with some links just above a heading, the links can't be clicked because the transparent 83px-high target overlaps them from the heading below.

I tried a few tweaks to the CSS but didn't have any success. Probably at least it should be documented, that every heading or other in-page anchor targeted by a link will have a zone above it equal to the navbar offset set in L&F admin that shouldn't contain links or other HTML that needs to be clicked, etc.

after an upgrade from TikiWiki 12 to 15, entries are missing in the "autotoc" of our TW installation:

the first entries seem to be ok up to the point where there's a "REMARKSBOX" in a wiki page. after such a remarksbox, no more (sub-)headings appear in the "autotoc" list, it seems to be truncated.

on all pages without a remarksbox, the autotoc seems to be working fine.

It should stay fixed at the same position from the top edge of the viewport.
Example: https://dev.tiki.org/Endangered+features

If some level y header follows a level x header, y is normally between 1 and x+1. But Tiki also supports going straight to x+2 or greater, in general. For tables of contents, this is not a problem for server-side TOC-s (maketoc), but it is one for client-side TOC-s (autoToc). Level i headers which follow the excessively deep header are displayed as level i-1 headers. And level 1 headers are not displayed. Furthermore, headers following a missing level 1 header are also missing, no matter their level.

So, for example, if a page contains:
{CODE(colors="tiki" theme="default")}
! Title 1
!!! Title 3 (too deep)
!! Title 2
! Title 1
!! Title 2
{CODE}
... the client-side TOC would list the first title fine, the third one would be displayed as H1, and the fourth and fifth titles would not display.

This appeared with Tiki 15, when autoToc switched to Bootstrap Scrollspy. Tiki 14.4 does not have this problem. This persists in Tiki 18.1.

The defect must be in autoToc.js. The technical bug causes another symptom reported in {wish id=6586}.

Hi,

We use ' Last update from SVN (18.1svn): Thursday February 22, 2018 15:47:32 +01 - REV 65559 (InnoDB)'

'Default bootstrap theme' -- 'no customization'.

__The REMARKSBOX:__
{CODE(caption="The REMARKSBOX" colors="tiki" theme="default")}
{REMARKSBOX(type="information" title="Hva er Wiki")} ... {REMARKSBOX}{CODE}

We experience that AutoTOC is not rendered properly (some headings are missing) when a REMARKSBOX is present in the Wiki page:
{img fileId="1164" thumb="box"}

Thanks!

Erik Qvam

------

The first entries seem to be ok up to the point where there's a "REMARKSBOX" in a wiki page. after such a remarksbox, no more (sub-)headings appear in the "autotoc" list, it seems to be truncated.

This regression from Tiki 12 to Tiki 15 was first reported by cpeter in {wish id=5928}.

This does not happen if REMARKSBOX is called in a level 3 section.

Auto-TOC is now activated on dev.tiki.org

This is nicer than ~np~ {maketoc} ~/np~ and th way going forward, but now, we have hundreds of pages with duplicate Table of Contents.

# Find them all via http://dev.tiki.org/tiki-searchresults.php?highlight=maketoc&date=0&searchLang=&where=wikis&search=Go
# Remove all the maketoc instance with an edit comment "Auto-TOC is now activated"
# Check if page looks OK. If not, report issue in Auto-TOC category, so it will appear here on ((Auto-TOC))

At https://doc.tiki.org/VideoTutorial-2737-Basic%20Tiki%20Customisation
The autotoc is in the way and it have been turned off (set to on by default on the website).

It is not applied, on some screen it is breaking the page layout.

{img fileId="1293" thumb="box"}
{img fileId="1294" thumb="box"}

I have an issue where if my sub-headings exceed 9 then the auto-numbering and autoToc is screwed up.

This does not happen on first saved, rather after the next edit and save.

To replicate the issue:

1. Create new wiki page.
2. Add a H1 Heading, e.g. 'Section 1'
3. Add 10+ H2 Headings underneath the 'Section 1' Heading
4. Add another H1 heading, e.g. 'Section 2'
5. Save
6. Edit Wiki page
7. Save again

H2 Headings are OK up unitl section 1.9 and then the system seems to add an additional hard coded 1.x on to the end of the auto number.
An additional hardcoded number is added with each subsequent edit & save.

The TOC gets populated with some headings from plugins like trackerlist (probably should not as it seems to appear on wrong position at the top of the TOC).
---
affecting autotoc and standard maketoc, also in Tiki15. {sign user="xavi" datetime="2016-05-20T09:48:34+00:00"}