• Thomas Pollinger
• 20.05.2019
• DE

RD- & PreExecute: Verwendung und Einstellungen

Man kann im Management Server serverseitige Skripte (PHP, JSP, ASP, ASPX u.a.) und für Templates definierte Skript-Dateien in SmartEdit oder der Vorschau ausführen lassen. Der Management Server bietet die Ansätze RDExecute und PreExecute zum Verarbeiten von Skripten auf Seiten beim Publizieren.

---

Hinweis: Dazu werde ich verschiedene Abschitte aus der Online-Hilfe des Management Servers - leicht angepasst bzw. angewandelt - verwenden und die Möglichkeiten bzw. Einstellungen näher erläutern.

---

Serverseitige Skripte in der Vorschau und in SmartEdit

Serverseitige Skripte sind beispielsweise ASP, PHP oder JSP. Eine Ausführung der serverseitigen Skripte ist vorgesehen, um den Redakteuren die auf dem Live-Server benötigten Skripte, bereits in der Vorschau und im SmartEdit unterstützend anzuzeigen. Dies kann durch die technischen Limitierungen der Systemumgebung auch nur mit den nachfolgend geschilderten Voraussetzungen und technischen Einsatzmöglichkeiten durchgeführt werden. Skripte, welche unter diesen Voraussetzungen nicht ausgeführt werden sollten, sind im Template mit der Blockmarkierung Nicht im SmartEdit-Modus zu markieren.

Dazu sind bitte folgende Hinweise und Einschränkungen zu beachten:

• Die Skripte werden in isolierten Sessions verarbeitet, es existieren jeweils eine in sich konsistente Session für den SmartEdit (inklusive Aufgaben und Suche) und für den SmartTree. Bitte auch den Session Timeout beachten.
• Ein Redirect (Client wird über Umleitung informiert) auf interne oder externe Seiten ist unproblematisch.
• Durch die Ausführung serverseitiger Skripte in der Vorschau und im Management Server wird die Darstellungsgeschwindigkeit gemindert. Verzichte daher auf große, umfangreiche und komplexe Skripte.
• Setze keine Skripte ein, welche die Nutzung von Funktionalitäten des Management Server beinhalten oder manipulieren, beispielsweise eigene Zusammenstellungen von Anchor-Elementen. Diese Funktionalitäten können nicht über die Software abgefangen werden und können zu Darstellungsproblemen aus dem Cache für Vorschau und SmartEdit führen. Dies betrifft beispielsweise auch die Manipulation von Inhalten via RQL innerhalb eines Templates durch serverseitige Skripte.
• Der OpenText-Support unterstützt keine Problemanalyse bei serverseitigen Skripten. Die Zusammensetzung der Skripte geschieht in eigener Verantwortung. Stelle sicher, dass die Skripte auch ohne den Management Server funktionsfähig sind und beachte die technischen Limitierungen.
• Formulardaten lassen sich derzeit nicht ohne weiteres mittels GET an eine andere ASP Seite übergeben, da der Management Server zur Übermittlung notwendiger Parameter die gleiche Übermittlungsmethode verwendet.
• Das Redlining ist in ausgeführten Skripten verfügbar. Es wird nach Unterschieden in den entstandenen HTML-Seiten (nicht in den Serverseitigen Skripten) gesucht, die Darstellung von Sonderzeichen und Umlauten ist nur eingeschränkt möglich.
• Externe Skripte sind im Management Server direkt in die Seite einzufügen.
• Für eine Parameterübergabe an aufzurufende Seiten ist zu beachten, dass die vom Management Server selbst verwendeten Parameternamen in den selbst erstellten Seiten nicht verwendet werden dürfen. Das kann zu nicht vorhersagbaren Resultaten führen. Die folgenden Parameternamen sind für den Management Server reserviert:
  • Action, BackAsp,
  • bt... (also alles, was mit 'bt' anfängt),
  • CalledFromRedDot,
  • CancelAsp,
  • EditLinkGuid,
  • EditPageGuid,
  • FromLanguageVariantId,
  • Host, Isolated,
  • LanguageVariantGuid,
  • LngID, Mode,
  • OrderBy,
  • PageGuid,
  • ParentPageGuid,
  • Preview,
  • Project,
  • ProjectGuid,
  • RedDot,
  • SelDay,
  • SelTime,
  • SelYear,
  • ShowLoginMask,
  • StartPageGuid,
  • ToLanguageVariantId,
  • UserId,
  • VersionGuid.

 

Serverseitige Skripte verwenden

Der Management Server erlaubt die Ausführung von serverseitigen Skripten im SmartEdit und in der Vorschau. Auch die korrekte Ausführung von zum Beispiel XML im Browser ist damit möglich.

---

Hinweis: Session-Variablen des Management Server können durch den Skript-Code gegebenenfalls überschrieben werden. Nutze für die Skripte individuelle eigene Session-Namensdeklarationen. Sollen mit diesen Skripten auf dem späteren Live-System Datenbanken abgefragt werden. Dann muss auch bei der Ausführung auf dem Anwendungsserver sichergestellt werden, dass diese Datenbanken genauso erreichbar sind wie auf dem Live-Server.

---

Voraussetzung für die Ausführung der serverseitigen Skripte ist, dass die Dateiendungen auf dem Anwendungsserver in der IIS Anwendung des Management Server korrekt interpretiert werden. Dazu muss also zum Beispiel für ASP oder ASPX die entsprechenden Engines installieren bzw. konfigurieren.

---

Tipp: Prüfe zunächst mit einfachen Test-Dateien die Ausführung der Skripte im Installationsverzeichnis, ohne die Oberfläche des Management Server. Test-Seiten sollten im Installationsverzeichnis auch ohne Management Server gestartet werden können.

Bei fehlerhaften Anzeigen kann man Skript-Codebereiche im Management Server auch ausblenden. Diese werden dann gegebenenfalls nur noch auf dem Live-Server angezeigt.

---

RDExecute und PreExecute

Der Management Server bietet die Ansätze RDExecute und PreExecute zum Verarbeiten von Skripten auf Seiten beim Publizieren.
 

RDExecute

RDExecute verarbeitet stets eine ganze Seite und zeigt die Ergebnisse sofort in SmartEdit und in der Seitenvorschau an. Um sicherzustellen, dass der Code verarbeitet wird, muss man einen Kommentar in den Code einfügen, z. B. unter dem Tag <body>:

<!--RDExecute=[*]-->

Hierbei entspricht [*] der Dateiendung für die Ausführung des Codes.

Management Server erkennt den Kommentar und filtert die Dateiendung heraus. Für die Darstellung wird eine statische Datei mit der im Kommentar angegebenen Endung abgelegt und zur Ausführung gebracht.

---

Hinweis: Bei Kommentaren ist die Groß- und Kleinschreibung zu beachten. <!--rdexecute=[*]--> verursacht einen Fehler.

---

Um ASP oder PHP auszuführen, sehen die entsprechenden Kommentare wie folgt aus:

<!--RDExecute=ASP-->

oder

<!--RDExecute=PHP-->

PreExecute

PreExecute wird in Active Templates verwendet, die eine Verarbeitung von Skriptcode vor Publizierung einer Seite und danach eine Publizierung des Ergebnisses des verarbeiteten Skripts ermöglichen. Dies ist beispielsweise hilfreich, wenn man Seiten mit Datenbankzugriff hat, wobei Skripte nicht bei jedem Aufrufen einer Seite in SmartEdit oder in der Seitenvorschau verarbeitet werden sollten. Um die PreExecute-Skripte in Active Templates zu verwenden, muss man eine Blockmarkierung Pre-Execute Bereich in ein Template einer Content-Klasse einfügen. 

---

Hinweis: Skripte über RDExecute und PreExecute ausführen: Als Standardeinstellung werden alle Skripte, die über RDExecute oder PreExecute aufgerufen werden, im Unterverzeichnis <Management Server Installationsverzeichnis>ASP\RedDotTemp\SessionID> ausgeführt. Diese Einstellung kann in den Projekteinstellungen geändert werden und ist auch sinnvoll wenn man z.B. einen eigenen Appikationspool einsetzen möchte. Dazu jedoch mehr im nächsten Artikel ;)

---

Active Templates

Active Templates sind Templates, über die Skript-Code bereits vor dem Publizieren einer Seite ausgeführt werden kann. Publiziert wird dann das ausgeführte Ergebnis des Skript-Codes. Für die Kennzeichnung des auszuführenden Skript-Codes steht im Template die Blockmarkierung Pre-Execute Bereich zur Verfügung.

So verwendet man Active Templates:

1. Aktiviere die Checkbox Active Templates zulassen, in den Allgemeinen Einstellungen des Projektes.
   
2. Im Feld Wählbare Suffixe gebt man an, welcher Skript-Code zugelassen werden soll (z. B. PHP, JSP oder ASP). Die angegebenen Suffixe werden im Dialog Projektvariante bearbeiten in der Liste Active Templates ausführen als zur Auswahl angeboten. Mit dieser Auswahl legt man fest, welcher Skript-Code in der jeweiligen Projektvariante verwendet werden darf/soll.
3. In dem Feld Cache-Zeit geben Sie an, welche Cache-Verweildauer für das ausgeführte Ergebnis des Skript-Codes zur Verfügung stehen soll. Das Ergebnis eines Skriptes wird dann entsprechend der eingetragenen Verweildauer im Cache vorgehalten. Lesen Sie hierzu auch die untenstehenden Informationen.
4. Klicke nun auf OK.
5. Bearbeite nun die Projektvarianten, in denen der Skriptcode ausgeführt werden soll, und bestimme den zu verwendenden Skript-Code. Beachte, dass umfangreiche Skripte die Auslieferung erheblich verzögern können.
   
6. Erstelle nun eine Content-Klasse mit einem Template, und füge den Skript-Code nach feier Wahl ein.
    

Blockmarkierung Pre-Execute Bereich

Die Blockmarkierung Pre-Execute Bereich benötigt man für die Verwendung von Active Templates. Active Templates sind Templates, über die Skript-Code bereits vor dem Publizieren einer Seite ausgeführt werden kann. Publiziert wird dann das ausgeführte Ergebnis des Skript-Codes. Über die Blockmarkierung Pre-Execute Bereich wird der auszuführende Skript-Code gekennzeichnet.

Um eine Blockmarkierung Pre-Execute Bereich einzufügen:

• Markiere den auszuführenden Skript-Code.
• Wähle aus der Liste Blockmarkierungen den Eintrag Pre-Execute Bereich aus. Der markierte Code erhält ein einleitendes und ein abschließendes <IoRangePreExecute>-Tag.

Beispiel für ein Active Template:

<!IoRangeList>
    <a href="<%List%>"><%Headline%></a>
    <!IoRangePreExecute>
        <% If DateDiff ("d", Now, "<%DateCreative%>") > - 7 Then %>
            <img src="<%Image%>">
        <% end if %>
    <!/IoRangePreExecute>
    <br/>
<!/IoRangeList>

Das Listen-Element <%List%>, das Überschrifts-Element <%Headline%> und das Info-Element <%DateCreate%> sind aus den Seiten der Liste hochgereichte Elemente. Der Skript-Code dieses Beispiels fügt hinter jede Überschrift ein Bild ein (<%new_image%>), wenn der Artikel in den letzten sieben Tagen erstellt wurde. Publiziert werden statische Seiten, in denen der Skript-Code bereits ausgeführt wurde. Für diesen Skript-Code bestimmt man in den jeweiligen Dialogfeldern Einstellungen bearbeiten und Projektvariante bearbeiten die Dateiendung asp.

---

Hinweise:

Cache-Time effizient verwenden
Wenn man die Cache-Zeit auf 0 festlegt, wird der Skript-Code nicht zwischengespeichert. Wenn man den Cache-Wert höher als 0 festlegt, prüft der Management Server, wann der Skript-Code zuletzt ausgeführt wurde. Je nach angegebenem Wert wird einer der folgenden Prozesse gestartet:

• Wenn die Zeitdauer den angegebenen Wert übersteigt, wird das Skript erneut ausgeführt.
• Wenn die Zeitdauer kürzer als der angegebene Wert ist, wird der Skript-Code auf Änderungen geprüft. Liegen keine Änderungen vor, wird das zwischengespeicherte Skript-Ergebnis verwendet. Liegen Änderungen vor, wird das Skript erneut ausgeführt.

Um die Cache-Zeit für PreExecute-Skripte effektiv zu nutzen, vermeide folgendes:

• Verwenden von Elementen, die sich ständig ändern, z. B. das Info-Element Seite: Datum/Uhrzeit des Seitenaufbaus, oder die vom aktuellen Benutzer abhängig sind, z. B. das Info-Element Session-Objekte.
• Verwenden von Blockmarkierungen, z. B. SmartEdit-Modus oder Nicht im SmartEdit-Modus, um Teile des Skript-Codes auszublenden oder anzuzeigen.
• Verlinken von Elementen
   

RDExecute und PreExecute in einem Template

Man kann ebenso über RDExecute bestimmen, dass Skript-Code erst auf dem Live-Server ausgeführt werden soll. RDExecute und PreExecute können auch in einem einzelnen Template verwendet werden. Skripte, die in RDExecute ausgeführt werden sollen, müssen jedoch außerhalb der Blockmarkierungen Pre-Execute Bereich platziert werden.

Für die Ausführung der PreExecute-Seite wird eine temporäre Datei im ASP-Verzeichnis erstellt. Nach dem Abschluss der Ausführung wird diese Datei sofort gelöscht. Das Löschen der Datei kann man unterdrücken, indem der Wert 28 in dem Eintrag flags setzen, welcher in der Datei RDSERVER.INI in dem Abschnitt [Defaults] zu finden ist. Dieses Attribut ist ein binäres Feld und muss daher bitweise festgelegt werden:

2⁸ (+256) = Stoppt das Löschen der temporären ASP-Verzeichnisdatei

In der RDServer.ini muß man noch einen weiteren Eintrag erstellen:

[DEFAULTS]
preexecutepath=c:\temp

Dort werden dann die Dateien aus der Publizierung hin kopiert nach der Ausführung.

---

Konfiguration und Einstellungen

Es gibt im Management Server mehrere Stellen, die sich auf die Arbeitsweise der RDExecute und PreExecute Skripte auswirken können:
 

Server Manager

Im Server Manager gibt es die Möglichkeit sich die Verbindungsdaten anzeigen zu lassen. Dort steht eine wichtige Einstellung, die s.g. Host-URL (PreExecute und RDExecute).

Verbindungsdaten anzeigen:

Host-URL (PreExecute und RDExecute)
Der Name des Host-Headers (z. B. https://<Servername>/cms), über den die virtuelle Website anzusprechen ist, unter welcher Management Server verfügbar ist. Der Name der Host URL wird für interne IIS-Aufrufe bei RDExecute- und PreExecute-Konstruktionen verwendet. Man ändert ihn z. B., wenn als virtuelle Website eine andere als die Standard-Website verwendet werden soll oder wenn aufgrund der Netzwerkkonfiguration bei internen Aufrufen ein abweichender Servername verwendet werden muss.

Allgemeine Einstellungen:

RDExecute-Timeout
Geb hier eine Zeitdauer in Sekunden ein. Der Timeout greift bei der Ausführung von serverseitigem Scriptcode. Standardmäßig sind 10 Sekunden eingestellt. Wird ein Wert kleiner 10 Sekunden eingegeben, wird automatisch der Wert 10 gespeichert.

PreExecute-Timeout
Geb hier eine Zeitdauer in Sekunden ein. Der Timeout greift bei der Ausführung von Active Templates. Standardmäßig sind 10 Sekunden eingestellt. Wird ein Wert kleiner 10 Sekunden eingegeben, wird automatisch der Wert 10 gespeichert.
 

.NET-Ordner verwenden:

Man wählt diesen Typ für Dateien, die immer auf dem Publizierungsziel verfügbar sein sollen, beispielsweise Konfigurationsdateien oder Assemblies in .NET-Projekten.
Zur Vorschau wird der Inhalt dieses .NET-Ordners in einen physischen Pfad publiziert, der im Projekt RDExecute und in den Einstellungen PreExecute definiert ist. Wenn die Projektvarianteneigenschaft Dateien aus .NET-Ordner publizieren aktiviert ist, wird der gesamte Inhalt des .NET-Ordners in den Publizierungsordner am Publizierungsziel publiziert, der für diesen .NET-Ordner konfiguriert ist.
Ordner von diesem Typ können nicht Inhalts-Elementen zugewiesen werden. Dateien in diesem Ordner können nicht direkt referenziert werden. Sofern richtig konfiguriert, wird der gesamte Inhalt dieses Ordners zur Vorschau und auf dem Publizierungsziel verfügbar gemacht.

Physischen Pfad und IIS Anwendung angeben
Geb hier den physischen Pfad und die IIS Anwendung zur Ausführung von RDExecute- und PreExecute-Seiten wie z. B. ASPX-Seiten an.
(Unter: SmartTree > Start > Projekteinstellungen bearbeiten > Projekt > Aktion: Allgemeine Einstellungen > Einstellungen bearbeiten: RDExecute und PreExecute Einstellungen)
 

IIS Anwendung als Präfix hinzufügen

Steht nur zur Verfügung, wenn die Option Platzhalter für Seite in Container einsetzen aktiviert ist. Aktiviere diese Checkbox, um den vollständigen Referenzpfad zur separaten Datei auf der Seite, die den Container enthält, einzufügen. Anderenfalls wird nur der Dateiname eingefügt.

Wenn keine bestimmten Einstellungen für RDExecute oder PreExecute in den Projekteinstellungen definiert sind, bezieht sich der Pfad auf die Datei im Ordner RedDotTemp. Anderenfalls bezieht er sich auf die angegebene IIS-Anwendung. 
 

Allgemeine Projekteinstellungen

RDExecute und PreExecute Einstellungen
Man kann einstellen, dass Skripte, die über RDExecute oder PreExecute aufgerufen werden, in einer IIS Anwendung ausgeführt werden.

Keine Byte Order Mark (BOM) schreiben
Aktiviere diese Checkbox, wenn keine Byte Order Mark geschrieben werden soll. Eine Byte Order Mark zeigt, wie der Dateiinhalt codiert ist. BOMs werden nur für Unicode-Dateien verwendet. Es gibt verschiedene Unicode-Dateiformate, wie Unicode little-endian, Unicode big-endian oder UTF-8. BOMs unterstützen die verarbeitenden Anwendung beim Kodieren des Inhalts. Gerade UTF-8 codierte Unicode-Dateien können mit einfachen uncodierten ASCII-Dateien verwechselt werden.

Physischer Pfad
Geben Sie den physischen Pfad zu dem gewünschten Verzeichnis an (z. B. C:\Pfad)

IIS Anwendung
Geb hier den virtuellen Pfad zur IIS-Anwendung ein (z. B. /PfadZuMeinerAnwendung). Die IIS-Anwendung muss nicht zwingend untergeordnet zur Management Server-Anwendung sein. Nach jeder Änderung des physischen Pfads oder der IIS-Anwendung muss die Management Server-Anwendung recycelt werden, damit die Änderungen übernommen werden.
 

Main.config

Konfigurieren des Schutzes vor Pfadmanipulationen
Der Management Server bietet einen Mechanismus, um unbefugten Zugriff auf das lokale Dateisystem zu verhindern.

Whitelisting
Jedes Modul muss nur auf die Informationen und Ressourcen zugreifen können, die für seinen legitimen Zweck erforderlich sind. Daher muss jeder Whitelist-Eintrag Informationen über die Art der Daten enthalten, auf die zugegriffen werden soll. Der Management Server bietet den folgenden Satz konfigurierbarer Typen:

• RdExecute: Dient zum Zugriff auf Rd-/PreExecute-relevante Daten.

 

Verwendung des vorkonfigurierten PreExecute Application Pools

Wenn der Management Server installiert ist, wird ein separater Anwendungspool (OpenTextWsmPreExecuteAppPool) und eine Anwendung für PreExecute erstellt, um zu verhindern, dass der Management Server stoppt, wenn Skriptfehler auftreten, die auf in aktiven Vorlagen definierten Skripten basieren. Um diese vorkonfigurierte Anwendung zu verwenden, ändere die Einstellungen für Physischer Pfad und IIS-Anwendung in den allgemeinen Einstellungen des Management Server-Projekts wie folgt:

• Physischer Pfad: <Management Server install_dir>\Web\PreExecute
• IIS Applikation: /PreExecute

Wenn man seine eigenen Einstellungen für den Anwendungspool und die Anwendung verwenden möchte, empfiehlt OpenText, einen neuen Anwendungspool und eine neue Anwendung anzulegen, anstatt die vorkonfigurierten zu bearbeiten.
 

RDServer.ini

Das Löschen der Datei kann man unterdrücken, indem der Wert 28 in dem Eintrag flags setzen, welcher in der Datei RDSERVER.INI in dem Abschnitt [Defaults] zu finden ist. Dieses Attribut ist ein binäres Feld und muss daher bitweise festgelegt werden:

2⁸ (+256) = Stoppt das Löschen der temporären ASP-Verzeichnisdatei

In der RDServer.ini muß man noch einen weiteren Eintrag erstellen:

[DEFAULTS]
preexecutepath=c:\temp

Dort werden dann die Dateien aus der Publizierung hin kopiert nach der Ausführung. Ein anderer Tipp ist, im IIS das Failed Request Tracing Feature zu aktivieren. Damit bekommt man detaillierte Fehlermeldungen. Jedoch hat man noch immer nicht den Source Code und damit Probleme, die fehlerhafte Zeile im Code zu finden. Manchmal genügt das aber dennoch.

---

Tipp: Das Format der Dateinamen im o.g. Ordner stetzt sich wie folgt zusammen: Die erste GUID ist zufällig, die andere ist die Seiten-GUID, sprich PreExecute_Publisher_Random-GUID_Page-GUID.PreExecuteExtension. Die Random-GUID soll verhindern, dass verschiedene Projekt-Varianten die Dateien gegenseitig überschreiben.

---

Hinweis: All diese Einstellungen hängen zusammen oder beinflussen sich gegenseitig, wenn man etwas nicht korrekt konfiguriert hat.

---

Zusammenfassung

Jetzt nochmals die wichtigsten Schritte und Unterschiede in einer Zusammenfassung:

• RDExecute:
  • Ist primär für den SmartEdit- (Mode 1) und Seitenvorschau-Modus (Mode 0) gedacht.
  • Scope ist immer die komplette Seite und wirde während der Laufzeit ausgeführt.
  • Kann nicht für die Publizierung (Mode 2) genutzt werden.
  • Es kann immer nur eine Skript-Sprache zeitgleich innerhalb einer Seite verwendet werden.
  • Innerhalb von Pre-Execute-Blockmarkierungen dürfen schreibenden (ändernden) RQL-Aufrufe eingesetzt werden.
• PreExecute (Active Templating):
  • Kommt primär bei der Publizierung der Seite zum Einsatz.
  • Jeder PreExecute-Block wird vorher ausgeführt und das Ergebis in die zu publizierende Seite geschrieben.
  • PreExecute-Blöcke können gecached werden.
  • Es können unterschiedliche Skript-Sprachen je PreExecute-Block innerhalb zur gleichen Zeit in einer Seite verwendet werden.
  • Innerhalb von Pre-Execute-Blockmarkierungen dürfen keine schreibenden (ändernden) RQL-Aufrufe eingesetzt werden, da dies zu Fehlern führen kann.
• Einstellungen
  • Active Templating wird in den allgemeinen Projekteinstellungen, je Projekt individuell, eingestellt.
  • Active Templating muss dann noch je Projekt-Variante explizit erlaubt und konfiguriert werden.
  • Man kann in der RDServer.ini das sofortige Löschen der Skriptausführung unterbinden.
  • Es werden alle temporären Dateien per Default im Pfad ASP\RedDotTemp\SessionID> abgelegt.
  • Man kann den temporäen Pfad anpassen und auch einen eigenen Applikations-Pool einrichten (dazu im nächsten Artikel mehr).
• Nutzung und Einschränkungen
  • Es gibt feste Schlüsselworte, welche nicht genutzt werden dürfen.
  • Es muss in jeder Content-Klasse indivduell der RDExecute-Tag oder PreExecute-Block definiert werden.
  • Skripte welche komplex oder eine lange Laufzeit haben sollten vermieden werden.
  • Durch massiven Einsatz von RDExecute und PreExecute kann die Performance des Systems beeinflusst werden.
  • Vermeide die Verwendung von Elementen, welche sich permanent ändern, z.B. Datum/Uhrzeit per Elementtyp Info. Dies unterbindet das Caching und führt zu längeren Wartezeiten.

 

Im nächsten Artikel beleuchten wir das Thema: PreExecute: Eigener AppPool - bis dahin viel Spaß beim ausprobieren, tunen oder konfigurieren. ;)

 

Quellen-Nachweise:

• Online-Hilfe (Version 16.0.3):
  • Handbuch: Asset Manager / Kapitel: Ordner erstellen oder bearbeiten (2.4.1), 
  • Handbuch: SmartTree / Kapitel: Einstellungen bearbeiten (3.1.1), Ordner erstellen oder bearbeiten (3.4.1), 
  • Handbuch: Content-Klassen / Kapitel: Templates erstellen/Eigenschaften bearbeiten (5.8.1), Skripte verwenden (6.3), Serverseitige Skripte verwenden (6.3.2), Active Templates (6.3.5)
  • Handbuch: Server Manager / Kapitel: Verbindungsdaten anzeigen (3.3.1)
  • Handbuch: Installation / Kapitel: Servereinstellungen und SSL konfigurieren (2.5.15), Konfigurieren des Schutzes vor Pfadmanipulationen (2.7.9), 

---

Über den Autor: