Release Notes

Forms and rules (“Dynamic forms”) can be defined for FirstSpirit scripts (like all template types). The form can then be displayed in the desired position via

context.showForm();

The validation (evaluation of the rules) can be deactivated on a language-specific basis so that rules defined for the form are ignored for the language(s) in question (FirstSpirit ServerManager / Project properties / Languages, “Validate language” checkbox).

Previously, in the case of language-independent forms, rules were not evaluated in ContentCreator in some cases as the preview language was taken into account for the form rather than the master language.

With the latest release, the setting in the project properties (“Languages”, “Validate language” checkbox) will be taken into account according to the master language in the case of language-independent forms as well (in the same way as in FirstSpirit SiteArchitect).

Furthermore, the use of ShowFormDialogOperation (de.espirit.firstspirit.ui.operations package, FirstSpirit Developer API) has been adapted to the behavior of SiteArchitect. This interface can be used to create and configure project-specific dialogs.

• Preselection of the language: setPreselectedLanguage(...)
  If setPreselectedLanguage(...) is not defined, the dialog is opened in the master language.
• Definition of language set: setMultiLanguage(...)
  For language-dependent (multilingual) forms, it is necessary to call setMultiLanguage(true). The language set to be edited is transferred to perform(...) and can then be selected in the dialog via the menu.
  
  Alternatively, setMultiLanguage(false) (default) can be used if content is only to be changed in one specified language. If multiple languages are transferred with perform(...) in this case, only the preselected or first language can be edited and a debug log message will be output.

Example:

...
import de.espirit.firstspirit.agency.FormsAgent;
import de.espirit.firstspirit.agency.LanguageAgent;
import de.espirit.firstspirit.agency.OperationAgent;
import de.espirit.firstspirit.ui.operations.ShowFormDialogOperation;

...

formsAgent = context.requireSpecialist(FormsAgent.TYPE);
form = formsAgent.getForm(formdefinition);

la = context.requireSpecialist(LanguageAgent.TYPE);
langs = la.getLanguages();
en = la.getProjectLanguages(false).get("EN");
de = la.getProjectLanguages(false).get("DE");
fr = la.getProjectLanguages(false).get("FR");

sfd = context.requireSpecialist(OperationAgent.TYPE).getOperation
 (ShowFormDialogOperation.TYPE);
sfd.setTitle("My form");
sfd.setMultiLanguage(true);
sfd.setPreselectedLanguage(fr);
sfd.setRuleset(rules);
sfd.setValidation(true);
sfd.perform(form, langs);

In this example, the dialog is opened with the predefined language (“FR”). The language can be selected in the dialog via the menu.

In FirstSpirit ContentCreator, the structure of a site is mapped by means of menu items and pages:
While every page

represents a concrete web page, each menu item

corresponds to a menu item in the site navigation.

Defining start menus/pages
Depending on the site structure, a menu item may comprise not only several sub-menu items, but also several different pages. Equally, there can be menu items which do not have any pages.
Previously, it was only possible to set which specific page or menu item is opened when the user clicks on menu items on the site via FirstSpirit SiteArchitect.

With the latest release, this can now also be controlled via FirstSpirit ContentCreator using the following context menu functions in the navigation view:

• Set as default start menu
  If a menu item has no concrete page or several sub-menu items, clicking on the corresponding menu item on the site takes the user directly to the pages in the subpages set as the “default start menu”.
• Set as start page
  If there are several pages on a menu level, clicking on the corresponding menu item on the site displays the page set as the “start page”.

Changes in this area must be released in order to appear on the site.
Which element is the start menu/page in each case can be checked in the navigation view via the

Controlling visibility of menu items
Previously, the visibility of menu items could be set for each language in FirstSpirit SiteArchitect using the “Display in navigation menu” option for a menu level (“Properties” tab):

This option allows menu items to be temporarily removed from the site on a language-specific basis and added back in again later.

With the latest release, this setting can now also be made in FirstSpirit ContentCreator in the navigation view:

• Hide in navigation menu
  The menu item in question will no longer be displayed on the site in the selected language.
• Show in navigation menu
  Hidden menu items will once again be displayed on the site in the selected language.

Changes in this area must be released in order to appear on the site.

Menu items that are hidden / not visible on the site are visualized by the following icon in the navigation view:

In addition, the menu name is grayed out.

For more information, see FirstSpirit Manual for Editors (ContentCreator), “Menu functions / Navigation”
(https://docs.e-spirit.com/contentcreator/menu-functions/navigation/index.html)

As of FirstSpirit 2020-10, functions can be hidden on a project-specific basis in FirstSpirit ContentCreator (“Tailored UI”).
In the latest release, this functionality has been optimized and further configuration options have been implemented:

Configurable functions
In addition to the standard ContentCreator functions, all ItemsPlugins recognized by FirstSpirit are listed in the configuration dialog and can be edited there.
In order to configure functions originating from customer-specific modules, the “Plug-in” field is now an editable combo box. This also lists the ItemsPlugins recognized by FirstSpirit.

The table columns in the configuration dialog can now be sorted by clicking on the column header to make it easier to find features.

Influencing the sorting of menu entries and icons
The order of features in the ContentCreator interface can now also be influenced via the “Features: Order” tab (“FirstSpirit ServerManager / Project properties / Project components / CXT ContentCreator Extension: Feature Configuration”).

The functions are bundled into groups to provide a better overview.
The functions can be sorted within their group via drag-and-drop. Changes are saved directly without a prompt appearing.

If the standard sorting of a group has been changed, this is indicated by the “Custom Order” label. The sorting is also shown in the overview (“Order” column).

The standard sorting can be restored on a group-specific basis with a click.

Restrictions:
The defined order of the functions is to be considered as a guideline. It may differ slightly in the client so as not to circumvent design and operating specifications for ContentCreator:
For functions in the preview, for example, automatic grouping takes place as soon as several icon bars are nested, and there is also a primary action, e.g., editing.
The “My changes” report is always displayed in the lower area irrespective of its position in the sort order. The positions of the “Search” and “Dashboard” reports cannot be changed. Nor can they be hidden.
In general, the functions of right-aligned menu bars (EasyEdit) are also sorted right-aligned.

Server-wide configuration
In addition to the local project configuration, the “Feature Configuration Service” can also be used to make server-wide settings (FirstSpirit ServerManager / “Modules / FirstSpirit CXT ContentCreator Extension”):

Prerequisite: The “CXT ContentCreator Extension: WebApp for ContentCreator” web component must be added in the “ContentCreator” area (FirstSpirit ServerManager / “Server properties / Web applications”).
If there are ContentCreator instances that are local to a project, the web component must also be added there (under FirstSpirit ServerManager / “Project properties / Web components”).

Configuration is carried out in the same way as at project level.

Note: Currently, the project component “CXT ContentCreator Extension: Feature Configuration” (“FirstSpirit ServerManager / Project properties / Project components”) must be present for every server project for which configuration of the ContentCreator functions is to be carried out. This project component is currently still used to carry out the configuration for each project.
Configuration that is carried out at server level (via the “Feature Configuration Service”) must currently be transferred to the relevant project via the From Service function in order to be used there.
A future release will include configuration of the “Feature Configuration Service” for projects without the “CXT ContentCreator Extension: Feature Configuration” project component. Use of the project component will then be optional; configuration at server level will be sufficient.

An existing configuration from a project can be adopted for the server in the “Feature Configuration Service” via the From Project button.
Conversely, a configuration made at server level can also be adopted for a project via the From Service button.
Existing configurations are overwritten without a prompt appearing; inheritance of settings or similar is not supported.

If necessary, the entire current configuration can be exported in JSON format and then transferred to a different FirstSpirit Server.

Migration notes:

• Actions that were previously found in the StoreTree default group (functions of the tree view in the navigation bar and in the Media Management) are now found in the Navigation group. The StoreTree default group has been removed. This change will be carried out automatically when updating to the latest FirstSpirit release. There is no need to change anything manually.
• An existing configuration that was made before upgrading to FirstSpirit 2020-12 at project level is still valid after upgrading to FirstSpirit 2020-12. To transfer a configuration made at server level, the From Service function of the “CXT ContentCreator Extension: Feature Configuration” project component can be used for the desired project(s) so that a configuration made at server level can take effect in the project.

For more information, see FirstSpirit Online Documentation, “Template development / ContentCreator / Customization / Standard functions” (https://docs.e-spirit.com/odfs/template-develo/contentcreator/customization/standard-functi/index.html)

For CMS_INPUT_DOM and CMS_INPUT_DOMTABLE, the FORMATS tag can be used to define format templates that may be used in the input component, e.g.

  <CMS_INPUT_DOM name="st_text" hFill="yes" list="no">
         <FORMATS>
           <TEMPLATE name="standard"/>
           <TEMPLATE name="h3"/>
         </FORMATS>
         <LANGINFOS>
           <LANGINFO lang="*" label="Text"/>
         </LANGINFOS>
</CMS_INPUT_DOM>

Previously, if the FORMATS configuration was changed later, e.g., by removing a TEMPLATE definition, this could mean that existing content could no longer be saved in ContentCreator (e.g., error message “Referenced element 'xyz' does not exist.”).

With the latest release, CMS_INPUT_DOM and CMS_INPUT_DOMTABLE now also take into account format templates that are no longer valid in ContentCreator (in the same way as SiteArchitect). This means that corresponding formatting will be retained even when saving.
Even if the text is edited within the formatting, the formatting will be retained after saving.

Previously, slow connections resulting from connection problems could lead to frequent reloading of the whole client. Now, in the event of connection problems, a message is displayed at the bottom of the browser rather than reloading the page:

(“There are problems with your network connection. Please contact your administrator!”)

Exceptions:
An automatic reload will still take place for

• authentication errors (error code 403 / “Access denied/impermissible”, followed by the log-in page being displayed)
• maintenance mode (a corresponding text is displayed in the client)

Examples of possible causes of connection problems: The connection between the browser and the application server (e.g., Apache Tomcat) is not stable. Furthermore, the use of HTTP 2.0 can result in problems, depending on the configuration and slow connections (see writeTimeout attribute on the https://tomcat.apache.org/tomcat-9.0-doc/config/http2.html page).
The affected connection should be checked by the administrator (e.g., via the network activity in the browser and the access log of the application server) and an analysis should be carried out to determine why requests are not being finished.

In the template development process, the ContentCreator preview allows the developer to check the changes they make to templates.
Previously, content often had to be changed and saved in order for changes to the underlying template to be taken into account in the preview.
With the latest release, updating the preview in ContentCreator after making changes to templates has been improved, thus simplifying template development.

If changes to underlying templates are not shown in the ContentCreator preview, the preview can be manually updated as follows:

• F5 : ContentCreator is reloaded.
• Ctrl + R : Only the preview is reloaded.

In both cases, /forceRefresh=1 is automatically appended to the URL.

With the new ContentCreator, the state display in the menu bar now takes into account not only pages (PageRef element type) and datasets (Dataset element type), but also other elements such as media folders.

In this context, the WebeditElementStatusProviderPlugin interface (de.espirit.firstspirit.workflow package, FirstSpirit Developer API) now includes the optional method

isSupported(IDProvider)

This method allows the plug-in to offer support for elements other than the standard PageRef and Dataset element types.
It returns information to indicate whether the plug-in supports the relevant element (true) or not (false).

As before, the plug-in also allows dependent objects to be taken into account for the state display and workflows with the

getReleaseState()
getWorkflowGroups()

methods. Thanks to the new method, these dependences can now also be taken into account for other element types.

However, no dependences are taken into account for all IDProvider elements that are not supported according to the configured plug-in.

For more information, see the chapter on the plug-in development of the “Element Status Provider” (ESP): https://docs.e-spirit.com/odfs/plug-developmen/contentcreator/interactive-fea/element-status/functional-over/index.html

With the current FSDevTools release (Release 2.6.4), developers can configure web components, project applications and services using the “FSDevTools” command line tool.

Use cases:

• Install/update (and roll-out) web components in Web Apps
• Add/update project components to projects
• Configure/restart services

Configuration is done via a configuration file in JSON format using the command
fs-cli module configure -mcf|--moduleConfigFile "path/to/configFile.json".

The results of the call can be saved to an additional file (also in JSON format) via the command
fs-cli [...] [-rf|--resultFile "path/to/result.json"].

Syntax:

fs-cli [...] [-rf|--resultFile "path/to/result.json"] 
module configure -mcf|--moduleConfigFile "path/to/configFile.json".

If files are uploaded during configuration, they are automatically uploaded to the appropriate directory for the module.

If a folder is specified in the JSON configuration file, the corresponding folder structure is rebuilt in the server's file system (creating only subfolders under the specified folder).

FirstSpirit 2020-12 supports the following module versions for “FirstSpirit Content Experience Tools”:

* These modules require FirstSpirit 2020-03 or higher from this version.

The latest FirstSpirit release includes the definitive release of the Oracle Database 19c database layer.

The FirstSpirit Community (https://community.e-spirit.com) still contains a detailed migration guide for switching from Oracle Database 11g/12c to Oracle Database 19c for use with FirstSpirit.

The old database layer Oracle Database 11g/12c (de.espirit.or.impl.oracle.OracleLayer) will be removed in the future. This is scheduled to take place with FirstSpirit 2021-06.

With the company's own M1 processor, Apple switches to an ARM architecture. Applications that were developed for an x86 architecture (such as FirstSpirit) can still be executed using the “Rosetta 2” emulation technology.

e-Spirit is currently not aware of any problems when using FirstSpirit with “Rosetta 2”. However, native support of the ARM architecture is currently not planned for FirstSpirit.

Methods for transferring FormData objects have been added to the SnippetAgent interface (de.espirit.firstspirit.agency package, FirstSpirit Access API).

The new methods

getSnippetProvider(@NotNull FormData formData, @NotNull Snippet snippet)

getSnippetProvider(@NotNull FormData formData, @NotNull Snippet snippet, @NotNull 
   SnippetContext context)

make it possible to obtain a SnippetProvider by transferring the corresponding FormData object.

In the latest FirstSpirit version, the rule evaluation (“Dynamic forms” functionality) has been expanded for ContentCreator and SiteArchitect.

What's new?

The services FormDataValueService and MetaDataValueService will be provided. These services provide access to the information of an IDProvider.

Furthermore, three new properties are now available in the rules for corresponding elements:

• PAGE_ID: Determining the ID of a FirstSpirit element of the Page type
• PAGE_UID: Determining the reference name / UID of a FirstSpirit element of the Page type
• PROJECT_PROPERTIES_ID: Determining the ID of project properties.

These are in addition to the existing properties:

• ID: Determining the ID of a FirstSpirit element
• UID: Determining the reference name / UID of a FirstSpirit element. Sections do not technically have a UID, which is why the display name is returned in this case.
• GID: Determining the global ID (GID) of a FirstSpirit element
• TEMPLATE: Determining the template of the current FirstSpirit element. The reference name of the template is returned (UID).

Why do I need this functionality?

With the expanded functionality, it is possible to access FirstSpirit elements in a rule execution even if these elements are outside the current context. This means that information from other forms (e.g., form data from another page, from metadata forms, or from the project settings) can be retrieved and used in the current rule execution.

How can I use this functionality?

Availability and configuration:

In the latest FirstSpirit version, the services FormDataValueService and MetaDataValueService are automatically available in SiteArchitect and in ContentCreator. It is not necessary to configure or activate the functionality separately.

Usage:

The data is retrieved within the form (in the “Rules” tab) using the <SCHEDULE/> tag.

• The FormDataValueService enables access to the data of a form.
• The MetaDataValueService enables access to the data of a metadata form.

The following parameters are used to access a FirstSpirit element (within the <SCHEDULE/> tag):

• ID and Storetype,
• UID and UIDType, or
• GID and Template (for datasets only).

Further parameters are then used to restrict the selection:

• to specific input components (FIELD parameter)
• to content in a specific language (LANGUAGE parameter)

Further information on the new parameters and additional examples:

• see manual Accessing information from other forms.

Example:

Access to metadata at page level (<SCHEDULE/> tag):
Example A enables access to metadata (service="MetaDataValueService").
The input component value (“md_layout”) (via the FIELD parameter) of the “PAGE_UID” page (via the UID and UIDTYPE parameters) is retrieved here.
Use in the current context (<DO/> tag):
This value is saved in the input component (“st_layouttext”) of the current section so that the value can then continue to be used in other rules.

	<RULE when="ONLOCK">
		<SCHEDULE delay="0" id="A" service="MetaDataValueService">
			<PARAM name="UID">
				<PROPERTY name="PAGE_UID" source="#global"/>
			</PARAM>
			<PARAM name="UIDTYPE">
				<TEXT>PAGESTORE</TEXT>
			</PARAM>
			<PARAM name="FIELD">
				<TEXT>md_layout</TEXT>
			</PARAM>
			<PARAM name="LANGUAGE">
				<PROPERTY source="#global" name="MASTER" />
			</PARAM>
		</SCHEDULE>
		<DO>
			<PROPERTY name="VALUE" source="st_layouttext"/>
		</DO>
	</RULE>

The following internal software has been updated in the latest FirstSpirit release:

Eclipse Jetty (contained in the module fs-jetty.fsm / “FirstSpirit Jetty Service”)

Update from version 9.4.31 to version 9.4.33

Install4j (used for FirstSpirit Launcher)

Updated from version 8.0.4 to version 8.0.8.

Java The following new Java version is available:

• Integrated in FirstSpirit (default): 11.0.9.1+1 64bit AdoptOpenJDK
• In the FirstSpirit Launcher JRE module: 15.0.1+9 64bit AdoptOpenJDK

Java Service Wrapper (configuration and monitoring of FirstSpirit Java VM)

Updated from version 3.5.42 to version 3.5.44.

Note: When the FirstSpirit server is updated (auto-update, in-place upgrade), the Java Service Wrapper files are not automatically updated. The Java Service Wrapper can be updated via the tar gzip update archive (file fs-update-[version].tar.gz) as described in the FirstSpirit installation instructions.

Additional documentation:

• on Java Service Wrapper (manual for administrators)
• on Updating the Java Service Wrapper (installation instructions)

Spring Boot (used for MicroApp Framework)
Update from version 2.3.1 to version 2.3.5

Spring Cloud Hoxton (used for MicroApp Framework)
Update from version Hoxton.SR5 to version Hoxton.SR8