playground:ixwiki

Die Sidebar ist die in DokuWiki festgelegte Seite (hier: sidebar.txt) innerhalb eines Namespaces oder einem übergeordneten Namespace, die vor allem für Navigationselemente benutzt wird. Ihre Breite ist abhängig von einer wahlweise festen oder prozentualen Breitenangabe in der Konfiguration von DokuWiki. Sie wird oft selbst im Menü nicht angezeigt (administrativ ausgeblendet via hidepages) und ist daher dann nur auf Verzeichnisebene sichtbar. Sie kann im Browserfester durch direkte Eingabe der id sidebar aufgerufen werden.

In der Sidebar nutzen wir für die Erstellung der Navigation das Plugin-basierte Indexmenu. Dieses verfügt über eine javascriptgesteuere Navigation mit Unterebenen. Das Grafikset ist dem CI angepasst individuell erstellt. Der Speicherort der individuellen Symbole ist aktuell lib\plugins\indexmenu\images\ix-wiki.png.

Bestimmte Seiten/Namespaces werden administrativ als Navigationselemente ausgeschlossen und somit in der Sidebarnavigation selbst auch nicht benannt. Die Seite sidebar.txt wird zudem generell auch von der Volltextsuche ausgeschlossen. Derzeit sind dies somit (s. Anweisung im Admin-Bereich für Darstellung) die Seiten bzw. Namespaces:

Seite	Namespace	ausgeschlossen durch	in Volltextsuche	in Sidebar-Navigation
sidebar		DokuWiki-Parameter `hidepages` sidebar	nein	nein
main		indexmenu-Parameter `skip_pages` /(:main\|:howto\|:parameter\|:technical)/	ja	nein
howto
parameter
technical
parameter1
howto1
	playground	indexmenu-Parameter `skip_index` /(playground\|wiki)/	ja	nein
	wiki	indexmenu-Parameter `skip_index` /(playground\|wiki)/	ja	nein

Im Playground setzen wir eine separate sidebar.txt ein. Da hier der Inhalt nicht per indexmenu sondern manuell generiert ist, sind die Links dort unterstrichen und es gibt dort keine indexmenu-typischen Features im Kontextklick.

Interne Links können im Wiki auf Seitenebene automatisch erkannt werden. Diese Links sind dann rot und punktiert unterstrichen dargestellt, wenn ihr Ziel noch nicht existiert. Vorteil: So kann in einer Seite beim Bearbeiten schon ein Link definiert werden, dessen Ziel dann (ggf. von anderem Wikiredakteur) einfach erstellt werden kann, indem man dem Link folgt und das Ziel bearbeitet. Bis dahin ist der Link für den normalen Anwender tot.

Am Ende der Startseite ist ein Abschnitt eingebaut, in welchem den angemeldeten Usern eine automatische gefüllte Tabelle toter interner Links angezeigt wird (orphans wanted). I. d. R. kann man hierüber die Seiten mit den toten Links ermitteln und zwecks Korrektur aufrufen. Diese Tabelle sollte daher redaktionell beachtet und möglichst immer leer sein. Sie befindet sich auch im Kopf des Redaktionsleitfadens. Treffer werden nur von den Seiten ignoriert, die per hidepages ausgeschlossen sind (dies sind die sidebar und der playground). Daher ist diese Tabelle nach der Verschiebung eines Projekts von playground in den allgemeinen Wiki-Bereich besonders zu beachten.

Verwaiste Seiten können analog mit dem Parameter orphans gesucht werden. Auf der Startseite macht diese große Tabelle redaktionell jedoch wenig Sinn. Die verwaisten Seiten sind eher ein Indiz auf fehlende Vernetzung solcher einzelstehenden Seiten mit anderen Seiteninhalten im Wiki, wobei include-Vernetzungen leider nicht berücksichtigt werden, sondern nur interne Hyperlinks! Benannt werden die Seiten hier nach dem Namen der ersten Überschrift, ansonsten leer). Daher kann man in dieser Liste dann wohl alle Seiten mit Strukturtiteln wie Was mache ich hier? ausklammern bzw. ungewöhnliche Bezeichnungen erkennen und bei Bedarf ausmerzen.

Orphans-Tabelle

Links, welche auf nicht auffindbare Abschnitte innerhalb existenter Seiten zeigen, werden nicht als tote Links betrachtet. In solchen Fällen wird die Seite aufgerufen, ohne die Sicht auf einen bestimmten Abschnitt festzulegen. Dass Abschnitte nicht auffindbar sind kann unterschiedliche Ursachen haben:

Schreibfehler im Link: der Zusatz im internen Link nach dem # unterliegt Vereinfachungsregeln (keine Großbuchstaben, Umlaute durch ausgeschriebene Diphtonge ersetzen, Ersetzungen von Leerzeichen durch Unterstrich, Auslassung von Sonderzeichen, …)
Die Überschrift, auf die verwiesen wird, wurde geändert und ist somit nicht mehr aktuell (s. Schreibfehler).
Die Überschrift wurde eingeklappt. Gefunden werden nur Überschriften, welche auch ohne Ausklappen sichtbar sind! (Fehlbedienung)

In vielen Fällen kann der Link sicher generiert werden, indem auf der Zielseite der Abschnitt über den TOC angesteuert wird. Dann steht in der Browseradresse die ID der Seite inklusive des mit # beigefügten Abschnitts. Kopiert man diese ID, kann man damit die Linkanweisung leicht und sicher aufbauen. Der interne Link besteht aus einer doppelten eckigen Klammer mit den Parametern id#abschnitt|titel. z. B.

[[playground:start#loeschen_einer_seite|Beispiel interner Link]] ⇒ Beispiel interner Link

Die Suche nach dem toten Link über den Backlink ist auf umfangreichen Seiten mit vielen Einklappungen ggf. mühsam. Ist die optische Suche (alles Ausklapen und über die Seite scrollen) nicht erfolgreich, hilft die Suche nach dem toten Link im Quelltext mittels Textsuche im Browser (Str+F) nach dem angegebenen Code des toten Links.
Eine häufige Ursache für tote Links sind nachträgliche Umbenennungen von Überschriften, Seiten oder Namespaces. Nimmt man solche manuell vor, ist es ratsam, im Anschluss die orphans wanted-Liste auf der Startseite zu checken.
Das Umbenennen von Seiten oder Namespaces kann mit dem administrativen Wiki-Plugin move durchgeführt werden. Entsprechende Links werden hierbei mit angepasst und tote Links vermieden.

Weitere (alte) Seiten im Namespace Playground

Infos zum Plugin Sectiontoggle
Infos zu Wikidesign und php-Anpassungen ⇒ php-Parameter
Playground ist das Standardtestareal der Wiki

Beim Verschieben oder Umbenennen einer Seite sind mehrere Aspekte zu beachten:

Welche internen Links zeigen auf diese Seite?
Wird die Seite in ein Verzeichnis verschoben, auf welches nicht jeder Nutzer Zugriffsrechte hat?
Welche anderen Elemente nutzen den Namen der Seite als Parameter?

Die erste Frage ist technisch leicht zu prüfen und wird vom Plugin move erledigt. Dieses Plugin kann auf Admin-Ebene auch ganze Namespaces umbenennen. Das klappt nur, wenn die zu ändernde Seite nicht durch die hidepages-Parameter administrativ ausgeblendet ist! Wird eine Seite in ein Verzeichnis verschoben, das durch Menüsysteme nicht erfasst wird oder sogar für bestimmte Benutzer zugriffsgeschützt ist, gehen zuvor verfügbare Zugriffmöglichkeiten verloren. Sofern mit differenzierten Benutzerrechten gearbeitet wird, könnte die administrative Einstellung sneaky index eine Rolle spielen (derzeit nicht aktiv).

Schwieriger wird es bei den anderen Elementen (also nicht den Hyperlinks), die den Namen (und Ort) der Seite als Parameter führen. Klassisches Beispiel: Nach dem Verschieben und/oder Umbenennen verweist ein Eintrag in dem Element einer Navigationsstruktur nicht automatisch auf den neuen Ort/Namen. Der Eintrag oder sogar das ganze davon abhängige Menü verschwindet. Erst nach manueller Anpassung wird es wieder sichtbar. Systembedingt sind daher vor allem gescriptete und selektive Navigationsmenüs von Umbenennungen oder Verschiebungen betroffen. Ebenso kann nach Verschieben einer Seite in einen anderen Namespace ein auf der Seite eingesetztes Steuerelement den Fokus auf sein ursprüngliches Ziel verlieren. Auch hier ist eine Anpassung an die geänderte Position oftmals manuell erforderlich. Daher ist es sinnvoll, ein Verzeichnis der Seiten zu führen, welches solche Elemente auflistet. Dies wird bei uns auf der Startseite in einem nur den Redakteuren sichtbaren Abschnitt gesuchte Seiten - broken links realisiert.

Für die Arbeit von iX-Wiki in Zusammenhang mit SVN bedeutet dies, eine bestimmte Abfolge von Schritten bei der Umbenennung beizubehalten, um die Historie des Textes in SVN zu erhalten. Beispiel: Im Trunk soll für Excel-Berichte die Seite system.txt in technical.txt umbenannt werden.

Aufruf der Seite über den Browserpfad
srv-dev/xampp/DokuWiki/trunk/doku.php?id=berichtscenter:excel_berichte:system
srv-dev\DokuWiki\Trunk\data\pages\berichtscenter\excel_berichte\system.txt (analoger Dateipfad)
Umbenennen in DokuWiki: → Links werden angepasst, → Datei wird umbenannt system.txt → technical.txt
SVN-Commit vorbereiten
1. Dateinamensänderung auf Verzeichnisebene zurücknehmen: technical.txt → system.txt
  \\srv-dev\DokuWiki\Trunk\data\pages\berichtscenter\excel_berichte\technical.txt →
  \\srv-dev\DokuWiki\Trunk\data\pages\berichtscenter\excel_berichte\system.txt
2. SVN-Rename über SVN-Kontextmenü im Dateiexplorer: system.txt → technical.txt
SVN-Commit
Merge abwarten (Mail mit Konflikt?), ggf. Mergekonflikt bereinigen
Update auf branch (Mail mit Konflikt?) ggf. Mergekonflikt bereinigen

Commit-Beispiel:

Auslöser		ix-Wiki Excel-Berichte
Inhaltliche Änderung	
Doku			
Testhinweise		
Betroffene Module	
Technische Änderung	rename system.txt -> technical.txt

Das Commit erzeugt mehrere E-Mails, die im Idealfall alle Status OK haben:

Merge OK  Revision 153515 (trunk) (arr)
PostCommit OK excel_berichte  Revision 153516 (branch) (arr)
Deploy OK  Revision 153516 (branch) (arr)
Done 'w:\branch\ix_dev\doku\DokuWiki\data\pages\berichtscenter\excel_berichte' (branch) (arr)

Sollten Merge-Konflikte benannt werden, müssen diese bearbeitet werden!

Nachdem alles OK ist, muss als letzter Schritt der Branch upgedated werden: SVN-Update von
\\srv-dev\DokuWiki\Trunk\data\pages\berichtscenter\excel_berichte
Die umbenannte Datei taucht hier mit der Action Deleted: Alter Dateiname und Added: Neuer Dateiname auf.

Sollten Merge-Konflikte benannt werden, müssen diese bearbeitet werden!

Greeboo -> Hogfather

Für das Upgrade dringend empfohlen und auch verwendet wurde das DokuWiki Upgrade Plugin, welche natürlich zuerst installiert werden musste.

Die Kompatibilitätsfrage bzw. Info bzgl. Indexmenu-Plugin hat sich relativiert. Es ist eine Einstellung in local.php unter dokuwiki\conf möglich, die auch unter Hogfather ein operables, javascriptgesteuertes Indexmenü ermöglicht (ansonsten wären Layout geändert wie auch Zugang zu Untermenüelementen verwehrt gewesen). Eingefügt werden musste nach dem Upgrade nur die folgende Zeile:

$conf['defer_js'] = 0;

Eine Demoinstallation auf Basis der Trunkversion vom 01.10.2020 ist als Video unter i:\doku\Projekt iX-Wiki verfügbar. Die zugrundeliegende Datenbasis (Komplettsicherung) und das Ergebenis (in einer on the Stick-Variante) sind dort ebenfalls als 7z-Archiv im Unterverzeichnis DokuWiki abgelegt.

Update 20.10.2020: Beide iX-Wikis (und hierdurch auch nachfolgende Wikis) sind nun erfolgreich upgegradet! Zuvor habe ich jeweils eine Sicherungskopie als 7z-Archiv erstellt. Eine Dateiliste der Anpassungen liegt als Textfile vor (Mail an SMV).

Ablauf

Installation des PlugIns DokuWiki Upgrade Plugin
Datensicherung
Update via Admin-Funktion
Update von weiteren Plugins?
Anpassung bei Bedarf, z. B. JavaScript-Einstellung $conf['defer_js'] = 0; in local.php-datei (s. u.)

Anpassung nach Upgrade auf Wiki-Programmversion 2020-07-29 „Hogfather“

in …\dokuwiki\conf\local.php einfügen der Zeile $conf['defer_js'] = 0; (zumindest derzeit erforderlich, damit Javascript gesteuertes Indexmenü in der Sidebar funktioniert!
Erstellung von Datensicherungen:
- Version 20.20.0 wurde am 20.10.2020 durch arr upgegradet. Eine lokale Datensicherung wurde vor Upgrade erstellt. Sie liegt in Form der Datei Version.20.20.0_Stand20201019.7z vor.
- Version 20.20.2 wurde am 20.10.2020 durch arr upgegradet. Eine lokale Datensicherung wurde vor Upgrade erstellt. Sie liegt in Form der Datei Version.20.20.2_Stand20201019.7z vor.
Anpassung TOC Titel (s. o., Anpassung des TOC-Titels)
Anpassung der Fußzeile über ..\dokuwiki\lib\tpl\dokuwiki\tpl_footer.php für die Links und die dazugehörigen Grafiken zu Datenschutz, Spacewell-Germany und Impressum, Bearbeitung der Grafiken für zweifarbige Darstellung.
Anpassung der ccs-Vorgaben für H1 bis H5 (s. o., Abschnitt Styles)
Durch das Upgrade wurden folgende Seiten neu erstellt:

/data/page/wiki/dokuwiki.txt

/data/page/wiki/syntax.txt
/data/page/wiki/welcome.txt

Diese waren zu prüfen. In syntax.txt wurden tote Links durch redaktionelle Bearbeitung entfernt.

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).

DokuWiki wird mit einigen PHP-Scripts ausgeliefert, die dazu gedacht sind von der Kommandozeile (UNIX) des DokuWiki-Servers aus ausgeführt zu werden. Die Kommandozeilen-Scripts liegen unter dem bin Ordner.

Notiz: Um die Scripts benutzen zu können, muss der PHP Kommandozeilen-Interpreter (CLI) installiert sein.

Die Scripts können auf zwei unterschiedliche Arten ausgeführt werden.

Entweder können sie ausführbar gemacht werden:

$> chmod +x <script>.php
$> ./<script>.php

oder direkt über den Interpreter aufgerufen werden:

$> /path/to/php <script>.php

</nodisp>

dwpage.php

Erlaubt das Editieren von Seiten unter der Kommandozeile.

Usage: dwpage.php [opts] <action>
  
  Utility to help command line DokuWiki page editing, allow
  pages to be checked out for editing then committed after changes
  
  Normal operation would be;
  
  
  ACTIONS
      checkout: see $ dwpage.php --help=checkout
      commit: see $ dwpage.php --help=commit
      lock: see $ dwpage.php --help=lock
  
  OPTIONS
      -h, --help=<action>: get help
          e.g. $ ./dwpage.php -hcommit
          e.g. $ ./dwpage.php --help=commit

indexer.php

Erlaubt das Aktualisieren des search-Indexes.

Usage: indexer.php <options>
  
  Updates the searchindex by indexing all new or changed pages
  when the -c option is given the index is cleared first.
  
  OPTIONS
      -h, --help     show this help and exit
      -c, --clear    clear the index before updating
      -q, --quiet    don't produce any output

Dieses Script muss mit dem richtigen Benutzer sowie im richtigen Verzeichnis ausgeführt werden um zu funktionieren (z. B. unter dem Benutzer www-data in /var/www/dokuwiki/data unter Debian Lenny). Wie kann ich prüfen, ob eine bestimmte Seite indiziert wurde? Warum werden bestimmte Seiten trotz Existenz im pages-Verzeichnis in der Linksuche nicht angezeigt? Die selben Seiten scheinen auch die zu sein, die nicht Indexiert werden. Z. B. die Suche nach dem Begriff Domäne sollte für fachadministration:systemmodule:systemeinstellungen_allgemein:start Systemeinstellungen Allgemein referenziert sein. ⇒ 25 Treffer (Domäne Domänen)
Eine Antwort findet sich ggf. in den hidepages. Sind hier für das wiki seiten definiert, werden diese im Indexmenü und in der suche nicht angezeigt (da herausgefiltert). Für das Indexmenü-PlugIn gibt es eine eigene Einstellung zum Ausblenden bestimmter Treffer. Diese wirkt sich dann nicht auf die treffer der Volltextsuche aus.
Administrativ kann der Suchindex neu aufgebaut werden. Dies kann einige Zeit in Anspruch nehmen. Intern werden die Indexinformationen auch beim Laden einzelner Seiten aktualisiert.

wantedpages.php

Zeigt die von den Benutzern geforderten Seiten an.

Usage: wantedpages.php [wiki:namespace]
  
  Outputs a list of wanted pages (pages which have
  internal links but do not yet exist).
  
  If the optional [wiki:namespace] is not provided,
  defaults to the root wiki namespace
  
  OPTIONS
      -h, --help get help

Eine Anpassung muss nach einem Update von DokuWiki oder einem PlugIn ggf. erneut vorgenommen oder adaptiert werden, wenn zum Tuning von DokuWiki zu iX-Wiki eine interne Datei angepasst oder ausgetauscht wurde. Daher ist es sinnvoll, die Anpassung in Schriftform oder als Datei zu sichern.

Anpassung des Favorite-Icons

Die Datei favicon.png wird über den Medien-Manager in das System kopiert. Das quadratische iX-Logo ist derzeit in Anlehnung an die iX-Haus-Marke gestaltet. Der Schriftzug Wiki ist jedoch kaum erkennbar, aufgrund der vom Browser reduzierten Skalierung. Die Bildgröße sollte mindestens 16×16 Pixel aufweisen, besser 32×32. 64×64 ergibt keine Qualitätsverbesserung. Ggf. übernimmt SUN aus dem Marketing die Optimierung der Datei.

neues favicon.png ab 01.04.2021? gestellt (s. Meeting am 18.03.2021 DSN, ARR, PSZ)

Anpassung der Fußzeile

Die aktuellen Logos von DokuWiki mit Grafiken und Hyperlinks zu den jeweiligen OpenSource- und Lizenzinformationen waren unerwünscht. Erforderlich hingegen sind die Benennungen von Links zum Impressum und Datenschutz auf der Startseite. Diese sind nun als Links in der Startseite realisiert. Dementsprechend wurden die Dateien ..\dokuwiki\conf\license.local.php erstellt und tpl_footer.php angepasst.

Wo das Entfernen bzw. Tauschen der Hyperlinks nicht ausreicht, wird das als Link genutzte Logo umbenannt. In Datei ..\dokuwiki\lib\tpl\dokuwiki\tpl_footer.php wurde Zeile 13: <?php tpl_license(''); // license text ?> innerhalb <div id="dokuwiki__footer"><div class="pad"> vor <div class=„buttons“> entfernt, Zeilen im Block <div_class=“buttons“> wurden für Impressum, Kontakt und Datenschutz der CREM SOLUTIONS angepasst. Die verbliebene Grafik \\srv-dev\DokuWiki\Branch\lib\tpl\dokuwiki\images\button-crem.gif der Fußzeile wurde aktualisiert.

Anpassung mit Datenschutz, Impressum, Weblink zur Spacewell- bzw. CREM SOLUTIONS-Hauptseite und Mail-To zu einer noch zu erstellenden Doku-Mailadresse. Datenschutz auf Webseite muss bzgl. Wiki ergänzt werden (temp. Session-Cookie) – hierzu wurde Philipp Spitz informiert (05.06.2020). Eine Mail-to-Adresse für Doku ist nicht zwingend erforderlich, hier kann der Kunde auch die Support- oder Infoadresse nutzen.

Nachtrag 17.11.2022 ARR: Bzgl. der Frage, inwiefern in iX-Wiki zusätzlich auf Cookies verwiesen werden muss: Ja es gibt ab 01.01.2021 gewissermaßen eine Cookie-Banner-Pficht auf Basis der neuen DSGVO. Für Tracking-Dienste und Cookies, die auf einer Webseite eingesetzt werden, soll daher ein Banner den Besucher neutral informieren und nicht erforderliche Tracker oder Cookies optional von diesem auch ablehnen lassen. In iX-Wiki werden in der Grundausstattung seitens DouWiki maximal drei Cookies genutzt. Cookie DokuWiki ist technisch notwendig und ist temporär (das DokuWiki-Cookie wird mit Schließen des Browsers gelöscht). Realisiert wird hiermit z. B. die Verlaufsleiste Zuletzt angesehen. Theoretisch könnte das Cookie nach Benutzeranmeldung und Freischaltung einer remeber-Option ein Jahr gültig sein (aber nur, wenn der Benutzer die remember me-Funktion aktiv einschaltet). Wir haben iX-Wiki jedoch so konfiguriert, dass diese Abfrage im öffentlichen Auftritt unter wiki.crem-solutuions gar nicht angeboten wird. In den Wiki-Versionen der Subdomain wiki.crem-solutions.de können sich keine Benutzer anmelden. Daher sind auch die beiden anderen Cookies irrelevant: Cookie DW<hash> wäre nur nach einem Login technisch notwendig, ist somit nicht relevant. Cookie DOKU_PREFS wäre funktional, ist aber ebenfalls nur nach Login relevant. Mit dem Schalter Datenschutz im Footer verweisen wir zudem auf jeder Seite auf die aktuelle Datenschutzerklärung der CREM SOLUTIONS. Um den prinzipell dennoch erforderlichen Cookiebanner zu schalten, verzichten wir darauf, in jeder Wiki-Version irgendeine Plugin-Lösung zu etablieren. Die bekannten DokuWiki-Plugins erfüllen i. d. R. nicht die gesetzlichen oder internen Anforderungen. Das Marketing der CREM SOLUTIONS verwendet daher ein professionelles Tool namens Cookiebot, welcher auch für die Subdomain wiki.crem-solutions.de eingesetzt werden soll. Dies deckt dann alle Erfordernisse ab (erkennt z. B. auch zukünftig durch irgendwelche Plugins ggf. neu hinzukommende Cookies, Suchlauf über alle Seiten hierzu mindestens einmal monatlich) und das IT-technische Management des Webauftritts der CREM SOLUTIONS bleibt so auch in der Hand des Marketings.

Anpassung des Logos

Das Logo (links oben) wird über den Medien-Manager als logo.png in das System kopiert. Ist das Logo unter 500 Pixel breit, wird bei den meisten Bildschirmeinstellungen der Schriftzug durch die Bindestrichkombination aufgeteilt . Es gab einen Ansatz, das in der Demo verwendete Logo mit einem transparenten Bereich auf der rechten Seite zu versehen. Ein anderer Ansatz ist, den Namen als Bildbestandteil zu definieren. Vorteil: Form und Farbe des Schriftzuges sind CI-konform vollständig redaktionell anpassbar.
Aktuell: Crem Solutions-Logo mit Wortmarke in der Art, dass diese mit dem Schriftzug iX-Wiki in der Größe harmoniert → logo.png mit 200*45 Pixel.
Das neue Cremsolutions-Logo löst ab April 2021 das Spacewell-Logo ab. Das zugrundeliegende Logo wird vom Marketing zur Verfügung gestellt (s. Meeting am 18.03.2021 DSN, ARR, PSZ), neueste Fassung des Logos 03.11.2022 (Durch Generierung direkt aus svg-Grafik nach png und transparentem Hintergrund wurden sog. Blitzer enfernt, die Grafik wirkt so klarer. Der Zusatz A NEMETCHEK COMPANY in Mikroschrift ist nur zu erahnen. Eine qualitative Verbesserung kann hier nur erfolgen, wenn statt PNG eine Vektorgrafik wie SVG eingesetzt wird. Dieser Dateityp wird von DokuWiki für das Logo derzeit aber nicht unterstützt. PNG ist derzeit die beste Wahl.)

Anpassung der Suchinfo

Der statische Text im Kopfbereich der dynamisch generierten Resultatseite einer Suche basiert auf jeweils Zeile 3 von
W:\Version.20.22.1\inc\lang\de\searchpage.txt → Unten sind die Ergebnisse Ihrer Suche gelistet. @CREATEPAGEINFO@ bzw.
W:\Version.20.22.1\inc\lang\de-informal\searchpage.txt → Unten sind die Ergebnisse deiner Suche gelistet. @CREATEPAGEINFO@. Hier lässt sich eine verbesserte Benutzerführung durch Integration einen Tipps zur Suche erzielen, z. B. Ergänzung mit Hinweis zur browserspezifischen Suche oder einem Link zu unserer Erläuterung der Suchfunktionen.

\inc\lang\de\searchpage.txt vorher …

====== Suche ======

Unten sind die Ergebnisse Ihrer Suche gelistet. @CREATEPAGEINFO@

\inc\lang\de\searchpage.txt nachher …

====== Suche ======

Unten finden Sie die optisch hervorgehobenen Ergebnisse Ihrer Suche.

<WRAP tip>Klappen Sie eine Seite mit "Alles aus-/einklappen" rechts im iX-Wiki-Menü auf und suchen anschließend per Suchfunktion (Strg + f) Ihres Browsers nach 
dem gewünschten Begriff. So verläuft die Suche über alle Einträge im Inhaltsverzeichnis rechts in der Seite sowie über den gesamten Fließtext. \\ 
Vermissen Sie Ergebnisse bei einer absoluten Suche, z. B. nach ''wirtschaftsplan'', sollten Sie mit einer Fragmentsuche nach mehr Treffern suchen, z. B. mit ''*wirtschaftspl*''. 
Weitere Hinweise und Tipps finden Sie im Abschnitt [[grundlagen:ixwiki#suchen_in_ix-wiki|Suchen in iX-Wiki]].</WRAP>

Diese Anpassung haben wir mit Version 20.22.3 umgesetzt.

Anpassung des TOC-Titels

Der Titel für das Inhaltsverzeichnis einer Wikiseite (table of content) wurde von Inhaltsverzeichnis auf Inhalt verkürzt. Die Anpassung erfolgte in der deutschen Sprachsteuerungsdatei ..\dokuwiki\inc\lang\de\lang.php an der Position Zeile 219, $lang[‘toc‘] in der Greebo-Variante bzw. in Zeile 229 der Hogfather-Variante.

Einstellungen für dass iX-Wiki Template Design

Admin ⇒ Einstellungen fürs Template Design ⇒ Seitenhintergrund

Im Template DokuWiki wurde via Konfigurations-Manager (ein dazugehöriges Plugin) die Hierarchische Pfadnavigation aktiviert. Hierdurch erhält ein Benutzer von einer Seite stehend Zugriff auf übergeordnete Seiten. An gleicher Stelle wird auch der Name festgelegt. Momentan lautet dieser iX-Wiki. (Ein Name ohne Trennzeichen wäre geeigneter bzgl. der automatischen Logo/Namensdarstellung Kopfbereich der Seiten.) Workaround: kein Name und Namen als Bild integrieren.

Die Einstellung bzgl. Veröffentlichung unter Lizenz wurde auf keine geändert. Zur Steuerung des internen Seiteninhalts (TOC) wird ab Überschrift 2 (h2) begonnen und es werden maximal bis zu Überschriftsebene 4 (h4) ausgeführt. Es sind mindestens drei Einträge erforderlich, damit der TOC generiert wird. Im Bereich DokuWki Aktionen unterbinden wurde probehalber die Aktion Letzte Änderungen deaktiviert. Welche weiteren Einstellungen hier für den Regelbetrieb sinnvoll sind, ist noch zu prüfen.

Bei Bedarf kann die Bearbeitungsfunktion HTML erlauben aktiviert werden, falls anderweitige Lösungen mit Plugins nicht greifen.

Das Setzen eines Anmeldecookies (Angemeldet bleiben) wurde im Konfigurationsmenü unter „Authentifizierungs-Konfiguration“ Permanente Login-Cookies erlauben (Auf diesem Computer eingeloggt bleiben) deaktiviert.

Nachfolgend sind die Anpassungen gelistet, welche nicht durch Plugins oder Templates realisiert werden.

Styles

DokuWiki sieht keine besondere Farbgebung für die Überschriften vor. Die Überschriften werden in DokuWiki via PHP und CSS mit h1- bis h5-Tags realisiert. Als Formatanweisungen werden im Wiki-Text Überschriften mit aufeinanderfolgenden Gleichheitszeichen geklammert: ======h1======, =====h2=====, ====h3====, ===h4===, ==h5==. Überschriften sind automatisch als Ziele von Sprungmarken (Hyperlinks) geeignet. Selbst können sie nicht zusätzlich als Hyperlink formatiert werden! Dagegen sprechen technische wie auch typographische Gründe.

In der Datei basicless.css im Verzeichnis dokuwiki\lib\tpl\dokuwiki\css können von Templates abhängige Formatierungen erweitert oder angepasst werden. In Anlehnung an das gültige CI sehen wir vor, die Überschriften dem Crem-Blau hervorzuheben. Die Anpassung der Header-Formate für Crem-Blau erfolgt in DokuWiki über ergänzende CSS-Angaben in der Datei basicless.css bzgl. der Farben kann in Hexadezimal: color: #003EDC; erfolgen. Auszug aus „C:\Work\w_branch\Intern\Technische Redaktion\DokuWiki\iXDokuWiki\dokuwiki\lib\tpl\dokuwiki\css\basic.less“:

h1 {
font-family: Helvetica, Arial, Geneva, sans-serif;
font-size: 2em;
margin: 0 0 0.444em;
color: #06478A;
}
h2 {
font-family: Helvetica, Arial, Geneva, sans-serif;
font-size: 1.5em;
margin: 0 0 0.666em;
color: #06478A;
}
h3 {
font-family: Helvetica, Arial, Geneva, sans-serif;
font-size: 1.25em;
margin: 0 0 0.888em;
color: #06478A;
}
h4 {
font-family: Helvetica, Arial, Geneva, sans-serif;
font-size: 1em;
margin: 0 0 1.0em;
color: #06478A;
}
h5 {
font-family: Helvetica, Arial, Geneva, sans-serif;
font-size: .875em;
margin: 0 0 1.1428em;
color: #06478A;
}

In der Datei ..\dokuwiki\conf\tpl\dokuwiki\style.ini werden Einstellungen gespeichert, welche administrativ in DokiWiki vorgenommen werden können. Wesentliche Anpassung hier ist die Einstellung der Seitenbreiten für einen links angeordneten Bereich, der meistens für Navigationszwecke genutzt wird (sidebar) und das Hauptfenster (site). In der Grundeinstellung von DokuWiki sind diesen Bereich absolute Breitenangaben in em festgelegt. Sidebar und Site reagieren dann nicht auf Größenänderung des Browserfensters! Durch die Anpassung in %-Werte reagiert DokuWiki in der Breitenberechnung dynamisch und liefert dann ein besseres Layout. Die %-Werte für Sidebar und Site müssen wir nach Fertigstellung ggf. noch anpassen. Auswahlmöglichkeiten für individuelle Farbanpassungen für den Text können mit Hilfe von Plugins eingebaut werden, vgl. color-Plugin. Einige der Einstellungen sind auch im iX-Wiki über Admin > Einstellungen fürs Template-Design einstellbar.

Textuelles Abbild von style.ini mit prozentualer Breitenangabe für site und fester Breite für sidebar (und TOC):

[replacements]
;These overwrites have been generated from the Template styling Admin interface
;Any values in this section will be overwritten by that tool again
__text__ = "#333333"
__background__ = "#ffffff"
__text_alt__ = "#999999"
__background_alt__ = "#eeeeee"
__text_neu__ = "#666666"
__background_neu__ = "#dddddd"
__border__ = "#cccccc"
__highlight__ = "#c8dcde"
__link__ = "#06478A "
__background_site__ = "#fcfcfc"
__existing__ = "#00737e"
__missing__ = "#dd3300"
__site_width__ = "95%"
__sidebar_width__ = "20em"
__tablet_width__ = "800px"
__phone_width__ = "480px"
__theme_color__ = "#008800"

Die Hyperlinkfarbe wird u. a. im TOC verwendet. Das Blau der Schrift lt. Wortbildmarke analog zur Website der Crem wird in der style.ini in der Domäne replacements der Eintrag link = „#06478A “ gesetzt oder im iX-Wiki über Admin > Einstellungen fürs Template-Design der entsprechende Eintrag für die Allgemeine Linkfarbe (#06478A). Diese Farbe wird auch für die Headerdefinition h1 bis h5 in lib\tpl\dokuwiki\css\basic.less verwendet.

In der Datei lib\plugins\wrap\style.less passen wir die Zeilen für die wrap-tags important und tip an (gelbfarbener Hintergrund) (ab iX-Wiki 20.20.0)

.wrap_important { background-color: #ffd39f; } 	mit #ffff79f;und 
.wrap_info { background-color: #d1d7df; } 		mit #ffffe0; als Hintergrundfarbe an.

Modifikation auf einheitliche Hintergrundfarbe ab iX-Wiki 20.20.3: Auszug aus „W:\Version.20.20.3\lib\plugins\wrap\style.less“
Anpassung Hintergrundfarbe important wie bei tip ab iX-Wiki für 20.20.3 (die dark.wrap Varianten wurden nicht angepasst!)

vorher…

/*____________ important ____________*/
.wrap_important { background-color: #fff79f; }
.wrap__dark.wrap_important { background-color: #6c3b00; }
div.wrap_important { background-image: url(images/note/48/important.png); }
span.wrap_important { background-image: url(images/note/16/important.png); }

/*____________ alert ____________*/
.wrap_alert { background-color: #ffbcaf; }
.wrap__dark.wrap_alert { background-color: #ffed44; }
div.wrap_alert { background-image: url(images/note/48/alert.png); }
span.wrap_alert { background-image: url(images/note/16/alert.png); }

/*____________ tip ____________*/
.wrap_tip { background-color: #ffffe0; }
.wrap__dark.wrap_tip { background-color: #4a4400; }
div.wrap_tip { background-image: url(images/note/48/tip.png); }
span.wrap_tip { background-image: url(images/note/16/tip.png); }

nachher… (Hintergrundfarbe für Wrap Important auf #fffffe0; wie bei Tip gesetzt)

/*____________ important ____________*/
.wrap_important { background-color: #ffffe0; }
.wrap__dark.wrap_important { background-color: #6c3b00; }
div.wrap_important { background-image: url(images/note/48/important.png); }
span.wrap_important { background-image: url(images/note/16/important.png); }

Inhalt

DokuWiki Basiswissen

Welche Wiki-Dateien sollten trunk/branch-spezifisch sein?

Onlineversionen

Einbinden von Grafiken

Bearbeiten der Seite sidebar

Tote interne Links

Weitere (alte) Seiten im Namespace Playground

Erstellung einer neuen DokuWiki-Seite

Erstellung eines Namespaces

Verschieben/Umbenennen einer Seite

Erzeugen einer Basisstruktur für neue Programmversion

Upgrade DokuWiki