Die iX-Benutzerdokumentation 20.19 (GoogleSites) betrifft die abgekündigte Programmversion 20.19. Die Doku ist redaktionell geschlossen und noch bis unbekannten Datum online. Alle nachfolgenden Onlinevarianten basieren auf iX-Wiki-Daten:

• iX-Wiki Onlineversion 20.20.0 abgekündigte Programmversion, redaktionell geschlossen
• iX-Wiki Onlineversion 20.20.3 abgekündigte Programmversion, redaktionell geschlossen
• iX-Wiki Onlineversion 20.21.0 abgekündigte Programmversion, redaktionell geschlossen
• iX-Wiki Onlineversion 20.21.1 abgekündigte Programmversion, redaktionell geschlossen
• iX-Wiki Onlineversion 20.21.2 abgekündigte Programmversion, redaktionell geschlossen
• iX-Wiki Onlineversion 20.21.3 abgekündigte Programmversion, redaktionell geschlossen KW16 2022
• iX-Wiki Onlineversion 20.22.0 letztes Upload steht noch aus (Suchindex wurde am 02.08.22 aktualisiert)
• iX-Wiki Onlineversion 20.22.1 Upload 30.09.2022 SMV

Zu beachten sind ggf. weitere Informationen lt. PatchNotes oder Minidokus als PDF im doku-Verzeichnis. Nachträgliche Patches sind ggf. erst in höheren Versionsvarianten Bestandteil in iX-Wiki.

Weitere (alte) Seiten im Namespace Playground

Eine neue Seite kann nach Aufruf eines toten internen Links erzeugt werden. Alternativ kann durch Eingabe des kompletten Pfads in der Adresszeile der Erstellungsprozess angestoßen werden. Das Plugin indexmenu erlaubt in der Sidebar via Kontextmenü ebenfalls die Anlage neuer Seiten. Eine weitere Form wäre das Kopieren von txt-Dateien in einen Namespace (ein Unterverzeichnis) des Wikis. Daher können theoretisch auch Musterdateien als Vorlagen oder kommandogesteuerte Prozesse zur Erstellung neuer Seiten genutzt werden. Der Name der Seite richtet sich nach dem Modulnamen in iX-Haus. Für neue Projekte stellen wir eine vorgefertigte Seite dem jeweiligen Produktmanager und Entwickler im Playgound zur Verfügung. Alle Beteiligten haben schreibende Zugriffsrechte für diesen Bereich.

So wird ein neuer Namespace im Browser manuell erstellt:

1. Startseite des Wiki aufrufen.
2. Adresszeile im Browser öffnen.
3. Namen für den Namespace plus Doppelpunkt vor dem Seitennamen start eintippen.
   Beispiel Fall A: Namespace xxxx in oberster Ebene: srv-dev/xampp/DokuWiki/Branch/doku.php?id=xxxx:start
   Beispiel Fall B: Namespace in untergeordneten Ebenen entsprechend: srv-dev/xampp/DokuWiki/Branch/doku.php?id=xxxxx:xxxx:xxxx:start
4. Neue Seite wird angezeigt als noch nicht existent. Zur Bearbeitung öffnen.
5. Titel anlegen und ggf. weitere Inhalte bzw. Verweise und speichern. Jetzt erscheint der Namespace mit Aufklappsymbol in der Menüstruktur des Wiki (sidebargesteuert).

Greeboo -> Hogfather

• bug: Beim direkten Aufruf eines Abschnitts durch Hyperlinks auffällig, eher aber ein allgemein beobachteter Effekt ist, dass das Laden einer Seite unvollständig ausgeführt wurde. Erkennbar ist dies anhand fehlender Informationen, meist nach einer Überschrift, die dann verwaist erscheint. Hier hilft die Webseitenaktualisierung im Browser (F5). Problematisch wird dies, wenn das Fehlen von Informationen unbemerkt eintritt.
• wish: Ein Hyperlink, der nicht nur zum gewünschten Abschnitt springt, sondern dort auch die betreffende Einklappung selektiv öffnet.
  Mit dem installierten Plugin sectiontoggle ist dies auf genereller Überschriftenebene möglich und wäre ggf. noch zu konfigurieren (derzeit deaktiviert). Problem ist hier, dass jede freigegebene Überschrift/Hierarchie erst einmal getoggelt wird, man also ggf. etliche Ausnahmen definieren muss. Ein weiterer Effekt kann sein, dass ein Link im TOC rechts oben auf einer Seite dann totgelegt wird, wenn der übergeordente Abschnitt eingeklappt ist. Dies führte bei unserer derzeitigen Struktur zu vielen toten TOC-Links. Aber auch andere, manuell generierte Querverweise auf Unterabschnitte wären dann 'ziellos'! Zudem sollte dann auch noch das toggle-Symbol, welches im Standard des Plugins entgegengesetzt zum toggle-Symbol in der Sidebar wirkt, überarbeitet werden, damit der Abschnittstitel nicht vom Symbol dominiert wird und die Ausrichtung des V mit der Sidebar einheitlicher Optik folgt und synchron funktioniert. Ggf. ist der Einsatz von Sectiontoggle mit Einschränkung auf eine tieferliegende Überschriftsebene eine Option? Derzeit noch einiger Diskussionsbedarf… noch keine Umsetzung.
• important:
  • nodisp-Tag mit eckigen Klammern funktioniert alleine nicht in Tabellen! Dem kann aber mit einem umrahmenden zusätzlichen WRAP-Tag begegnet werden ⇒ Beispiel

    ^Spalte 1^ Spalte 2^Spalte 3 ^ohne WRAP-Klammer^mit WRAP-Klammer^
    |  <nodisp 2>FIXME</nodisp> |  <nodisp 2>:?: </nodisp>  |<nodisp 2>:!:</nodisp>  |  :-(  | |
    |  <WRAP><nodisp 2>DELETEME</nodisp></WRAP>|  <WRAP><nodisp 2>8-O</nodisp></WRAP>  |<WRAP><nodisp 2>8-o</nodisp></WRAP>  | |  :-D  |

    ^Spalte 1^ Spalte 2^Spalte 3 ^ohne WRAP-Klammer^mit WRAP-Klammer^ | <nodisp 2></nodisp> | <nodisp 2> </nodisp> |<nodisp 2></nodisp> | | | |

    |

    |

    | | |

  • Bei Ausgabe nach PDF wird die Textstruktur gelesen (PDf <> php-Browserinterpretation). Hierbei entfaltet Nodisp-Tag technisch bedingt keine Wirkung. Daher in Nodisp-Abschnitten bitte auch so schreiben, dass ein Kunde ggf. Verständis hat, wenn er es im PDf entdeckt.
    Ein Kommentar im Nodisp-Tag dient aber auch der internen Information. Fehlender Kommentar hinterlässt fast immer Interpretationsspielräume und provoziert Informationsverlust.

• Der automatisch generierte Suchwortindex wird nicht ergänzt, wenn die Bearbeitung indirekt erfolgt, also z. B. stammdaten:personenstamm:start geöffnet wurde und hierüber in der includierten Datei parameter.txt eine Anpassung vorgenommen wird. Es wird der Status der Datei stammdaten:personenstamm:start.txt gegen das Datum des Indexsystems verglichen. Da die betroffene Start.txt aber älteren Timecode hat, passiert nichts, da sie ja auch nicht verändert wurde und es erfolgt keine Anpassung im Suchindex. Wird hingegen die Seite stammdaten:personenstamm:parameter direkt geöffnet/abgefragt, erkennt DokuWiki daher eine zeitliche Differenz zwischen Datum der index-Dateien (page.idx) und Datum der geladenen Seite. Diese ist neuer, daher wird sie neu indexiert. Generell begegnen wir diesem Effekt, indem wir vor Auslieferung eine generelle Aktualisierung des Index mit Hilfe Admin-Tools Searchindex-Manager machen. Die im ..data\index liegenden Dateien referenzieren auf Suchbegriffe (w*.idx) und deren Position und Häufigkeit (i*.idx) auf bestimmten Seiten (page.idx, pageword.idx).