====== DokuWiki Basiswissen ====== 

====Welche Wiki-Dateien sollten trunk/branch-spezifisch sein?====
++++|

<nodisp 2>
  * Seitenverzeichnis data\pages
  * Indexverzeichnis data\index => Index für Suchfunktionen in iX-Wiki 
  * Medienverzeichnis data\media
  * Plugin in Testphase
  * Neuerungen in Branch (inhaltliche Dateiunterschiede => Differenzierung ist via TortoiseSVN und update/commit-Workflow zu managen)
</nodisp>

++++
====Onlineversionen====
++++|

Die [[https://sites.google.com/a/crem-solutions.de/doku/|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:

  * [[http://wiki.crem-solutions.de/Version.20.20.0|iX-Wiki Onlineversion 20.20.0]] abgekündigte Programmversion, redaktionell geschlossen
  * [[http://wiki.crem-solutions.de/Version.20.20.3|iX-Wiki Onlineversion 20.20.3]] abgekündigte Programmversion, redaktionell geschlossen
  * [[http://wiki.crem-solutions.de/Version.20.21.0|iX-Wiki Onlineversion 20.21.0]] abgekündigte Programmversion, redaktionell geschlossen
  * [[http://wiki.crem-solutions.de/Version.20.21.1|iX-Wiki Onlineversion 20.21.1]] abgekündigte Programmversion, redaktionell geschlossen
  * [[http://wiki.crem-solutions.de/Version.20.21.2|iX-Wiki Onlineversion 20.21.2]] abgekündigte Programmversion, redaktionell geschlossen
  * [[http://wiki.crem-solutions.de/Version.20.21.3|iX-Wiki Onlineversion 20.21.3]] abgekündigte Programmversion, redaktionell geschlossen KW16 2022
  * [[http://wiki.crem-solutions.de/Version.20.22.0|iX-Wiki Onlineversion 20.22.0]] letztes Upload steht noch aus (Suchindex wurde am 02.08.22 aktualisiert)
  * [[http://wiki.crem-solutions.de/Version.20.22.1|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.

++++
==== Einbinden von Grafiken ====
++++|

<nodisp 2>
Die Integration von Grafiken in iX-Wiki ist in Einzelfällen didaktisch sinnvoll. Bilder werden im Kontext zu einer Wikiseite upgeloadet und integriert.  Formatanweisungen: linksbündig, große Grafiken (Breite >= 400) auf Stufe M verkleinert und mit Link, ansonsten in Originalgröße ohne Link. Das Umfließen kleinerer Grafiken kann mit Hilfe leerer Überschriften der Kategorie 5 unterbunden werden. Manchmal gewollt, meist eher unerwünscht, kann der umfließende Modus auch die Positionierung von nachfolgenden Elementen wie Tabellen maßgeblich beeinflussen!

Die Grafiken können hinter dem Pipezeichen im Link tituliert werden (Aktiv bei Anzeige des Titels bei Mouseover oder beim Vorlesen der Seite)(Beispiel 1). Eine Bildunterschrift kann mit Zeilenumbruch nach dem Link erstellt werden (Beispiele 2 und 3).

Beispiel 1: 
Beachte dass neben den systembedingten Größenvorschläge auch manuelle Größenangaben möglich sind. (Details hierzu [[wiki:syntax#media_files|hier]].)
  == ==
  {{:hieran_arbeiten_wir.png?nolink&75 |Infografik Hieran arbeiten wir...}} und der Text fließt weiter...
  == ==

== ==
{{:hieran_arbeiten_wir.png?nolink&75 |Infografik Hieran arbeiten wir...}} und der Text fließt weiter ...
== ==

Beispiel 2: Grafik ohne Link
  == ==
  {{:ix-haus_plus:flaechen_plus:leerstandsalarm_aktivitaeten_historie.png?nolink|}}\\ Abb.: Dialog zur Einstellung der Vermietungsaktivitäten  
  == ==
== ==
{{:ix-haus_plus:flaechen_plus:leerstandsalarm_aktivitaeten_historie.png?nolink|}}\\ Abb.: Dialog zur Einstellung der Vermietungsaktivitäten  
== ==

Beipiel 3: Grafik mit Link 
  {{:ix-haus_plus:flaechen_plus:leerstandsalarm_aktivitaeten_historie.png?direkt&400|}}\\ Abb.: Dialog zur Einstellung der Vermietungsaktivitäten  

{{:ix-haus_plus:flaechen_plus:leerstandsalarm_aktivitaeten_historie.png?direkt&400|}}\\ Abb.: Dialog zur Einstellung der Vermietungsaktivitäten  


Um Grafiken einzubinden, werden diese mit dem ''Medien-Manger'' bereitgestellt. Der Link hierzu befindet sich rechts oben im Browserfenster. <wrap important>Hier ist zu beachten, dass der Aufruf des Medien-Managers mit einfachem Klick die aktuelle Seite verlässt und als Speicherort den aktuellen Standort vorschlägt.</wrap> Daher bietet es sich an, den Medienmanager von einer zweiten gespiegelten Browsersitzung zu starten. Steht man also z. B. in der Seite ''fachadministration:docuware_integration:start'', wird beim Start des Medien-Managers diese Seite geschlossen (auch wenn diese im Editmodus aufgerufen war!) und der Medien-Manager-Dialog im Namespace ''fachadministration:docuware_integration'' aktiviert. Soll ein Upload woanders gespeichert werden, stellt man im Medien-Manager unter Namensraum wählen den gewünschten Standort ein oder begibt sich vor dem Aufruf erst an die gewünschte Stelle. So ist eine strukturierte Medienablage möglich. Allgemeine, ggf. mehrfach zu verwendende Grafiken legt man am besten in der obersten Ebene ab, ab der die Grafiken in unterschiedlichen Unterverzeichnissen benötigt werden.
</nodisp>

++++


==== Bearbeiten der Seite sidebar ====
++++|

<nodisp 2>
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'' <WRAP>/(:main|:howto|:parameter|:technical)/</WRAP>|ja|nein|
|howto| |:::|:::|:::|
|parameter| |:::|:::|:::|
|technical| |:::|:::|:::|
|parameter1| |:::|:::|:::|
|howto1| |:::|:::|:::|
| |playground|indexmenu-Parameter ''skip_index'' <WRAP>/(playground|wiki)/</WRAP>|ja|nein|
| |wiki|:::|:::|:::|
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.
</nodisp>

++++

==== Tote interne Links ====
++++|
<nodisp 2>
Interne Links können im Wiki auf Seitenebene automatisch erkannt werden. Diese Links sind dann [[playground:toterlinkmusterseite|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|
Zur Erstellung der Tabelle können Sie hier die nur im Editmodus sichtbaren Prozentzeichen vor und nach dem Befehl ''%%ORPHANSWANTED:orphans%%'' durch Tilden ersetzen... =>  ''%%~~ORPHANSWANTED:orphans~~%%''
Die Tabellenfunktion ist hier deaktiviert, um die Ladezeit dieser playground-Seite zu verkürzen. (Doppelte Prozentzeichen-tags blockieren die Wiki-Interpretation des geklammerten Inhalts.). Eine aktive Tabelle der finden Sie zudem schon auf der Startseite. \\

%%ORPHANSWANTED:orphans%%
++++

<WRAP important>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)
</WRAP>
<WRAP tip>
  * 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]]%%'' => [[playground:start#loeschen_einer_seite|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.
</WRAP>
</nodisp>


== Weitere (alte) Seiten im Namespace Playground ==
<nodisp 2>
  * Infos zum Plugin [[playground:sectiontoggle|Sectiontoggle]] 
  * Infos zu Wikidesign und php-Anpassungen => [[playground:parameterphp|php-Parameter]]
  * [[playground:playground|Playground]] ist das Standardtestareal der Wiki 
</nodisp>

++++
==== Erstellung einer neuen DokuWiki-Seite ====
++++|
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.
++++
==== Erstellung eines Namespaces ====
++++|
So wird ein neuer Namespace im Browser manuell erstellt:
  - Startseite des Wiki aufrufen.
  - Adresszeile im Browser öffnen.
  - 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''
  - Neue Seite wird angezeigt als noch nicht existent. Zur Bearbeitung öffnen.
  - Titel anlegen und ggf. weitere Inhalte bzw. Verweise und speichern. Jetzt erscheint der Namespace mit Aufklappsymbol in der Menüstruktur des Wiki (sidebargesteuert).
<WRAP tip>Wird ein interner Link erzeugt, so wird beim Aufruf durch einen User mit Schreibrechten die Möglichkeit gegeben, die Seite zu erzeugen, falls sie noch nicht existiert. Hierbei wird ein ggf. noch nicht existenter Namespace ebenfalls generiert, falls der interne Link auch einen Namespace beinhaltet. </WRAP>
++++

==== Verschieben/Umbenennen einer Seite ====
++++|
<nodisp 2>
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. <wrap important>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).</wrap>

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
    - 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''
    - 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. \\ 
{{:playground:svn-udate.png?400|}}\\ 
Sollten Merge-Konflikte benannt werden, müssen diese bearbeitet werden!
</nodisp>
++++

==== Erzeugen einer Basisstruktur für neue Programmversion ====
<nodisp 2>
++++|
Macht SMV... Er spiegelt die Version in ein neues Verzeichnis. Da die Datenpfade relativ sind, klappt dies.

Für eine manuelle Kopie könnte man wie folgt vorgehen: Bei diesem Prozess soll die aktuelle Doku als Kopie in ein neues Verzeichnis kopiert werden, um später durch weitere Aktualisierungen angepasst zu werden. Die Quelldoku bleibt auch hier parallel hierzu erhalten. Zugleich wäre die Kontrolle auf interne Links obsolet.
  * Zuerst wird das Quellverzeichnis (z. B. Namespace 20176) kopiert und zwischengelagert.
  * Um das neue Verzeichnis zu ‚erzeugen‘, kann der Umbenennungsmodus des Plugins ''move'' auf den Namespace des Quellverzeichnisses angewendet werden. So werden alle Hyperlinks mit umgezogen. Dabei ist die Namenskonvention für die Ansteuerung einer kontextsensitiven Hilfe zu beachten. Beispiel: Versions- und Service Pack Nummer zeichenbereinigt, also 20211 für Version 20.21.1 oder 20220 für Version 20.22.0.
  * Da alle internen Links innerhalb des Namespace liegen, sind anschließend interne Links auf Seiten im übergeordneten Namespace bzw. Root anzupassen, und zwar im Titel, da deren Verweis ja nun auf eine neue Version zeigen wird.
  * Anschließend wird die Sicherungskopie des Quellverzeichnisses wieder eingespielt.
  * Da alle internen Links innerhalb des Namespace liegen, ist anschließend nur ein neuer interner Link auf Seiten im übergeordneten Namespace bzw. Root anzulegen, dessen Verweis (wieder) auf die alte Version zeigt. Ein solches übergeordnetes Verzeichnis ist derzeit Laufwerk ''\\srv-dev\DokuWiki''.
  * Die Startseite start.txt und ggf. sidebar.txt in dem neuen Namespace muss angepasst werden. Ggf. sind weitere Steuerelemente abhängig vom Namespace anzupassen. Ohne die parallele Lagerung bzw. Querverweise zwischen einzelnen Versionen entfällt diese Überlegung bzgl. der sidebar.txt. 
++++
</nodisp>
==== Upgrade DokuWiki ====
++++|
=== Greeboo -> Hogfather ===
<nodisp 2>
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.
</nodisp>
++++
==== Known Bugs/Missed Features ====
++++|
  * **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>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  |
++
    * 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). 

++++
==== Kommandozeilen Werkzeuge ====
<nodisp 2>
++++|
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:

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

oder direkt über den Interpreter aufgerufen werden:

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

=== dwpage.php ===
<nodisp 2>
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
</nodisp>

=== indexer.php ===
<nodisp 2>
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).
FIXME :?: 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 [[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.  
</nodisp>

=== wantedpages.php ===
<nodisp 2>
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
</nodisp>
++++
</nodisp>

====Tuning von DokuWiki zu iX-Wiki ====
++++|
<WRAP important>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.</WRAP>

===Anpassung des Favorite-Icons===
<nodisp 2>
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 16x16 Pixel aufweisen, besser 32x32. 64x64 ergibt keine Qualitätsverbesserung. Ggf. übernimmt SUN aus dem Marketing die Optimierung der Datei. 
<WRAP center round todo 60%>
neues favicon.png ab 01.04.2021? gestellt (s. Meeting am 18.03.2021 DSN, ARR, PSZ)
</WRAP>
</nodisp>

===Anpassung der Fußzeile===
<nodisp 2>
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.
</nodisp>

===Anpassung des Logos===
<nodisp 2>
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.) 
</nodisp>

===Anpassung der Suchinfo===
<nodisp 2>
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.
</nodisp>

===Anpassung des TOC-Titels===
<nodisp 2>
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.
</nodisp>


====Einstellungen für dass iX-Wiki Template Design====
''Admin'' => ''Einstellungen fürs Template Design'' => ''Seitenhintergrund'' \\ 
<nodisp 2>
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.
</nodisp>

===Styles===
<nodisp 2>
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); }
</nodisp>
++++