Table of Contents

Backend application configuration

The backend application can typically be configured in development using the cluster YML configuration file.
This configuration is used by Neos to create an ASP.NET Core appsettings.json configuration file when generating the application.

Sometimes, you might need to add additional configuration for libraries used in the application (authentication, logger, email sender, ...).
This can be done by creating a appsettings.Development.json file a the root folder of the cluster.

Example :

{
  "PersistenceSettings": {
    "DefaultConcurrencyAccessMode": "Disabled",
    "SendGrid": {
      "Key": "MyKey",
      "From": {
        "Name": "MyApp",
        "Address": "[email protected]"
      }
    }
  }
}

This configuration file adds or overrides values in the appsettings.json file created by Neos when generating the application.

See this article to learn more about ASP.NET Core configuration.

Configure text validation

Neos validates text values on the backend for both entities and entity views.

  • For single-line properties (Multiline = false), values containing line breaks (\r, \n) are rejected.
  • For text properties with a configured maximum length, values exceeding the limit are rejected.

This backend validation is new in Neos 3.0. In earlier versions, this control did not exist at the backend level, which allowed some incorrect data cases to pass.

If you need to temporarily disable one or both controls during a migration, add the following settings in your appsettings.Development.json:

{
  "TextValidation": {
    "EnforceMultiLineConstraint": false,
    "EnforceMaxLengthConstraint": false
  }
}

Apply with environment variable

In .NET configuration binding, use __ as a section separator:

$env:TextValidation__EnforceMultiLineConstraint = "false"
$env:TextValidation__EnforceMaxLengthConstraint = "false"
Caution

Disabling these settings allows invalid text values to be persisted (line breaks in single-line properties and values exceeding configured maximum lengths). These options are intended as temporary production mitigation after an FMK upgrade when full regression testing is not yet possible and the new controls are considered too risky to enforce immediately. Keep them disabled only for transitional scenarios and re-enable them as soon as possible.