====== Redaktionsleitfaden im iX-Wiki ======
<nodisp 2>
<WRAP tip>Der Playground-Namespace ist nicht für die Veröffentlichung auf dem Server der CREM SOLUTIONS vorgesehen! Zur Ansicht von Details müssen Sie sich im iX-Wiki anmelden.</WRAP>
<WRAP important>Der Playground-Namespace ist nicht für die Veröffentlichung auf dem Server der CREM SOLUTIONS vorgesehen!</WRAP>
<WRAP todo> **Interne Kommentare, Verweise auf todos, fixmes und Vorschläge**
^wer^wo (Links)^was^status^
|...| [[#comment000]] | Mini-todo-Liste (ToDos und Fixmes innerhalb des Playground-Namespaces) mit Links zu Markern, wo sich ein todo/fixme befindet. \\ Der Marker auf der Zielseite wird so gebildet:\\ ''%%<wrap #comment000></wrap>%%'' (mit entsprechender laufender Nummer pro Seite) | Muster |
</WRAP>
</nodisp>

=== gesuchte Seiten - broken links === 
<nodisp 2>
 ~~ORPHANSWANTED:wanted~~

Verwaiste Seiten: siehe [[playground:start#tote_interne_links|Detailinfos zu toten internen Links]]
</nodisp>

===== iX-Wiki in Bearbeitung durch DEV / PM=====
<nodisp 2>
^ix-Wiki-Link^Thema^DEV^PM^Sybille^Wiki-Startdatum^Infos^
|__[[playground:zahlungstoleranzen|Zahlungstoleranzen]]__|Buchhaltung|tji|opp|20210701004|05.08.2021|Featurepaket 20.21| 
| ix-Scheduler | :?: | :?: | :?: | :?: | :?: | :?: |
| ProjektX | :?: | :?: | :?: | :?: | :?: | :?: |
</nodisp>

===== Muster =====
<nodisp 2>
Wir haben eine separate __[[playground:muster|Muster-Seite]]__ im Namespace Playground aufgebaut. Die Redaktion bildet für ein neues iX-Wiki-Projekt aus dem Muster eine neue Seite im Playground. Diese wird dann als neue Zeile in der Tabelle im Abschnitt **iX-Wiki in Bearbeitung durch DEV/PM** verlinkt und dann an die beteiligten Autoren kommuniziert. Diese Projektseite enthält die grundlegenden Strukturen, welche initial vom jeweiligen Bearbeiter ergänzt und bei Bedarf erweitert werden können. Letztere werden nach weitestgehender/abschließender redaktionellen Bearbeitung dann in die jeweilige Branchversion verschoben. Die verwendeten Links werden hierbei berücksichtigt. Developer oder Produktmanager können sich daher in der Anfangsphase auf die inhaltlichen Aspekte des Projekts konzentrieren und ''ohne Manschetten'' im Playground editieren und auch kommentieren. Eine Endkontrolle sollte nach der Verschiebung erfolgen. Hier sind dann nur noch kleinere Korrekturen zu erwarten.
<wrap #comment001></wrap><WRAP center round todo 60%>
> ARR: Vorschlag => Das wrap-Menü bietet auch eine **Zu-Erledigen-Box** an. Diese sollte markant genug sein, da sie so gar nicht in unser CI passt ;-). 
> FIXME-tags können an konkreten Punkten eingesetzt werden.
>> DSN: TOP! Machen wir so. 
> ARR: Solche tags können in den Quelltexten im page-Verzeichnis notfalls auch mit Total Commander gesucht werden, das der bei Bedarf im Hintergrund.
> Inhaltlich lassen sich damit Kommentare vom eigentlichen Wiki-Inhalt in der Erstellungsphase besser abgrenzen
</WRAP>
</nodisp>

====== Hilfreiches Wissen rund um Wiki und iX-Wiki ====== 
===== Fragestellung zur Startseite - mehrere Versionen des Wikis parallel? =====
<nodisp 2>
++++|
z. B. \\ 
<nowiki>[[20191:start|20.19.1]]   [[20192:start|20.19.2]]   [[2020:start|20.20]]</nowiki>

<nowiki>2020:start|zu Namespace 2020__ Klärungsbedarf Namespacemanagement/Hyperlinks/Workflow bei Versionswechsel</nowiki>

Antwort: Eine solche übergeordnete Seite werden wir in der Kundenversion **nicht** anbieten, wir steigen in der jeweiligen Version dann direkt auf der aktuellen Versionsseite ein. Abhängig von der Programmversion wird die jeweilige Hilfeseite geöffnet. Die trunk-Version nutzt eine vereinfachte Adressierung, zu der dann intern ein Redirekt auf die Versionsseite erfolgt: => https://wiki.crem-solutions.de/ Dies unterstützt die Einrichtung eines dauerhaft sinnvollen Webseitenlesezeichen im Browser des Kundens.

Mit der [[http://srv-dev/xampp/DokuWiki/Version.20.21.1/doku.php|Branchvariante]] besteht eine parallele Variante <wrap important>nur im Intranet</wrap>. Die Branchversion halten wir bis zu einem bestimmten Zeitpunkt mit der [[http://srv-dev/xampp/DokuWiki/20.21.0/doku.php|Trunk-Version]] parallel und werden sie dann gezielt weiterentwickeln. Hierzu nutzen wir eine Versorgung via TortoiseSVN und mergen nach bestimmten Regeln. Die Branchversion des iX-Wiki wird in der Aufbauphase **nicht** online gestellt. Dies ist der jeweiligen Trunkversion vorbehalten.

Z. B. ist => [[http://wiki.crem-solutions.de/Version.20.21.0|iX-Wiki Onlineversion 20.21.0]] nur für den exklusiven Teil der Kunden relevant, welche schon die Version 20.21.0 einsetzen, während [[http://wiki.crem-solutions.de/Version.20.20.0|iX-Wiki Onlineversion 20.20.0]] allen Kunden mit 20.20.0 bereitgestellt wird. (Stand dieser Konstellation: 01.08.2021). Wer den Pfad kennt, kann natürlich in seinem Browser auch eine andere Onlinevariante des iX-Wiki ansteuern, dies wird technisch nicht unterbunden. 

Redaktionell arbeiten wir z. B. Neuerungen in 20.21.0 ein. Nur absolute Basics werden in Vorversionen, z. B. in 20.20.0 angepasst. Diese werden dann über 20.20.2, nach 20.20.3 und höher durchgemerged. Falls man in 20.21.0 Anpassungen vornimmt, betreffen die per merge auch 20.21.1, nicht jedoch 20.20er-Versionen! Durch Veröffentlichung des Servicepack 1 zu Version 20.21 Ende Juni 2021 wurde die Version 20.21.1 zur neuen Trunk-Version und die neue Branchversion 20.21.1 wurde eingerichtet. Optional: Eine Angabe der Kalenderwoche nach der Programmversion (letzer Upload von KW...) auf der Startseite könnte dem Anwender helfen, zu entscheiden, welche Informationen ggf. zusätzlich per Patchnotes zu berücksichtigen sind, wenn er eine aktuellere Version einsetzt. 
++++
</nodisp>

====Welche iX-Wiki-Dateien sollten trunk/branch-spezifisch sein?====
<nodisp 2>
  * Indexverzeichnis data\index => Index für Suchfunktionen in iX-Wiki 
  * 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]] redaktionell geschlossen
  * [[http://wiki.crem-solutions.de/Version.20.21.0|iX-Wiki Onlineversion 20.21.0]] redaktionell geschlossen
  * [[http://wiki.crem-solutions.de/Version.20.21.1|iX-Wiki Onlineversion 20.21.1]] redaktionell geschlossen
  * [[http://wiki.crem-solutions.de/Version.20.21.2|iX-Wiki Onlineversion 20.21.2]] redaktionell geschlossen
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>

==== Einbinden von Video ====
<nodisp 2>
Noch Zukunftsmusik, aber denkbar... ich schlage vor, Minivideos nur als {{ living_bug_monitori.mp4?linkonly |Link}}, also nicht eingebettet zu realisieren. Später dazu ggf. mehr.
</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.

==== 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 der Volltextsuche neu aufgebaut werden (s. a. searchindex-Plugin). 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 ====
++++|
===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>

===Anpassung des Logos===
<nodisp 2>
Das Logo (links oben) wird über den Medien-Manager in das System kopiert. Ist das Logo unter 500 Pixel breit, wird bei den meisten Bildschirmeinstellungen der Schriftzug durch die Bindestrichkombination aufgeteilt :-(  . war ein 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 vollständig redaktionell anpassbar. :-)\\    Aktuell: SpaceWell-Logo
<WRAP center round todo 60%>
Neues Cremsolutions-Logo ab April 2021. Das zugrundeliegende Logo wird vom Marketing zur Verfügung gestellt (s. Meeting am 18.03.2021 DSN, ARR, PSZ)
</WRAP>
</nodisp>

===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.
 
Nachtrag 05-06-2020 ARR: Anpassung mit Datenschutz, Impressum, Weblink zur Spacewell-Hauptseite und Mail-To zu einer noch zu erstellenden Doku-Mailadresse. Datenschutz auf Webseite muss bzgl. Wiki ergänzt werden (temp. Session-Cookie) – hierzu ist Philip Spitz informiert.
</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>
++++