Release Notes

Es wurden weitere Verbesserungen durchgeführt, um die Stabilität des Systems bei einem Modul-Update im laufenden Betrieb zu erhöhen. Entsprechende Updates können nun in den meisten Fällen durchgeführt werden, ohne dass der FirstSpirit-Server neu gestartet werden muss.

Hinweis: Die erhöhte Stabilität des Systems wurde dadurch erreicht, dass vorhandene Modulressourcen, die außerhalb des Moduls in Benutzung sind, weiterhin erreichbar bleiben.
Wenn z. B. die Klassen eines Moduls, das aktualisiert wird, von dem Service eines anderen Moduls genutzt werden, dann sollte dieser Service anschließend neu gestartet werden.

Hinweis: Nur nach einem Server-Neustart ist sicher gewährleistet, dass keine Ressourcen aus alten Modul-Versionen mehr verwendet werden. Es wird weiterhin empfohlen, nach einem Modul-Update den Server neu zu starten.

Mit dem aktuellen FirstSpirit-Release werden die Inhalte der FirstSpirit-Jar-Dateien mit einem neuen Zertifikat signiert. Eine Aktualisierung des FirstSpirit-Servers ist nicht erforderlich.

Gelöschte Seiten können im FirstSpirit ContentCreator jetzt über das Statusmenü wiederhergestellt werden.

Dazu muss zunächst die gelöschte Seite in der Projekthistorie gesucht werden. Mit einem Klick auf den entsprechenden Eintrag wird die Seite in dem Zustand angezeigt, in dem sie gelöscht wurde.
Mit einem Klick auf den Menüeintrag „Version wiederherstellen“ im Statusmenü

kann die Seite wiederhergestellt werden.
Es werden sowohl die Seite sowie auch der Menüpunkt wiederhergestellt (soweit ein Menüpunkt vorhanden war).

In Kombination mit „BasicWorkflows“ (Moduldatei basicworkflows.fsm) kann es beim Wiederherstellen zu Problemen kommen.

Beim Import neuer und bestehender Aufträge über die Funktionalität „Externe Synchronisierung“ kann jetzt der Aktivitätsstatus der Aufträge (ScheduleEntries) aus dem Quellprojekt in die Zielprojekte übernommen werden.

Der Aktivitätsstatus kann per Aufruf über das Kommandozeilenwerkzeug „FSDevTools“ (fs-cli) oder per Aufruf über die FirstSpirit-Developer-API gesteuert werden.

Aufruf über das Kommandozeilenwerkzeug FSDevTools (fs-cli):

Über FSDevTools wird der Aufruf über den Parameter --import-schedule-entry-active-state gesteuert.

Beispiel:

D:\fs-cli\bin> fs-cli -h example.com [connectionparameters] import 
--import-schedule-entry-active-state

Ist der Parameter beim Aufruf gesetzt, wird der Aktivitätsstatus neuer und bestehender Aufträge aus dem Quellprojekt in die Zielprojekte übernommen. Für bestehende Aufträge wird dabei ggf. der Wert im Zielprojekt durch den Wert aus dem Quellprojekt überschrieben.

Ist der Parameter nicht gesetzt, wird beim Import von neuen Aufträgen der Aktivitätsstatus standardmäßig auf inaktiv (active=false) gesetzt. Bestehende Aufträge werden in den Zielprojekten unverändert beibehalten.

Aufruf über die FirstSpirit Developer-API:

Über die neue Methode setImportScheduleEntryActiveState(boolean) des Interfaces ImportOperation (FirstSpirit Developer-API,
Package de.espirit.firstspirit.store.access.nexport.operations), wird der Aktivitätsstatus der Aufträge in den Zielprojekten gesteuert.

Mögliche Werte:

• Standardfall, false: Ist der Wert false gesetzt bzw. wird die Methode nicht aufgerufen (Standardfall), wird beim Import von neuen Aufträgen der Aktivitätsstatus standardmäßig auf inaktiv (active=false) gesetzt. Bestehende Aufträge werden in den Zielprojekten unverändert beibehalten.
• true: Ist der Wert true gesetzt, wird der Aktivitätsstatus neuer und bestehender Aufträge aus dem Quellprojekt in die Zielprojekte übernommen. Für bestehende Aufträge wird dabei ggf. der Wert im Zielprojekt durch den Wert aus dem Quellprojekt überschrieben.

Beispiel:

import de.espirit.firstspirit.agency.OperationAgent;
import de.espirit.firstspirit.store.access.nexport.operations.ImportOperation;
import de.espirit.firstspirit.io.FileSystemsAgent;

importOp = 
context.requireSpecialist(OperationAgent.TYPE).getOperation(ImportOperation.TYPE);
fileSystem = 
context.requireSpecialist(FileSystemsAgent.TYPE).getOSFileSystem("c:/fs-cli/exam/");
importOp.setImportScheduleEntryActiveState(true);
importOp.perform(fileSystem);

Weiterführende Informationen:

• Interface ImportOperation (FirstSpirit Developer-API,
  Package de.espirit.firstspirit.store.access.nexport.operations)
• Import über FSDevTools

Viele Browser schränken seit Anfang des Jahres aus Sicherheits- und Datenschutzgründen Cookies von Drittanbietern („Third-Party-Cookies“, „Cross site“) ein: Konnten Cookies bis dahin standardmäßig im Third-Party-Kontext genutzt werden, muss dazu jetzt das Attribut SameSite=None explizit gesetzt werden. Cookies ohne SameSite-Attribut erlauben keine Nutzung im Third-Party-Kontext mehr.
SameSite ist ein Cookie-Attribut, das verhindern soll, dass Cookies bei sogenannten „Cross-Site Requests“ automatisch vom Browser mitgesendet werden und bietet damit einen Schutz vor Cross-Site-Request-Forgery (CSRF). Darüber hinaus ermöglicht das Attribut eine Definition, welche Cookies in welchem Kontext ausgelesen werden können sollen.

Das aktuelle Release reagiert auf diese Anforderung für das MicroApp Framework: Das MicroApp Framework nutzt Cookies für eine Kommunikation beispielsweise zwischen MicroApps und FragmentCreator. Ohne das Attribut SameSite=None kann es zu Problemen kommen, wenn die REST-API verwendet werden soll (beispielsweise für die Integration von kundenspezifischen MicroApps), diese aber auf einer anderen Domain liegt als die, die der Nutzer gerade im Browser geöffnet hat.

So kann jetzt für das MicroApp Framework das Attribut SameSite des CSRF-Token gesetzt werden, und zwar über den Parameter

cxt.platform.csrf-samesite

in der Datei web.xml des Moduls „FragmentCreator“ bzw. in der Datei cxt-fragment-creator.properties.

Standardmäßig ist der Wert des Attributs Unset, also

cxt.platform.csrf-samesite=Unset

Mit dieser Konfiguration wird das Attribut für das Cross-Site-Cookie nicht gesetzt. Dies entspricht dem bisherigen Verhalten bzw. dem Zustand, wenn cxt.platform.csrf-samesite nicht definiert ist.

Damit das MicroApp Framework auch bei Verwendung der REST-API vollumfänglich genutzt werden kann, muss einer der folgenden Werte gesetzt werden:

• None: War bisher kein Wert angegeben, hat der Browser dieses automatisch als „Third-Party-Cookie“ erkannt. Damit konnten User beispielsweise über verschiedene Webseiten hinweg identifiziert werden. Auch das MicroApp Framework nutzt diese Funktionalität stellenweise.
  Damit dieses Verhalten weiterhin möglich ist (z. B. mit Google Chrome ab Version 80), muss jetzt ausdrücklich das Attribut SameSite=None gesetzt werden.
  Wichtig: SameSite=None erfordert ein „Secure“-Flag. Dieses definiert, dass ein Cookie immer über eine sichere HTTPS-Verbindung gesendet wird.
• Lax: Dieser Modus bietet ein angemessenes Verhältnis zwischen Sicherheit und Benutzerfreundlichkeit für Websites: Das Cookie wird nur dann gesendet, wenn die URL im Browser mit der hinterlegten URL im Cookie übereinstimmt. Aber es sind auch Cross-Site-Requests möglich, wenn eine Navigation auf Top-Level erfolgt und sichere HTTP-Methoden verwendet werden.
• Strict: Das Cookie wird nur dann gesendet, wenn die URL im Browser mit der hinterlegten URL im Cookie übereinstimmt. Es werden dann beispielsweise keine Login-Informationen an andere Webseiten weitergegeben, auch dann nicht, wenn der User einem Link von einer anderen Seite oder aus einer E-Mail folgt. Dieser Modus bietet einen guten Schutz vor Cross-Site-Request-Forgery und ist z. B. für Webseiten mit sensiblen Inhalten sinnvoll.

Folgende Modul-Versionen für „FirstSpirit Content Experience Tools“ werden von FirstSpirit 2020-08 unterstützt:

* Diese Module benötigen ab dieser Version FirstSpirit 2020-03 oder höher.

Zum Hochladen und zur Auswahl von Medien im FragmentCreator wird die Komponente „FS_INDEX“ mit Modul „Media DAP“ verwendet. Mit dem aktuellen Release wurden einige Verbesserungen bei der Bedienung durch den User vorgenommen:

Maximale Dateigröße
Bisher war ein Upload auf eine Dateigröße bis 10 MB limitiert. Fehlermeldung in der Browser-Konsole: CxtElement request firstspirit-media-upload-widget/uploadMedia failed: 500.
Mit dem aktuellen Release beträgt die maximale Dateigröße, die für einen Upload erlaubt ist, standardmäßig 64 MB.
Werden Medien in den entsprechenden Dialog gedropped, die größer sind als die konfigurierten Werte, wird dies nach dem Drop im Dialog angezeigt und die betreffenden Medien werden anschließend, beim Starten des Upload-Prozesse über den Button „UPLOAD“, nicht ins Projekt hochgeladen.

Bei Bedarf kann dieser Wert angepasst werden, und zwar über folgende Parameter in der Datei web.xml des Moduls „FragmentCreator“ bzw. in der Datei cxt-fragment-creator.properties:

• spring.servlet.multipart.max-file-size: Erlaubte Dateigröße für ein Medium, das per Upload-Dialog hochgeladen wird.
  Der Wert darf nicht größer sein als der Wert für spring.servlet.multipart.max-request-size.
  Zu möglichen Größenangaben siehe Klasse DataSize (Spring Framework).
  Standardwert: 64MB
• spring.servlet.multipart.max-request-size: Jede Datei wird in einem separaten HTTP-Request übertragen. Daher muss der hier angegebene Wert mindestens so groß sein wie spring.servlet.multipart.max-file-size.
  Zu möglichen Größenangaben siehe Klasse DataSize (Spring Framework).
  Standardwert: 64MB

Eine weitere Konfigurationsmöglichkeit hinsichtlich der Dateigröße für Medien-Uploads besteht (weiterhin) über den FirstSpirit ServerManager unter „Projekteigenschaften / Medien-Restriktionen“. Dort können beispielsweise ebenfalls für das Remote-Projekt, in das Medien per FragmentCreator hochgeladen werden sollen, Einstellungen für Mediengrößen vorgenommen sein.
Diese können mit denen für den Upload-Dialog des FragmentCreator konkurrieren.

Upload per Dateiauswahldialog
Bislang wurden die Medien, die ins Projekt hochgeladen werden sollten, per Drag-and-drop in einen entsprechenden Dialog gezogen.
Mit dem aktuellen Release können die hochzuladenden Medien jetzt auch per Dateiauswahldialog ausgewählt werden. Der Dateiauswahldialog kann mit einem Klick in die graue Fläche geöffnet werden.

Upload aus einem anderen Browserfenster-/tab
Zusätzlich zu einem Upload vom Arbeitsplatzrechner können Bilder jetzt auch aus anderen Browserfenstern/-tabs in den Upload-Dialog gezogen werden.
Damit dies möglich ist, muss der Server, der das Bild ausliefert, Cross-Origin-Requests erlauben.

Zu weiteren Informationen siehe

• für Entwickler:
  https://docs.e-spirit.com/odfs/edocs/cxt/vorlagen/medien-verwende/index.html
• für Redakteure:
  https://docs.e-spirit.com/odfs/edocs/cxt/fragment-creato/eingabeelemente/index.html#upload
• zur Datei web.xml:
  https://docs.e-spirit.com/odfs/edocs/cxt/installation-mo/module-installi/fragmentcreator/index.html

Die MicroApp des FragmentCreator „Fragment erstellen“ wird beispielsweise von der Eingabekomponente FS_INDEX mit Fragment DAP und Tag CATEGORY verwendet, z. B.

<FS_INDEX name="contact" useLanguages="no">
    <LANGINFOS>
      <LANGINFO lang="*" label="Contact"/>
      <LANGINFO lang="DE" label="Ansprechpartner"/>
    </LANGINFOS>
    <SOURCE name="FirstSpiritFragmentAccess/FSFAConnector">
      <PROJECT remote="fragments">
        <CATEGORY uid="news"/>
      </PROJECT>
    </SOURCE>
</FS_INDEX>

(Siehe dazu auch Dokumentation „FirstSpirit Content Experience Tools (CXT)“, Vorlagen / Fragmente verwenden.)

Über die „CREATE“-Schaltfläche öffnet sich ein Fenster mit den Eingabeelementen des zu erstellenden Fragments.
Wird in die Eingabeelemente kein Inhalt eingetragen und der Dialog über das X geschlossen, wurde bislang ein (leeres) Fragment angelegt (Ordner und Seiten in der Inhalte-Verwaltung).

Mit dem aktuellen Release kann in diesem Fall jetzt gewählt werden, ob das (leere) Fragment tatsächlich im Projekt angelegt werden soll oder nicht.
Mit einem Klick auf das X öffnet sich dann folgender Dialog:

• Wählt der Benutzer „Löschen“, werden keine Daten im Projekt gespeichert.
• Wählt der Benutzer „Behalten“, wird ein leeres Fragment angelegt und im Projekt gespeichert.

Mit dem aktuellen Release wird die Eingabekomponente zur Eingabe von Zahlenwerten CMS_INPUT_NUMBER auch vom FragmentCreator unterstützt.

Beispiel:

<CMS_INPUT_NUMBER name="number" useLanguages="no">
    <LANGINFOS>
      <LANGINFO lang="*" label="Number"/>      
      <LANGINFO lang="DE" label="Zahl"/>
    </LANGINFOS>
</CMS_INPUT_NUMBER>

Standardmäßig können in diese Eingabekomponente Ganzzahlen (auch negative) eingegeben werden. Darüber hinaus ist auch das Exponentialzeichen E bzw. e möglich, z. B. 1.7976931348623057e+308.
Zusätzlich kann über das Attribut type gesteuert werden, ob Gleitkomma-/Dezimalzahlen eingegeben werden können sollen. Über die Attribute min und max kann ein zulässiger Wertebereich vorgegeben werden. Ungültige Eingaben werden mit einer entsprechenden Meldung abgewiesen und werden nicht gespeichert.

Je nach verwendetem Browser ist die Bedienung durch den User unterschiedlich: so unterbinden Google Chrome und Microsoft Edge die Eingabe von Buchstaben in die Komponente (Ausnahme: das Exponentialzeichen E bzw. e), Mozilla Firefox und Apple Safari hingegen nicht. Die Darstellung des Dezimaltrennzeichens (, oder .) ist in Microsoft Edge und Google Chrome in erster Linie von der Sprache des Betriebssystems abhängig und nicht (nur) von der Browsersprache, während Mozilla Firefox die Browsersprache berücksichtigt. Diese Unterschiede liegen in der Implementierungsweise der einzelnen Browser begründet und damit nicht im direkten Einflussbereich von e-Spirit.

Darüber hinaus wird das Attribut format, das für FirstSpirit ContentCreator und SiteArchitect verwendet werden kann, im FragmentCreator nicht unterstützt.

Zu weiteren Informationen siehe https://docs.e-spirit.com/odfs/edocs/cxt/vorlagen/eingabekomponen/index.html.

Die Statusseite, die für das MicroApp Framework eingerichtet werden kann (unter ~/status), listet jetzt alle aktuell registrierten MicroApps mit Erreichbarkeit, Name und URL auf.

Hinweis: Zum Testen der Erreichbarkeit sendet die Statusseite an jede MicroApp einen leeren Kontext zur Überprüfung. Das kann zu Warnmeldungen wie dieser im Log führen:

de.espirit.cxt.microapps.stereotype.UnsupportedContextException: Context is not 
    supported

Siehe auch Dokumentation zum MicroApp Framework, https://docs.e-spirit.com/odfs/edocs/cxt/installation-mo/module-installi/fragmentcreator/index.html.

Für de.espirit.common.util.Listable wurde die neue Convenience.Methode isEmpty() eingeführt.

Es ist jetzt möglich, bei

de.espirit.common.util
Interface Listable<T>

mittels .isEmpty() direkt zu prüfen, ob das entsprechende Objekt gefüllt ist (Rückgabewert true) oder nicht (Rückgabewert false).

Mit der neuen Methode getPreviousSibling() im Interface StoreElement (Package de.espirit.firstspirit.access.store, FirstSpirit Access-API) kann jetzt ausgehend von einem StoreElement das vorhergehende StoreElement ermittelt und zurückgegeben werden.

Mit der aktuellen FirstSpirit-Version wurde folgende intern verwendete Software aktualisiert:

• Java (JRE, mit dem der FirstSpirit-Launcher betrieben wird)
  Die neuen Versionen sind:
  • 11.0.8+10 64bit AdoptOpenJDK
  • 14.0.2+12 64bit AdoptOpenJDK

Mit dem aktuellen FirstSpirit Release erfolgt nun die endgültige Freigabe der neuen Steuerungsdateien für Windows- und Linux-Betriebssysteme. Somit wird ab sofort auch der Einsatz in produktiven Umgebungen empfohlen.

Voraussetzungen für den Betrieb eines FirstSpirit-Servers sind Java und der Java Service Wrapper. Der Java Service Wrapper und zugehörige Steuerungsdateien werden von e-Spirit über:

• das Installationsarchiv (für Neuinstallationen) bzw.
• das Aktualisierungsarchiv (für bestehende Installationen) bereitgestellt.

Beide Archive sind per Download erhältlich (für Zugangsdaten wenden Sie sich bitte an den Technical Support).

Die neuen Steuerungsdateien sind in beiden Archiven enthalten und unterstützen eine Reihe von Funktionen, die durch die bisherigen Steuerungsdateien nicht abgedeckt wurden (u.a. install unter Linux). Der Funktionsumfang der neuen Steuerungsdateien kann in der Kommandozeile über die integrierte Hilfe (Usage, Command syntax, Commands) aufgerufen werden, beispielsweise über den Aufruf fs-server (unter Linux):

test@fs_example:~$ fs-server
Usage: /home/fs_example/firstspirit/bin/fs-server [ console | start | stop | restart | 
 condrestart | status | install | installstart | remove | dump ]
Commands:
 console      Launch in the current console.
 start        Start in the background as a daemon process.
 stop         Stop if running as a daemon or in another console.
 restart      Stop if running and then start.
 condrestart  Restart only if already running.
 status       Query the current status.
 install      Install to start automatically when system boots.
 installstart Install and start running as a daemon process.
 remove       Uninstall.
 dump         Request a Java thread dump if running.

Steuerungsdateien im Installations- bzw. Aktualisierungsarchiv:

• Neu: fs-server (für Linux)
• Neu: fs-server.bat (für Windows)
• Alt: fs5 (für Linux)
• Alt: fs5.cmd (für Windows)

Die alten Steuerungsdateien werden zukünftig entfallen. Geplant ist der Entfall des Supports mit FirstSpirit 2021-02.

Voraussetzung für die Verwendung der neuen Steuerungsdateien:

Um die neuen Steuerungsdateien verwenden zu können, ist ein Update des Tanuki Java Service Wrappers auf Version 3.5.42 notwendig. Diese Wrapperversion ist im aktuellen Installations- und Aktualisierungsarchiv enthalten.

Weiterführende Dokumentation:

• Aktualisierung des FirstSpirit-Backends
• Installation per Installationsarchiv
• Steuerung des FirstSpirit-Servers (Linux)
• Steuerung des FirstSpirit-Servers (Windows)