HEUREKA! Wie lange schon geht mir auf die Nerven, dass WordPress keine Inhaltsverzeichnisse unterstützt. Die Suche nach “table of content” in der Plugin-Seite fördert nur wenig zu Tage, ganz selten ist eines der gefundenen Plugins überhaupt mit WP 3+ kompatibel, gefallen hat mir keines. Ziel ist doch nur, aus den Überschriften der verschiedenen Level eines Artikels ein popeliges Inhaltsverzeichnis zu erzeugen.

Nun ja, nachdem dem Inschenör nichts zu schwör ist, wird ab heute selbst Hand angelegt. Die Grundlage bildete das noch am ehesten brauchbare Plugin “TinyTOC“, welches aber auch eigene Tags erwartet, um Überschriften zu erkennen.

Nachdem ich gerne die Qualitätsmarke “made-in-Germany” auf eigene Entwicklungen stempele, ist’s nicht genug, ein Inhaltsverzeichnis zu erzeugen, sondern auch mit einer uralten HTML-Schwäche zu brechen – den Kapitelnummern. Warum können verschachtelte Heading-Tags nicht entsprechend (1., 1.1., 1.1.2, etc.) ausgegeben werden?! Es ist selbst mit CSS nicht möglich, entsprechende Funktionalität zu implementieren.

Zeit wird’s für ein Redesign.

Beschreibung

Das Plugin kann im Wesentlichen die folgenden zwei Aufgaben übernehmen.

Erweiterung von Überschriften um Kapitelnummern

Das Plugin scannt den gesamten Text eines Posts, egal ob in Seite aufgeteilt (“paginated”) oder nicht, und extrahiert die Überschriften aus den h1-h6 HTML-Tags. Sofern der Autor die Verschachtelung korrekt durchgeführt hat, sprich alle Ebenen sind aufsteigend hintereinander angeordnet (1. -> 1.1. -> 1.1.1., nicht 1. -> 1.1.1.), erstellt das Plugin korrekte intern Einträge.

Aus diesen erzeugt es quasi-eindeutige, zumindest aber statische ID-Attribute und weist sie den jeweiligen h*-Tags auf der aktuellen Seite (“Page”) zu. Dies geschieht unabhängig von den Gliederungsebenen, jede Überschrift erhält eine eigene ID.

Danach werden optional aus den Einstellungen im Admin-Interface und den jeweiligen Gliederungsebenen Kapitelnummern erzeugt (z.B. I., I.1, I.2, II., II.1., etc.) und diese dem Text der Überschrift vorangestellt.

Es lassen sich dafür drei Dinge einstellen:

1. Die Tiefe der Nummerierung von Level 1 – Level 9.
2. Der Nummernstil der Ebene:
   • nicht nummerieren
   • Arabische Ziffern: 1, 2, 3, …
   • Römisch Klein: i, ii, iii, iv, …
   • Römisch Groß: I, II, III, IV, …
   • Alphabetisch Klein: a, b, c, …
   • Alphabetisch Groß: A, B, C, …
3. Ein abschließendes Zeichen der Ebene:
   • keines
   • immer den Punkt (1., 2.)
   • Punkt, wenn nicht letzte Ebene (1, 1.1, 1.1.1, etc.)
   • immer Klammer (1),2),3))
   • Klammer, wenn nicht letzte Ebene (1, 1)1, 1)1)1, etc.)

Das sollte eine maximale Flexibilität für die meisten Einsatzzwecke geben.

Erzeugen des Inhaltsverzeichnisses

Wenn gewünscht, erzeugt das Plugin auch ein Inhaltsverzeichnis. Nahezu unabhängig von der Nummerierung von oben können auch hier ein paar Einstellungen vorgenommen werden:

• Kapiteltiefe: Bis zu welchem Level soll der TOC aufgebaut werden.
• Soll es eine flache Liste werden, eine aus <ul>-Elementen erzeugte, oder sollen die Kapitelnummern von oben übernommen werden (dann ist TOC-Tiefe auf die Nummerierungstiefe von oben begrenzt!).

Da die <ul>-Tags und die Nummerierungselemente flach untereinander liegen und nicht verschachtelt sind, erhalten die einzelnen Ebenen jeweils eine oder mehrere CSS-Klassen:

• tinytoc_level_n: Selbsterklärend, in welchem Level befindet das <li>- oder <div>-Element.
• current_page: Ist das Ziel des Links auf der aktuellen Seite zu finden?
• fiurst_in_block: Wenn ein neuer Level-Block aufgemacht wird (z.B. von 1. -> 1.1.), erhält das erste Element im neuen Block diese Klasse.
• last_in_block: Wenn Level-Block beendet wird (z.B. von 1.1. -> 2.), erhält das letzte Element im Block diese Klasse.

Damit kann das Verzeichnis beliebig gestyled und angeordnet werden.

Fazit

Das Stück Software ist weit davon entfernt, sauber oder schön programmiert zu sein, oder fertig. Ich habe im Moment nur leider gar keine Zeit zum weiterentwickeln und habe nur einen 2 Tage-Hack gesucht, um eben den Blog etwas zu verbessern. Hier der TinyTOC-Extended-Quellcode, soweit es geht kommentiert (Hinweis: Ich übernehme keine Haftung für oder gebe Garantien irgendwelcher Art auf die Software; Verwendung erfolgt auf eigenes Risiko!). Zum Installieren einfach in das /plugins-Verzeichnis kopieren, im Admin-Interface bei Plugins aktivieren und -wichtig- mindestens einmal die Konfiguration speichern.

Möchte man nun erreichen, dass bei jeder Kategorieansicht der Webbrowser die Kategorie zum Abonnieren anbietet, so muß eine Weiche programmiert werden. Es werden dabei die Kategorien auch hierarchisch abonniert, also Eltern- und alle Kinderkategorien. Ersetzt obige Zeile durch den Quelltext wie folgt:

Anmerkung: Es funktioniert nur, wenn ihr Pretty Permalinks aktiviert habt, also eure Kategorien mittels ausgeschriebener URLs ansprechen könnt. Falls ihr kein mod_rewrite auf eurem Server habt, müßt ihr obigen ersten Link so schreiben:

Das resultiert dann in einem Feed URL ähnlich diesem:

http://www.euerBlogUrl.com/wp-rss2.php?cat=20

Es war mir in einigen Artikeln aufgefallen, dass bei bestimmten Schriftgrößeneinstellungen im Webbrowser lange Wörter , die am Ende der Zeile nicht mehr hinpassen, vollständig in die nächste Zeile rutschen. Das gibt einen unschönen Effekt des “Flattertextes” bei linksbündiger Anordnung oder, bei blocksatzorientierter Anordnung große Lücken zwischen einzelnen Wörtern. Es fehlt also eine automatische Silbentrennnung, die aus langen Wörtern schön umgebrochenen, getrennten Fließtext macht.

Theorie

Zu Textsatz und Silbentrennung existiert hier ein sehr guter Artikel, der auch auf die universelle Silbentrennung, erfunden bzw. erarbeitet von Frankling Mark Liang im Jahr 1983, eingeht. Der Autor hat diesen Algorithmus dann in JavaScript umgesetzt und liefert auch die entsprechenden Musterdateien für viele Sprachen mit.

Ich möchte die Quelle kurz zusammenfassen und einige Gedanken festhalten:

1. Schriftgrößen sind im Internet (HTML, CSS) variabel, sofern die Seite “gut” programmiert ist, und hängen allein vom darstellenden Programm oder Gerät ab.
2. Je nach Schriftgröße ändert sich die Anzahl der Wörter, die in eine Zeile passen: je größer die Schrift, desto weniger Worte pro Zeile
3. Damit ein Webbrowser ein Wort oder ein Wortteil in eine neue Zeile rückt, muss es vom Rest abtrennt werden, sonst rutscht das gesamte Wort eine Zeile tiefer.

Notwendige Schritte

Es muss dem Webbrowser folglich mitgeteilt werden, an welchen Stellen ein Wort umgebrochen werden kann. Allerdings ergeben sich einige Schwierigkeiten:

1. Aktuelle Schriftgröße und -Art sind weder dem Webserver noch dem DOM (JavaScript) des Browsers bekannt. Man kann nicht herausbekommen, wieviele Pixel breit ein bestimmtes Wort ist, um eventuell die Pixelbreite für alle Wörter pro Zeile zu ermitteln.
2. Damit Suchfunktionen erhalten bleiben, kann der Datenbestand auf dem Server nicht verändert werden, sondern muss als ungetrennter, zusammenhängender Fließtext verbleiben.
3. Es existiert keine CSS(2)-Property “hyphenate” oder ähnlich.
4. Eine Trennung mittels “hart” codiertem Trennstrich “-” kommt wegen 1) nicht in Frage.

Glücklicherweise gibt es einen Ausweg. Das Zeichen lautet “&shy;” und zeigt dem Webbrowser an, wo ein Wort getrennt werden kann. Gleichzeitig aber wird es von der Darstellung ausgenommen und hat keinen Einfluß auf die Wortbreite. Als Beispiel würde man das Wort “Silbentrennung” im HTML-Quelltext korrekt

schreiben und der Webbrowser könnte korrekt umbrechen.

Lösung

Nun wäre der erste mögliche Schritt, einfach nach den Regeln des Herrn Liang die Texte in der Datenbank zu verändern und entsprechende “&shy;”s in jedes Wort einzufügen. Das würde aber den Verlust der Suchfunktionalität oder zuminedest einige Performance-Einbußen nach sich ziehen, da die Shy-Tags für jede Suche wieder entfernt werden müssen.

Eine bessere Lösung läßt sich mit JavaScript realisieren. Man muss einfach “nur” über einen gegebenen Text iterieren, die einzelnen Wörter mit mehr als x Zeichen (getrennt durch Whitespace, also Leerzeichen, Tabulator, neue Zeile, etc.) nach Herrn Liangs Regeln trennen, und für jede Trennung ein “&shy;” Tag einfügen. Danach schreibt man den Text mit neuen Tags wieder über .innerHTML=”$newText”; zurück in den HTML-Quelltext.

Der Webbrowser kann dann selbst anhand von Schriftgröße und -Art entscheiden, welches Wort wann und wo umzubrechen ist. Leute ohne JavaScript sehen den Text ganz normal ohne Umbrüche.

…und in WordPress

Eine Schwierigkeit hatte ich, den Hyphenator zum Laufen zu bekommen. Zuerst hatte ich ihn manuell in mein Theme installiert, also JavaScript-Datei und Patterns kopiert, das DIV-Tag mit Klasse “entry” noch um “hyphenate” erweitert und die Darstellung probiert.

Leider hat das mit dem Plugin highlight-source-pro nicht zusammengepaßt, die Quelltexte waren nicht mehr in der Schriftart Courier.

Der zweite Versuch mit dem WordPress-Plugin “Hyphenator” war dann von Erfolg gekrönt. Man muss zwar noch immer im DIV-Tag “entry” die Klasse “hyphenate” ergänzen, es scheint sich aber nicht mehr auf die PRE-Tags von highlight-source-pro auszuwirken. Ich habe die genaue Ursache allerdings nicht erforscht; dass es so funktioniert, hat schon gereicht

Einziger Wehrmutstropfen: FireFox 2 unterstützt die Tags nicht und behält die Wörter ohne Umbruch bei.

Damit scheinen auch andere IE-Versionen kein Problem zu haben, nur der FireFox stellt die Höhe dann (normgerecht!) viel zu gering dar und der Kasten stimmt dort nicht mehr.

Die Lösung ist schließlich eine zweite CSS-Datei, die nur per Kommentar-Browser-Weiche eingebunden wird. Ich habe in die header.php also wie folgt eingefügt:

Das zugehörige CSS schaut so aus:

Jetzt läuft’s in allen Browsern super.

Defacto funktioniert das aber nicht:

• Zum einen wird in jedem Browser das Padding der <ol>-Liste anhand der ersten (= niederwertigsten) Ziffer bestimmt und eben nicht anhand des Punkts. Das hat dann zur Folge, dass zwar die Ziffer über der graueren Border plaziert werden, der Punkt aber nicht.
• Zum anderen kommt eben der IE6 damit nicht klar und verschiebt reproduzierbar nachfolgenden Source um genau die Border-Breite nach links.

Ich habe jetzt als Lösung die Border-Deklarationen entfernt aus der “all.css” im highlight-source-pro Ordner der Instanz und ein GIF-Hintergrund (2000×1 Pixel) mit zwei verschieden grauen Bereichen erstellt. Die CSS schaut wie folgt aus:

Kleine Anmerkung zum margin-left des <ol>-Selectors: Hier nur 22px, weil die Zählung in den Browsern bei der ersten Ziffer beginnt. Hätten wir beispielsweise die Ziffer “22.”, so würde die Zählung links von der zweiten “2″, also zwischen beiden “2″ern beginnen.

Vorteil: Es klappt auch im IE6 wie gewünscht.

Nachteil: Nicht mehr XHTML-konform; wenn man die Schrift vergrößert, werden irgendwann die Ziffern über den dunkleren grauen Bereich hinauswachsen. Beim Verkleinern passiert das nicht, da hier das padding in Pixeln greift und nicht mit verkleinert wird.

Test 1 [+]
  Test 1.1
  Test 1.2
  Test 1.3
  Test 1.4
Test 2
Test 3

Würde ich nun mit der Maus über den “Test 1″-Link fahren, klappt der Baum wie gewünscht aus. Ich könnte auch Unter-Items (1.*) anwählen und hätte keine Probleme. Würde ich aber unter “1.4″ fahren, so würde die Klasse “:hover” des “Test 1″-Knotens nicht mehr aktiv sein und der Baum zusammenklappen; leider klappen damit 4 Items auf einmal ein und meine Maus wäre sofort außerhalb des Baumes.

Wenn ich nur zwei Level habe, so ist das kein Problem; bei dreien aber könnte ich bestimmte Menüpunkte nicht mehr erreichen. Außerdem kann der Internet Explorer 6 damit nichts anfangen.

Ich habe mich daher entschieden, DHTML zu verwenden. Ein unter FireFox und Internet Explorer laufendes JavaScript sieht dann so aus:

Natürlich kann man aus dem Ereignis onmouseover in Zeile 10 auch ein onclick-Ereignis machen, dann klappt der Baum erst beim Klicken auf. Eine Anmerkung zur Parameterübergabe der Funktion openTree(): Weise ich per JavaScript einem Element eine Funktion für ein Ereignis zu, so steht innerhalb der Funktion die Pseudo-Klasse this immer als das aufrufende Element zur Verfügung; ich brauche also nicht, wie von HTML her gewohnt, element.ereignis = “funktion(this)” zu schreiben.

Sicherstellen, dass er aufgeklappt bleibt, wenn die Seite z.B. in einem Unterpunkt neu geladen wird, der User also auf den Unterpunkt geklickt hat, kann man es aber wieder mit CSS:

Ich habe die display-Property der img-Tags noch so gesetzt, dass ein Baum, der gerade durch Klick auf ein Kind-Element offen bleiben soll, auch nicht mehr geschlossen werden kann; sonst wäre ja der Bezugspunkt unsichtbar.

Ein Wort noch zu deaktiviertem JavaScript: Sollte kein JS verfügbar sein, so erhält der Benutzer keinen Hinweis auf Kindsknoten. Sie werden zwar nach dem Neu-Laden wegen CSS aufgeklappt dargestellt, aber eben nicht in Echtzeit.

Eventuell wäre es deswegen sinnvoll, in einem nächsten WordPress-Release eine CSS-Klasse “page-item-haschildren” zu den “page-items” und “cat-items” mit auszugeben.

Heute hab ich der Seite einmal eine bessere Navigation verpaßt. Zwar gibt ja schon sehr viele Navigationsplugins, aber trotz zweitägiger Suche habe keines gefunden, das folgende Funktionalitäten ermöglicht:

1. Es werden in jedem Nav-Baum (Seiten, Kategorien, usw.) beim Laden der Seite nur die Ebene1-Elemente angezeigt.
2. Sollte ein Element “Kinder” haben, so muss das irgendwie kenntlich gemacht werden (z.B. ein “Plus”-Icon).
3. Wenn ich mit der Maus über ein solches Eltern-Element drüberfahre, sollen sich die Kinder der nächsten Ebene aufklappen. Ich möchte nicht erst noch auf das Eltern-Element klicken müssen, das behindert die Navigation. Drüberfahren muss reichen.
4. Die beschriebene Funktion sollte möglichst bei allen Elementen (also auch in der 5. Ebene) funktionieren.
5. Optional: Wenn möglich ohne Javascript

Nun ja, folgendes kam dabei heraus: WordPress ordnet die Navigation mittels Unordered Lists (<ul>-Tag) und verpaßt den Elementen in der Sidebar unterschiedliche CSS-Klassen.

• Jede Ebene ist für sich in ein <ul>-Tag sortiert, die Liste enthält als <li> alle Navigationspunkte der jeweiligen Ebene (also ein UL für Ebene 1, je eines für Ebene 1.1 und 1.2, usw.)
• Die <ul> der Kinder-Ebene wird innerhalb des <li>-Tags der Elternebene plaziert.
• Es haben alle Nav-Punkte z.B. der “Seiten”-Navigation mindestens die CSS-Klasse “page_item” und “page-item-$id” (beachte den Unterschied im Trennzeichen: Underscore “_” und Minus “-”!). Im Blog-Menü lauten sie entsprechend “cat_item” und “cat-item-$id”.

CSS-Teil

Wir können das Aufklappen und den aufgeklappten Baum beim neu laden der Seite also alleine über CSS ohne JavaScript lösen:

CSS-Klassen werden nicht rekursiv angewendet, deswegen ist es unbedingt erforderlich, jeden möglichen Pfad im Baum mit Klassen zu versehen. Ich habe dies oben für die Seiten-Navigation mit maximal drei Ebenen erledigt.

Sollte der Benutzer nun vom Eltern-Element wegfahren, um zu einem Kind-Element zu gelangen, so macht das nichts, er ist ja immer noch über dem allumspannenden <li>-Tag drüber. Das Menü bleibt also aufgeklappt.

JavaScript-Teil

Leider gibt WordPress in einer Ebene nicht aus, ob sich noch Kinder darin befinden. Es ist mir also nicht gelungen, das Plus-Icon oder einen Text alleine auf CSS basierend an das <a>-Tag zu hängen. Meine Idee wäre gewesen, dem <ul>-Tag der Kind-Ebene ein neues Element voranzustellen:

Leider wertet der Browser das insofern korrekt aus, als dass der den Content anzeigt, aber nur, wenn das Element sichtbar ist (display=’inherit’). Außerdem ist das CSS2-Funktionalität, die im Internet-Explorer nicht funktioniert.

Ich komme deswegen nicht um JavaScript-Benutzung:

Innerhalb des if-Statements kann eingebaut werden, wie und wo die Information über vorhandene Kindknoten erscheinen soll; bei mir eben nach dem Link als Plus-Icon.

Ich habe dieses Script in meine footer.php meines Themes eingebaut, nachdem ich den absoluten Pfad zu den Images brauche und ich das Script deswegen einmal durch den PHP-Parser schicken muss. JavaScript-Dateien (*.js) nimmt der nämlich nicht.

Falls ein User JavaScript ausgeschaltet hat, so macht das nichts, er sieht eben dann die Plus-Zeichen nicht. Anregungen oder Fragen gerne in die Kommentare…

Schreibt mir, was euch gefällt, oder was noch verbessert werden könnte. Speziell fällt mir da die Navigationsleiste bei mehreren Seiten ein: Ist es gut, dass die oben und unten erscheint? Mein Hintergedanke war, dass einige vielleicht gleich zu einer Seite gehen möchten und andere den Text immer bis ganz unten lesen.

Dann sind alle zufrieden… so long